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 <14065.8582.314971.116630@ballista.eng.us.uu.net>you write:
  >   Correct.  I'm sorry, I probably left off too much of the preceeding
  > parts of the conversation.  To summarize, collect2 invokes ld with a
  > full path.  The ld on my OS (BSD/OS 4.x) acts differently if invoked
  > as "ld" than as "/usr/bin/ld".  Particularly, it searches
  > "/usr/bin/../lib" first for libraries when invoked as "/usr/bin/ld".
  > This causes it to get the static libc/libm/etc before the dynamic
  > shared ones in /shlib.
Right.  I remembered all this.  BTW, this is *majorly stupid* behavior
for BSD/OS's linker.  You should complain to them that this behavior loses.

  >   In asking before if it was reasonable to modify collect2 to have a
  > compilation option that would allow it to know to invoke ld as "ld",
  > you said you thought that was ugly, and that I should be able to
  > rectify the problem with LINK_SPEC or LIB_SPEC.
I'd really prefer to avoid this since we have mechanisms to handle these
kinds of issues via spec files.  Another option is for the tm.h file to
define REAL_LD_FILENAME.  But I don't recommend that either if we can use
specs to DTRT.

  >   In looking s'more, I found that I need to add "-L/shlib" at the end
  > of, or just after, %D.
Why doesn't defining LINK_SPEC to add -L/shlib work?  Other ports do similar
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 version of
the math library).


  >   Blah.  Yeah, I guess that's a valid point.  I guess I'm used to a
  > system with a more stable compiler, as is true of the gcc 2.7.2.1
  > installation on the BSDi-shipped system.  I can see how your point is
  > especially valid with a "secondary" compiler, and one that changes
  > fairly quickly.
Even if you had a "more stable compiler", what happens when you do an upgrade
of the entire system every few years -- and possibly the compiler has been
updated.

Really, it's a bad idea, even when the compiler only changes once every few
years.

jeff



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