This is the mail archive of the gcc-patches@gcc.gnu.org mailing 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]

Re: egcs (1.1.1) for BSD/OS 4.0




  In message <14066.35085.218936.509616@ballista.eng.us.uu.net>you write:
  > > Why doesn't defining LINK_SPEC to add -L/shlib work?  Other ports do simi
  > lar
  > > things to override the location where things like libm is found (the PA
  > > for example adds -L/lib/pa1.1 so that it picks up a PA1.1 specific versio
  > n of
  > > the math library).
  > 
  >   Setting LINK_SPEC puts it ahead of the egcs-specific library
  > directories, which causes it to pick up the installed gcc 2.7 libgcc,
  > etc, instead of egcs's...
You might also want to look at LINK_LIBGCC_SPECIAL or something like
that.  It's been a while since I've looked at that code, but it might
(incombination with LINK_SPEC) be able to do what you need.

  >   Actually, I thought about this s'more, and I think I understand your
  > point but disagree.  I think the benefit of having all of your
  > executables that much smaller in disk outweights what I see to be a
  > small risk of the library changing so drastically that the programs
  > don't run anymore.  Perhaps it's because I'm being overly optimistic
  > about the library not needing to change much, but...  I think we'll
  > just have to agree to disagree on this point.  There are arguments to
  > both sides...
It's both a case of the library changing and the library simply going
away.

And it is a serious problem.  The single biggest reason why glibc-2.1
recommends against using gcc-2.8 is because the gcc-2.8 libgcc does not
contain backwards compatible EH intrinsics with older gcc and egcs
releases.

Also consider that even if you don't link in any code from libgcc, you
will often still end up with the path to libgcc embedded in the shared
library search path.  If that happens to be an nfs directory, then you're
going to lose.

Really it's a terrible idea.  This has been hashed at length, we're not
planning on hashing it again since nothing has really changed from a
technical standpoint.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]