Building a shared libgcc

[Pavel Roskin]

Hello!

> But maybe I'm just overestimating the number of people that enable
> shared libraries when building GCC *and* install it in non-standard
> locations.  The fact that we don't get too many reports about this
> probably indicates that either people read the FAQ or that I'm
> overestimating it, but the fact that we *do* get some such reports
> indicates I'm not alone :-)

I install gcc in non-standard locations an all machines except those where
I know the root password (where I use /usr/local unless /usr/bin/gcc in
absolutely broken).

I also install gcc in non-standard locations in gcc is a cross-compiler
(it is usually /usr/local/hurd/ for the linux->hurd compiler and
/mnt/gnu/usr/ for the cross-compiled hurd->hurd compiler)

I'm usually careful enough to set LD_LIBRARY_PATH to an appropriate value.

However, I realize that if by some reason LD_LIBRARY_PATH will not be set
bad things will happen. This can happen if, for example, ssh is used to
run programs compiled with a "private" (i.e. installed in a non-standard
place) compiler.

On systems where all programs are compiled by gcc, shared libgcc is as
vital as shared libc. Installing libgcc in a non-standard place can cause
a lot of problems.

Maybe you should consider adding libgcc to libc. Then, on systems where
libc includes the necessary routines you don't include them into libgcc.
If all the necessary stuff can be found in libc, libgcc is not built.

AFAIK, Libc CVS is now hosted by SourceWare, so it shouldn't be a problem
to submit your changes.

Another related issue is that I want to have full control on which
libraries are linked as shared and which libraries are linked as static.
I want something like

--only-static=gcc
--prefer-static=stdc++
--prefer-shared=Xm
--only-shared=c

Such options should not make "-l" options unnecessary. They should affect
both explicitly and implicitly (e.g. libgcc.a) linked libraries.

Pavel Roskin