egcs (1.1.1) for BSD/OS 4.0

[Chris P. Ross]

Jeffrey A Law <law@hurl.cygnus.com> said:
>   In message < 14064.5379.907565.865920@ballista.eng.us.uu.net >you write:
>> LIB_SPEC either, as far as I can tell.  I need to figure out where the
>> -L's for the "normal" library paths get built, and put a new -L after
>> that.  I'll hunt around for it, but if you can suggest where to put
>> it, I'd appriciate it.  (I need to add a -L/shlib *after* the
>> egcs-specific lib dirs, since there may be duplicates of things like
>> libgcc...)

> Sorry I don't follow this.  egcs knows how to find its own libraries, you
> don't want to override that.

  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.

  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.

  In looking s'more, I found that I need to add "-L/shlib" at the end
of, or just after, %D.  The only way I have found to do this is to
duplicate the LINK_COMMAND_SPEC from gcc.c into config/arch/bsdi.h,
and add "-L/shlib" between %D and %o.  Ugly, but I can see no other
way to add that to the link line, and since I can't make collect2
invoke "ld" instead of "/usr/bin/ld", I must add -L/shlib to the link
line to get it to pick up the shared libraries.

  Make more sense now?

>> As a seperate [hopefully quick] question, is there support for
>> building/installing a libgcc.so?  I don't see anything that does it
>> (for linux,or the like) that I can try to mirror...

> No, and it's a bad thing to do.

> Consider what happens when you upgrade and delete your old copy of gcc.

  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.

  Thanks...

                         - Chris