egcs (1.1.1) for BSD/OS 4.0

[Chris P. Ross]

Jeffrey A Law <law@hurl.cygnus.com> said:
> 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.

  I agree.  However, it appears that it's not a BSDi addition.  It's
part of the logic used in set_scripts_dir() in ld/ldmain of
binutils-2.8.1.  It's possible they didn't put the wedge in to make it
check /shlib first, or at least not in the right way, but.  If I
remember correctly from my conversation with them, I could mkdir
/shlib/ldscripts and it would also avoid this problem, but...

> 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.

  Well, that was what I tried to do first (setting REAL_LD_FILENAME),
however egcs passes that into find_a_file(), and qualifying the path.
There appears to be no way at all to compile collect2 to invoke "ld".
That was the thing that I was argueing was a reasonable thing to add
to the egcs/collect2 build process...

> 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).

  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...

> 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.

  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...

                         - Chris