Of libgcc -pic and -shared and openbsd config

Marc Espie espie@quatramaran.ens.fr
Tue Sep 26 15:40:00 GMT 2000


On Tue, Sep 26, 2000 at 02:11:55PM -0700, Richard Henderson wrote:
> On Tue, Sep 19, 2000 at 07:31:55PM +0200, Marc Espie wrote:
> > Note that I believe a separate t-openbsd/t-openbsd-old makes sense,
> > even though they `share' a large part, the idea being that t-openbsd-old
> > is somewhat broken, and not to use for anything else.
> 
> I think it's better to just add a new entry to the tmake list
> for 2.8, similar to config/i386/t-crtpic.
Ok.

> > The last issue is the libc spec change for -shared... like FreeBSD does,
> > I think we ought not to link against libc by default for shared libraries
> > (especially since we have a shared libc). Opinions ?

> This is a big mistake.
> 
> Always link against every DSO that you depend on.  Always.
> 
> Linking against dependant libraries has multiple benefits:
> 
>  1. If you ever implement elf symbol versioning, linking against the
>     implementing library is critical to getting the .o symbols bound
>     to the correct version.  Not an issue for you now, but maybe later.

Could you explain (briefly) how this is supposed to work ?

>  2. It sets up the proper dependancy graph between the DSOs.  This
>     dependancy graph influences the order in which libraries are
>     initialized.

>  3. Having the explicit dependancy on the libraries providing the
>     symbols used by your new DSO ensures that they will be present
>     when dlopen'ing your new DSO.

> Points 2 and 3 generally tend to cause more problems when the 
> dependancies are not present for libraries other than libc, since
> libc tends to always be present.  But making an exception to the
> general rule for no good reason is bad.

Actually, I've found several good reasons, at least for now.  


1/ Using gcc -shared to build libc makes stuff break in a big way, 
as you end up with libc depending on itself, and ld barfing all over the place.

As you said, exceptions to the general rule are bad... from the system point
of view, we would have to make an exception to the way we build libraries
to accommodate libc.

2/ Depends where you're placing the barrier... if you build a portable,
system independent compiler, this is fine.

Now, from our point of view, gcc is the system compiler. And libc is just
another library. Not a special case at all, except for linking programs.

3/ We don't have weak symbols on all platforms yet. Hence, our pthread 
implementation is done through a separate libc_r right now.

Having libc dependencies hardcoded in other dynamic libraries would break
things in a big way, and we would have to multi-lib the link of all other
shared libraries... Ouch.


So, I guess this is a sound decision for now, and it will be revisited 
later on, when finally we do get our linker/other tools updated, and we
use a separate libpthread...


More information about the Gcc mailing list