On Tue, 7 Nov 2000, Brook Milligan wrote:

> I'm having troubles with several packages or other software that uses
> shared libraries and I'm not entirely sure I understand how to
> construct them.  The objects are created with cc -fPIC ... .  The
> library is created with cc -Bshareable -o xxx.so ... .  The problem I
> have is that this results in "undefined symbol" references and the
> library creation fails.  This is on an a.out (i386) system.
> 
> The questions I have are:
> 
> - is this the correct way to construct a shared library?

I don't know what the "correct" way is. There's a lot of different
ways to do it. You might look in other packages, or in the NetBSD
sources, for examples. One thing, you probably want to use "ld" to
create the shared library on a.out. ("-Bshareable" is an ld option.)

> - how are shared libraries handled on elf versus a.out systems?

If you're porting a package (for submission), the preferred way is to
convert the package to use "libtool". There's an outline of how to do
that in /usr/pkgsrc/Packages.txt.

> - is the fact that I need to resolve all symbols within a single
>   library an a.out requirement or is that also true for elf? or is it
>   a netbsd-specific requirement?
> 
> - do other systems (e.g., linux, freebsd, ...) allow a shared library
>   to have unresolved symbols that can be resolved from a different
>   library at runtime?

All systems do. AFAIK, the shared library that resolves the symbols
still has to be present at link time. (But bug or feature,
NetBSD-i386/a.out "defers" the link-time error until run-time.)
NetBSD-a.out, and ELF, allows a shared library to implicitly pull in
other libraries. This allows you to skip mention of some of the shared
libraries, at link-time, but it's still safest to list them all. E.g:

  ld -o libfoo.so.1.0 -Bshareable -R/usr/X11R6/lib *.o \
    -L/usr/X11R6/lib -lX11 -lXt -lSM -lICE

In the above, on NetBSD-a.out-1.4.3 and later, or NetBSD-ELF, the
mention of -lXt _automatically_ pulls in -lSM -lICE. If you leave it
off on in a NetBSD package, though, someone using 1.4.1/i386 will file
a PR.

> - what is the best way of resolving problems of this sort?  choices
>   seem to be at least the following:  upgrade to elf (if this indeed
>   will allow interlibrary dependencies), patch pkgsrc in some clever
>   way to enable builds on both a.out and elf systems, submit a bug
>   report to the original author.

Use libtool!

> Sorry to be so clueless about the internals of shared libraries, but I
> am encountering more and more of these interlibrary dependencies and
> I'm not sure if there are a bunch of systems that don't have this
> problem or what.

It's pretty common for missing shared libraries to break in various
ways on different platforms. Most commonly, a package developed
against ELF X counts on -lXt to pull in -lSM -lICE automatically.
Hopefully, this will become a non-issue in the future, as NetBSD-1.4.2
and earlier becomes obsolete.


Frederick