Ian Lance Taylor wrote:
Note that if you are using a linker which supports the --eh-frame-hdr option, and if your libc provides the dl_iterate_phdr function, and if the gcc configure script figures those things out, then exceptions will correctly propagate across shared libraries even if you don't use libgcc_s.so. That approach is also more efficient and should be used if possible, so libgcc_s.so may not be an issue for you.
That's affirmative for the linker, but I know libc doesn't have dl_iterate_phdr. Somebody even gave me a patch to add that functionality a few months ago, but they never submitted it to the DragonFly devs. As an aside, I might follow that up to take advantage for future releases of DragonFly, but for the present it appears that still need libgcc_s.so.
This could indeed be the problem. Did you use --disable-bootstrap when you ran configure? When bootstrapping, this is supposed work due to the setting of LD_LIBRARY_PATH in the top level Makefile before building adalib. Specifically, these lines: $(RPATH_ENVVAR)=`echo "$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \ TARGET_LIB_PATH = $(TARGET_LIB_PATH_libstdc++-v3)$(TARGET_LIB_PATH_libmudflap)$(TARGET_LIB_PATH_libssp)$(TARGET_LIB_PATH_libgomp)$(HOST_LIB_PATH_gcc) Ideally libgcc_s.so.1 should be found via HOST_LIB_PATH_gcc. (If you used --disable-bootstrap, then you are more or less responsible for dealing with this yourself.)
Yes, that's exactly what I'm using. Sounds like the solution is either remove that configuration item or deal with this paths myself as you mentioned. This information points in me in the right direction.
You'll have to ask the ports people. In Debian or RPM packaging, libgcc_s.so.1 is only installed by the core gcc package.
Yeah, I don't think that kind of restriction is in place for the BSDs. I was thinking there might be some common configuration that results in a unique file location so they don't step on each other, but it sounds like there's only one spot for library.
Thanks Ian! John
