Subject: Re: compile-time linker still doesn't detect missling shared library references?
To: NetBSD-current Discussion List <current-users@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: current-users
Date: 02/09/2000 02:23:35
[ On Tuesday, February 8, 2000 at 21:57:20 (+0000), David Brownlee wrote: ]
> Subject: Re: compile-time linker still doesn't detect missling shared library  references?
>
> 	Apologies for the ambiguity in my statement - its use in a shared
> 	library is lightly bogus (not incredibly, but somewhat). It would
> 	be much better to pass in pointers to {allow,deny}_severity as
> 	needed.

Philosophically speaking I'd be more inclined to require calls to
functions that initialise or manipulate any internal data structures.
I'm very much on the side of always hiding the internal data
representation, even when it might be extremely simple (as it is in this
case).  Passing these values as additional parameters would be OK too,
but some things do make more sense to treat as "state" rather than as
"parameters".

> > In every other sane shared-library system I've ever used, including the
> > venerable SunOS-4 ones that NetBSD's are derived from, the compile-time
> > linker chokes immediately when a library, shared or otherwise, makes an
> > unresolved reference.  In no case should the failure ever have to wait
> > for the run-time linker to find it.  If this means bringing back the
> > lib*.sa files then so be it.
> > 
> 	Just to clarify - the problem is that code in the shared library
> 	which is not called referenced {allow,deny}_severity?

In the original problem, on a.out systems, is that it does not matter
whether or not any code in the library is actually referenced or not --
the mere appearance of '-lwrap' on the link command-line will cause a
run-time ld.so failure if there's no definition of {allow,deny}_severity
in the resulting program.

02:07 [232] $ uname -srm 
NetBSD 1.3.3 i386
02:07 [233] $ echo 'main() {printf("hello world.\\n");}' > hello.c
02:07 [234] $ cc -o hello hello.c
02:07 [235] $ ./hello
hello world.
02:07 [236] $ cc -o hello-lwrap hello.c -lwrap
02:08 [237] $ ./hello-lwrap                    
/usr/libexec/ld.so: Undefined symbol "_deny_severity" in hello-lwrap:/usr/lib/libwrap.so.0.0


However I see that on -current things are indeed not quite as bogus any
more, at least not on i386.  All that remains is the problem that the
compile-time linker doesn't seem to know whether or not any library code
has been refernenced and always wants to see definitions for undefined
library externals, just as you mentioned:

02:11 [6] $ uname -srm
NetBSD 1.4R i386
02:10 [7] $ echo 'main() {printf("hello world.\\n");}' > hello.c
02:10 [8] $ cc -o hello hello.c
02:10 [9] $ ./hello
hello world.
02:10 [10] $ cc -o hello-lwrap hello.c -lwrap
/usr/lib/libwrap.so: undefined reference to `allow_severity'
/usr/lib/libwrap.so: undefined reference to `deny_severity'
collect2: ld returned 1 exit status

I'd rather see this fixed than not (i.e. don't require references to
library global declarations unless library objects are referenced).
However I am much happier with seeing the compile-time failure rather
than having to wait until run-time to find it!  If this is an ELF
"feature" then "Thanks ELF!", and if it's a fix done explicitly by
somone then "Thanks!" to whomever did it.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>