http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47608
Summary: libstdc++ links to bad libgcc_s on OS X (libgcc_s rebuilt needlessly and incorrectly) Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: oss...@cendio.se The problem I'm seeing is this: /usr/lib/gcc/i686-apple-darwin9/4.4.3/../../../../i686-apple-darwin9/bin/ld: warning can't open dynamic library: /usr/i686-apple-darwin9/sys-root/libgcc_s.1.dylib referenced from: /usr/lib/gcc/i686-apple-darwin9/4.4.3/libstdc++.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) If you notice the path to libgcc_s.1.dylib, you see that it is directly in the sys-root. This is of course wrong, and we can see why by examining libstdc++.dylib: $ strings /opt/cendio-build/arch/osx32/usr/lib/gcc/i686-apple-darwin9/4.4.3/libstdc++.dylib | grep dylib /usr/lib/gcc/i686-apple-darwin9/4.4.3/libstdc++.6.dylib /usr/lib/libSystem.B.dylib /libgcc_s.1.dylib /usr/lib/libSystem.B.dylib __mh_dylib_header As you can see, it expects a path of / to libgcc_s. This is not however the path stored in the installed libgcc_s: strings /opt/cendio-build/arch/osx32/usr/lib/gcc/i686-apple-darwin9/4.4.3/libgcc_s.1.dylib | grep dylib /usr/lib/gcc/i686-apple-darwin9/4.4.3/libgcc_s.1.dylib /usr/lib/libSystem.B.dylib __mh_dylib_header After digging around in the gcc build system, I noticed that libgcc_s.1.dylib is built twice. Once with the proper path (the one which gets installed), and once with the broken path (the one that libstdc++.dylib seems to link against). They end up in i686-apple-darwin9/libgcc/libgcc_s.1.dylib and gcc/libgcc_s.1.dylib respectively in the build tree. Digging further I believe I found the cause, and it is two-fold: 1. The darwin specific SHLIB_LINK outputs libgcc_s.1.dylib.tmp (and eventually libgcc_s.1.dylib also gets created). But the target for libgcc_s expects libgcc_s.dylib to be created. From libgcc/Makefile.in: libgcc_s$(SHLIB_EXT): $(libgcc-s-objects) $(extra-parts) # @multilib_flags@ is still needed because this may use # $(GCC_FOR_TARGET) and $(LIBGCC2_CFLAGS) directly. # @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name. $(mkinstalldirs) $(MULTIDIR) $(subst @multilib_flags@,$(CFLAGS) -B./,$(subst \ @multilib_dir@,$(MULTIDIR),$(subst \ @shlib_objs@,$(objects),$(subst \ @shlib_base_name@,libgcc_s,$(subst \ @shlib_map_file@,$(mapfile),$(subst \ @shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \ @shlib_slibdir@,$(shlib_slibdir),$(SHLIB_LINK)))))))) 2. The rule for libgcc_s.dylib specifies $(extra-parts), which can resolve to nothing or one of two phony targets. In the latter case (which I'm hitting), make will always assume that things need to be rebuilt. Because of either of the above bugs, the recipe will be executed once more when this target hits: all: all-multi # Now that we have built all the objects, we need to copy # them back to the GCC directory. Too many things (other # in-tree libraries, and DejaGNU) know about the layout # of the build tree, for now. $(MAKE) install-leaf DESTDIR=$(gcc_objdir) \ slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR) In other words, libgcc_s.1.dylib will be recreated instead of just copied, which I assume was the purpose of the above target. And it will be recreated incorrectly as slibdir affects how the library is constructed. (Bug 28910 might also be caused by this)