universal flags and configuration

[Anders F Björklund]

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.