[macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

[Ryan Schmidt]

On Jul 21, 2017, at 12:56, Kenneth F. Cunningham wrote:

> If it works like I think it does, PortGroup muniversal does manually what Apple's driverdriver.c does behind the scenes for apple gcc compilers (gcc4.2, etc) and is built in to clang … so PortGroup muniversal should not be needed for anything that is being handled by an Apple compiler that can understand what to do with multiple -arch flags.
> 
> <https://opensource.apple.com/source/gcc_42/gcc_42-5577/driverdriver.c>
> 
> If that is all true, it makes me wonder what if anything actually does need PortGroup universal to build correctly any more.

The problem is with configure scripts that make assumptions that don't hold when building for multiple architectures.

For example, consider a configure script that checks whether we are building for 32 or 64 bit. It does so by compiling and running a small C program and running it and checking what happens. It sets a define based on the result, and that define is used in ifdefs in the code during compilation.

If the configure script check is compiled with -arch i386 -arch x86_64 and the resulting program is then run, it will only run as one arch -- x86_64 on 64-bit systems, and i386 on 32-bit systems. So the result of running this program will only give the correct answer on one arch, not both. So on 64-bit systems it will build everything -- both the x86_64 and i386 parts -- as if they were both 64-bit, and on 32-bit systems it will build both parts as if they were 32-bit.

The muniversal portgroup fixes this by extracting the source to two different directories, one for each arch, running configure, build and destroot separately in each of those two directories, and then using lipo(1) to combine all the binaries in the two destroots in a single merged destroot, which is what's then installed.