On 14/06/2006, at 5:15 AM, Mike Stump wrote:
None of this is a problem on MacOS X Intel. The cross-compilers
build without problems on an Intel Mac.
Well, apparently one solution is to fatten your system.
My attempts to do that just resulted in a system that would not boot :-(
Fortunately, I tried it on a spare disk.
The other might be to try:
x86-*-darwin*,*-*-darwin*)
instead, and then use --with-sysroot=/.
I have done something like that already. Basically breaking the
configure test and adding --with-sysroot= to the CONFIGFLAGS
definition in build-gcc. This allowed the powerpc-i686 build to go
through.
[ this list is for people that want to roll up their sleeves and
fix their own problem. If you want us to fix it for you, just file
a PR. :-) ]
I am trying. Currently the cross-hosted compiler build still breaks,
which seems to be an issue with the SDK.
The link breaks like this:
/usr/bin/ld: warning fat file: /usr/lib/system/libmathCommon.A.dylib
does not contain an architecture that matches the specified -arch
flag: i386 (file ignored)
/usr/bin/ld: warning multiple definitions of symbol _strncmp
../libiberty/libiberty.a(strncmp.o) definition of _strncmp in section
(__TEXT,__text)
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libSystem.dylib(strncmp.So)
definition of _strncmp
/usr/bin/ld: Undefined symbols:
_fegetround referenced from libSystem expected to be defined in /usr/
lib/system/libmathCommon.A.dylib
collect2: ld returned 1 exit status
make[2]: *** [makedepend] Error 1
make[1]: *** [all-libcpp] Error 2
+ exit 1
This would seem to be because libSystem.B.dylib references the
system's libmathCommon.
billn% otool -L /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/
libSystem.B.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libSystem.B.dylib:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.1.3)
/usr/lib/system/libmathCommon.A.dylib (compatibility version
1.0.0, current version 210.0.0)
This cannot be changed with install_name_tool because
libSystem.B.dylib is a stub library.
Any suggestions? Does the -isysroot compiler flag fix this sort of
issue? It does not seem to be used in the gcc build.
Bill
