This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: egcs (1.1.1) for BSD/OS 4.0
- To: "Chris P. Ross" <cross at eng dot us dot uu dot net>
- Subject: Re: egcs (1.1.1) for BSD/OS 4.0
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Thu, 18 Mar 1999 23:24:23 -0700
- cc: egcs-patches at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
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