On Feb 7, 2008, at 03:30, Anders F Björklund wrote:

I've added some configure. flags for +universal variants, and also to the macports.conf file for providing defaults.

They are:

- universal_target # for setting macosx_deployment_target and configure target Default: 10.4

- universal_sysroot # the SDK "sysroot" to use, normally for the -isysroot flag Default: /Developer/SDKs/MacOSX10.4u.sdk

- universal_archs # machine architectures to use, can be more than just one Default: ppc i386

There are some workarounds for known shortcomings/bugs, such as setting -mmacosx-version-min instead of macosx_deployment_target when the variable don't want to take effect,

The documentation I've read says to use MACOSX_DEPLOYMENT_TARGET environment variable. When is this -mmacosx-version-min applicable instead?

or adding -syslibroot on PowerPC so that it doesn't forget to use the Intel versions...

Apple documentation on building universal binaries from configure- based software used to mention -syslibroot but this was removed quite some time ago. When is it still applicable?

The additions means that it will now cross-compile when necessary,

As I understand it, cross-compiling is compiling for a platform other than the one on which the compiler is running. Haven't we already been doing that when building universal binaries?

and that +universal target is meant to generate similar binaries*. By changing the values, it's possible to build for the Leopard SDK and even the Panther SDK (cross-compiling to a previous OS version)

Currently these do _not_ affect the MacPorts os. variables, though. These use the currently running operating system, and nothing else (i.e. they aren't affected by changing these universal variables) So it would still say "+darwin_9" and "+i386", even for Panther SDK.

However, if you do set the universal_target to a certain version then it will pass matching configure flags to autoconf/automake. For instance, when using the default MacOSX10.4u.sdk, it'll use: configure --host=i686-apple-darwin8 --target=i686-apple-darwin8

What problem does setting --host and --target solve? Because for me it's causing a problem, namely that glib2 doesn't build universal anymore. I traced this failure back to r33483 in which you added the --host and --target switches. With trunk r33482 (without those switches), glib2 builds universal. With trunk r33483 (with them), it does not. Possibly suspicious output from glib2's ./configure at the beginning: configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. Definitely suspicious output from glib2's ./configure: checking whether to use assembler code for atomic operations... i486 With r33482 it says: checking whether to use assembler code for atomic operations... none Definitely suspicious output from glib2's make at the end: /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -DG_LOG_DOMAIN= \"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED - DGLIB_COMPILATION -DPCRE_STATIC -I/opt/local/include -isysroot / Developer/SDKs/MacOSX10.4u.sdk -D_REENTRANT -O2 -funroll-loops - fstrict-aliasing -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc - arch i386 -Wall -c gatomic.c -fno-common -DPIC -o .libs/gatomic.o gatomic.c: In function 'g_atomic_int_compare_and_exchange': gatomic.c:66: error: impossible constraint in 'asm' lipo: can't figure out the architecture type of: /var/tmp//ccmwc7KI.out make[4]: *** [gatomic.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

Ryan Schmidt wrote:

...

There are some workarounds for known shortcomings/bugs, such as setting -mmacosx-version-min instead of macosx_deployment_target when the variable don't want to take effect,

The documentation I've read says to use MACOSX_DEPLOYMENT_TARGET environment variable. When is this -mmacosx-version-min applicable instead?

MACOSX_DEPLOYMENT_TARGET is deprecated (but still working), it's just that I had a problem with MacPorts onot setting the environment variables probably so I went for overkill and included the parameter explicitly on Leopard to avoid linker problems with crt1.10.5.o. They both do the same thing, so if the variable had just been set OK then setting the parameter for gcc wouldn't have been needed...

...

or adding -syslibroot on PowerPC so that it doesn't forget to use the Intel versions...

Apple documentation on building universal binaries from configure- based software used to mention -syslibroot but this was removed quite some time ago. When is it still applicable?

It doesn't apply when building on Intel, since there it can load the system libraries without problems. It does apply sometimes on PowerPC, when it doesn't get the -isysroot flag alright, as it will try to use system libraries and fail to link because those libraries are missing the i386 architecture. Including this parameter explicitly made sure that it linked with the libs from the SDK - not system.

...

The additions means that it will now cross-compile when necessary,

As I understand it, cross-compiling is compiling for a platform other than the one on which the compiler is running. Haven't we already been doing that when building universal binaries?

Sortof, but not all the flags were pointing in the same direction... That was "hidden" by setting the SDK version to the same as the system, since then it would always match up - even if using the wrong one... (i.e. if using 10.4u SDK on 10.4 OS and 10.5 SDK on 10.5 OS, then it doesn't matter if some values are gotten from the system instead of sdk) Besides, by setting all flags you can build for PowerPC on Intel say. Like compile Panther/PPC binaries from your Leopard/x86 installation ?

...

However, if you do set the universal_target to a certain version then it will pass matching configure flags to autoconf/automake. For instance, when using the default MacOSX10.4u.sdk, it'll use: configure --host=i686-apple-darwin8 --target=i686-apple-darwin8

What problem does setting --host and --target solve? Because for me it's causing a problem, namely that glib2 doesn't build universal anymore. I traced this failure back to r33483 in which you added the --host and --target switches. With trunk r33482 (without those switches), glib2 builds universal. With trunk r33483 (with them), it does not.

Oops, the port I tested with didn't have any such arch-specific code... Fixed now, in r33947. It will probably still do the wrong thing, though.

Possibly suspicious output from glib2's ./configure at the beginning:

configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used.

This is OK, as maybe we *wanted* to do a cross-compile.

Definitely suspicious output from glib2's ./configure:

checking whether to use assembler code for atomic operations... i486

This is actually a problem when building universal. Setting arch stuff at configure time is bound to break later on, when building for the other. i.e. here it says "use i486", and then it'll try to use that with ppc. Usually such ports will need to be configured/built twice, and merged.

Definitely suspicious output from glib2's make at the end:

/usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -DG_LOG_DOMAIN= \"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED - DGLIB_COMPILATION -DPCRE_STATIC -I/opt/local/include -isysroot / Developer/SDKs/MacOSX10.4u.sdk -D_REENTRANT -O2 -funroll-loops - fstrict-aliasing -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -Wall -c gatomic.c -fno-common -DPIC -o .libs/ gatomic.o gatomic.c: In function 'g_atomic_int_compare_and_exchange': gatomic.c:66: error: impossible constraint in 'asm' lipo: can't figure out the architecture type of: /var/tmp// ccmwc7KI.out make[4]: *** [gatomic.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

This is not suspicious, it is plain wrong :-) Or at least it broke. It was trying to build x86 asm for ppc, which doesn't really fly... Should be back to previous behaviour with the above change to trunk. (i.e. not passing any --host and --build when building fat binaries) --anders PS. It might be a bit overengineered to just build "Universal Binaries". But now it should also work for cross-compiling, and building twice.

On Feb 22, 2008, at 05:25, Anders F Björklund wrote:

Previously, I wrote:

...

- universal_target # for setting macosx_deployment_target and configure target Default: 10.4

- universal_sysroot # the SDK "sysroot" to use, normally for the -isysroot flag Default: /Developer/SDKs/MacOSX10.4u.sdk

- universal_archs # machine architectures to use, can be more than just one Default: ppc i386

...

The additions means that it will now cross-compile when necessary, and that +universal target is meant to generate similar binaries*. ... * this default is a change from MacPorts 1.6.0, that used 10.5 SDK on Leopard and 10.4u SDK on Tiger (but is the same as in 1.5/1.4)

I changed the above defaults back to the same as on MacPorts 1.6.0, except that it is now configured at compiletime (in macports.conf).

So it will now again use /Developer/SDKs/MacOSX10.5.sdk on Leopard, and /Developer/SDKs/MacOSX10.4u.sdk on Tiger and avoid cross-compile.

This implicitly also fixes the issues were the wrong MDT was being passed to GCC, even if it now passes an extra -mmacosx-version-min

As before, cross-compiling is not going to be supported this way since the variants (like +darwin_8 and +i386) will all be wrong.

I don't really understand why this was changed yet again. I renew my objection, which is that a port built with +universal on Leopard won't work on Tiger (but the same port built with +universal on Tiger will work on Leopard). Doesn't this defeat part of the purpose of universal?

Merge support still needs to be added for +universal to work OK, but I'm not going to continue that Summer-of-Code 2007 project...

mww has already rewritten the summer-of-code merge.rb script into the merge tcl function which is already in trunk.

However, changing the Xcode group to support the above settings should be pretty straightforward so that will go in soonishly.