Re: universal flags and configuration
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. 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... However, changing the Xcode group to support the above settings should be pretty straightforward so that will go in soonishly. --anders ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: universal flags and configuration
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. ___ macports-dev mailing
universal flags and configuration
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, or adding -syslibroot on PowerPC so that it doesn't forget to use the Intel versions... The additions means that it will now cross-compile when necessary, 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 It still only works for ports using configure and not hardcoding architecture into generated files (like endianness for instance), and there still needs to be an implementation that will build twice (once for each arch) and then merge the results together. Also left to do is to wire the above settings into Xcode group, by using appropriate parameters to the xcodebuild(1) command... (variables like SYSROOT and ARCHS should be straightforward, and I think the remaining one is MACOSX_DEPLOYMENT_TARGET ?) Thoughts? --anders * 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) ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: universal flags and configuration
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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
