Mike Stump - shared libgcc on darwin9 (original) (raw)
This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
- From: mrs at apple dot com (Mike Stump)
- To: gcc-patches at gcc dot gnu dot org
- Date: Fri, 23 Feb 2007 23:03:42 -0800 (PST)
- Subject: shared libgcc on darwin9
There is a serious design flaw with how gcc uses environment variables to select the just built shared libraries to test with. In short, it is just broken as designed.
The problem is that when building older gcc packages on newer OSes, we force newer executables, like /usr/bin/ld, which is linked with a shared libgcc, to use the older libgcc, which, isn't going to work. Also, ld could be (it is on darwin9) linked against libstdc++ as well.
Only perfect forwards and backwards compatibility in these runtime libraries would allow resetting the environment variables (DYLD_LIBRARY_PATH) like we do. Since we don't, that's just not the design of these libraries, we can't use that mechanism.
The below patch is a cheap hack to hide the variable from ld. Though, there is no reason why it would be sufficient, for example, expect could be so linked.
Now, on darwin, we can set the install name of the library to the build tree location, and that is sufficient for testing to use that library. The issue is that we then have to change the install name when the library (libraries) are installed to reflect the actual install location, instead of the build location. It is just a lot of annoying work.
Another possibility, would be to fixup the libraries in all gcc releases to be new enough and then just require that people only build the ends of the release branches, not a 4.1.1 for example.
Anoher possibility would be to just stop setting DYLD_LIBRARY_PATH for darwin, as it is known to be problematic and just require people to do a make install before doing any testing. Hum, thinking about this, maybe that is the easiest solution right now, as libgomp already requires a make install prior to testing.
Or, maybe using the variable when the build version is newer than the system versions.
So, I thought I'd ask for comments on the direction we want to take this in, so that it really does work. I hoping for a magic bullet, but don't expect one.
Doing diffs in Makefile.in.1:
--- Makefile.in.1 2007-02-21 20:23:29.000000000 -0800
+++ Makefile.in 2007-02-23 15:38:55.000000000 -0800
@@ -1495,7 +1495,11 @@ stamp-collect-ld: $(ORIGINAL_LD_FOR_TARG
*)
rm -f collect-ld$(exeext);
echo '#!$(SHELL)' > collect-ld;
- echo 'exec (ORIGINALLDFORTARGET)"(ORIGINAL_LD_FOR_TARGET) "(ORIGINALLDFORTARGET)"$@"' >> collect-ld ;
+ echo "# darwin9's ld is linked against a shared libgcc, we can't" >> collect-ld;
+ echo "# randomly use other shared libgcc's as libgcc doesn't" >> collect-ld;
+ echo "# feature upwards and backward compatinbility" >> collect-ld;
+ echo "unset DYLD_LIBRARY_PATH" >> collect-ld;
+ echo 'exec (ORIGINALLDFORTARGET)"(ORIGINAL_LD_FOR_TARGET) "(ORIGINALLDFORTARGET)"$@"' >> collect-ld;
chmod +x collect-ld ;;
esac
echo timestamp > $@
- Follow-Ups:
- Re: shared libgcc on darwin9
* From: Eric Christopher
- Re: shared libgcc on darwin9
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |