When bootstrapping a mainline compiler on i386-apple-darwin8.8.1, we
are linking libstdc++.dylib incorrectly. My understanding of the
build machinery behind libstdc++ is very poor, so here's what I've
found.
The symptom of the problem is a warning from the Darwin linker when
trying to build any C++ program. Here's the result of "Hello, World":
/usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib
referenced from: /Users/dgregor/Projects/mainlinegcc-install/lib/gcc/
i386-apple-darwin8.8.1/4.3.0/../../../libstdc++.dylib (checking for
undefined symbols may be affected) (No such file or directory, errno
= 2)
Now, the problem here is that nobody should be referencing /libgcc_s.
1.dylib.... it doesn't exist. The correct libgcc_s is installed as /
Users/dgregor/Projects/mainlinegcc-install/lib/libgcc_s.1.dylib.
Running otool -L on libstdc++.dylib confirms that it is indeed libstdc
++.dylib that is looking in the wrong place:
libstdc++.dylib:
/Users/dgregor/Projects/mainlinegcc-install/lib/libstdc++.
6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.4)
/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
(The last line is the important one)
Now, the *installed* compiler actually does the right thing with
respect to libgcc_s. Running "otool -L' on the executable for "Hello,
World" produces:
./a.out:
/Users/dgregor/Projects/mainlinegcc-install/lib/libstdc++.
6.dylib (compatibility version 7.0.0, current version 7.9.0)
/Users/dgregor/Projects/mainlinegcc-install/lib/libgcc_s.
1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.6)
So, the problem is clearly in the way we're building libstdc++.dylib.
The compiler we use to link libstdc++.dylib is:
CXX = /Users/dgregor/Projects/mainlinegcc-build/./gcc/xgcc -shared-
libgcc -B/Users/dgregor/Projects/mainlinegcc-build/./gcc -nostdinc++ -
L/Users/dgregor/Projects/mainlinegcc-build/i386-apple-darwin8.8.1/
libstdc++-v3/src -L/Users/dgregor/Projects/mainlinegcc-build/i386-
apple-darwin8.8.1/libstdc++-v3/src/.libs -B/Users/dgregor/Projects/
mainlinegcc-install/i386-apple-darwin8.8.1/bin/ -B/Users/dgregor/
Projects/mainlinegcc-install/i386-apple-darwin8.8.1/lib/ -isystem /
Users/dgregor/Projects/mainlinegcc-install/i386-apple-darwin8.8.1/
include -isystem /Users/dgregor/Projects/mainlinegcc-install/i386-
apple-darwin8.8.1/sys-include
Sure enough, if I link a C++ "Hello, World" with this compiler
command, I get an executable that links to that bogus libgcc_s:
./a.out:
/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.6)
I assume that the libgcc_s.1.dylib we want to link against is the one
built in /Users/dgregor/Projects/mainlinegcc-build/i386-apple-
darwin8.8.1/libgcc, but I couldn't manage to get libstdc++.dylib to
link against that one...
I'll be happy to test patches, but I have *no* idea how to attack
this problem.
Cheers,
Doug
