> > The compromise implemented is this: ld notes the symbol name and the
> > size of the data item (both of which can be found in the shared
> > library's symbol table) and [...]
>[[....]]
> > SunOS 4.x takes a different approach and stuffs all exported data
> > into an accompanying archive (`.sa') file, causing all referenced
> > data to be copied into the executable's data segment.

This discussion is very apropos.  I'd encountered a problem with the
differences between SunOS and NetBSD libraries some time ago, and I
think I tried to convince anyone who would listen on current-users at
the time that the SunOS way was better (though I don't remember what the
objections were at the time -- other than NIH, and as we see below my
opinion may have been misguided).

I've just recently re-encountered this problem and it's now in my face
enough that I'm going to have to implement a work-around.

The issue is where a shared library references storage that's to be
defined by the application.  The problem I encounter is that if I link
an executable with '-l' for such a shared lib on the linker command
line, but even without referencing anything from within that library,
the linker leaves an unresolved entry in the resulting binary and I end
up with an error from ld.so at runtime:

/usr/libexec/ld.so: /usr/libexec/ld.so: Undefined symbol "_deny_severity" in mkdbm:/usr/lib/libwrap.so.0.0
Undefined symbol "_deny_severity" in mkline:/usr/lib/libwrap.so.0.0
 
The workaround is easy -- just never specify '-l' for libraries that are
not actually required by the product.  Such a requirement will break
many default build processes for many many packages though.  The
unexpectedness of this in light of the normal behaviour of libraries,
and esp. the difference between this behaviour for dynamic linking and
static linking is unexpected to say the least, if not down right broken.

(At least I think the transparent "solution" would be to use *.sa
archives ala SunOS-4, though in my case the problem may in fact be just
a silly linker issue -- i.e. the linker should remove unresolved
references from libraries which have no members included in the final
product.)

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>