Subject: Re: Shared libraries
To: Ian Dall <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
Date: 06/27/1999 19:19:35
On Sun, 27 Jun 1999, Ian Dall wrote:
: If I do
: gcc -shared -o libfoo.so.1.0 a.o b.o c.o
This is presuming NetBSD 1.4 or later, of course - on NetBSD 1.3.x on a.out
systems, "gcc -shared" was horribly broken and you really needed "ld
-Bshareable". NetBSD 1.3.x on ELF had other restrictions (see below), but
: what happens if a, b or c have reference to other libraries? I notice
: that this will succeed even when symbols are not resolved, presumably
: they are just stored somewhere and resolved at runtime.
This only happens on a.out systems. On ELF systems, you *must* provide the
dependent libraries on the cc or ld link line, otherwise the link will fail.
If you do happen to supply the dependencies on either a.out *or* ELF, the
runtime linker (ld.so or ld.elf_so) will automatically load the dependent
library at program runtime.
: However, what happens when the symbol is in standard library (say libc).
: Does the libc_pic.a ever get used "automatically" in response to a -lc
: or would it need -lc_pic?
You'd need ot use -lc_pic if you actually wanted to link the code into the
shared object (ld.so, for example, uses this to pull bits of libc in, since
the shared libc isn't yet loaded when ld.so starts).
However, the default is just to set a dependency in the library upon libc
(*if* you are using cc -shared on 1.4 or specifying -lc).
: If the libc_pic.a is not used, what actually happens? I notice the
: size of the shared library is considerably smaller if I use -nostdlib
: than if I don't. Also if I don't use -nostdlib, libfoo.so ends up with
: a whole stack of extra symbols.
This smells like you may, in fact, be on NetBSD 1.3.x on a.out. See above
comment about gcc -shared vs. ld -Bshareable. In any case, if you're on
1.4, you should not use -nostdlib.
: Finally, what happens if there is no shared library? I am thinking
: specifically of libgcc.a. If a, b or c call a function in libgcc.a, is
: it extracted from libgcc.a and linked? If so that is almost certainly
: wrong since libgcc.s doesn't appear to be compiled with -fpic.
libgcc _is_ compiled -fpic.
-- Todd Vierling (firstname.lastname@example.org)