🚀 go-pugleaf

Hello GCC gurus,

Could you please help me with the following problem:
I have to maintain GCC for sparc-sun-sunos4.1.3 (and others not interesting
here). It uses the SUN Linker to use shared libraries and all works fine.
When dynamic linking is in effect, all library search paths specified by
the -L options are remembered in the executable, so that the run time linker
can search for them at program startup time.
Since the SUN Linker does not remember that /usr/gnu/lib/gcc-lib... does not
contain any shared objects, it searches for them also here, invoking the
automounter, scanning directories etc, just to find it of no earthly use.

FOR EVERY GCC-COMPILED EXECUTABLE, the procedure above has to be performed
(if /usr/gnu/... has not been mounted at least).
We have linked some important programs (like login shells like bash)
statically, but linking all programs this way cannot be done.

Our LAN contains 255 sun4 workstations, our NFS servers are often
"not responding still trying" and GCC is heavily used!

So is it possible to tell GCC not to use a -L option to specify the libraries
above, instead link them with the full path ?
Our system administrator said this would be an improvement.

I used the force and read the source. :-)

I found a "#define LINK_LINKGCC_SPECIAL" in gcc.c which causes gcc to use
/PATH/libgcc.a instead of -L/PATH -lgcc.

Would this be possible for libg++ and libobj, too ?
I tried to modify the "specs" file, but runnung gcc under gdb I found it treats
-lfoo options as simple arguments for ld, not beeing able to substitute them
via the specs expansion mechanism.

Has anyone else also that problem ?
Are there any patches ?
Or am I simply brain dead and overlooked a simple solution ?

Any help would be greatly appreciated!

Please send mail to

	aquarius@cs.tu-berlin.de

or, better follow up as other gcc maintainers may have the same problem.

Thank you!

    Christoph Reichert
    Technical University Berlin

P.S: Sorry for my bad english!