David Holland <dholland@cs.toronto.edu> writes:
>  > : 3) Our shared libraries, at least a.out ones, don't deal well w/ libraries
>  > : depending on other libraries. It doesn't auto-include them.
>  > 
>  > Which will not, ever, get fixed on a.out platforms.  (Yet another argument
>  > for ELF, but then, the a.out behavior is actually the historic and
>  > expected... ;)
> 
> ELF shared libraries still don't deal very well with cross-library
> dependencies.

Uh, for the definition given above ("auto-include"), indeed, ELF
shared libraries _should_ do the right thing, unless i'm horribly
misremembering.


Note that that doesn't necessarily mean that the NetBSD _make process_
is set up to do the right thing.

For instance, as an example of a proper auto-inclusion, consider
libg++ (which requires libcurses):

12 [beta] tmp % ldd /usr/lib/libg++.so
/usr/lib/libg++.so:
         -lcurses.2 => /usr/lib/libcurses.so.2

16 [beta] tmp % gcc main.c -lg++ -lstdc++ -lm
17 [beta] tmp % ldd a.out
a.out:
         -lcurses.2 => /usr/lib/libcurses.so.2
         -lg++.4 => /usr/lib/libg++.so.4
         -lstdc++.0 => /usr/lib/libstdc++.so.0
         -lm.0 => /usr/lib/libm.so.0
         -lc.12 => /usr/lib/libc.so.12

Note the correct inclusion of libcurses, even though it wasn't
specified on the command line.


Note also the fact that, in many cases, dependencies aren't
specified wehre they should be.  for instance, if you look at a
solaris system, you'll note that libm depends on libc, libX11 depends
on a whole bunch of things including libc, etc.

In general, NetBSD should, but does not, specify those dependencies as
part of its make rules.  (it does for libg++ because for whatever
reason that had already been done for a.out, if i recall correctly.
8-)



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.