[ On Wednesday, February 9, 2000 at 11:05:25 (-0500), der Mouse wrote: ]
> Subject: Re: compile-time linker still doesn't detect missling shared library references?
>
> Unfortunately that is fundamentally incompatible with our shared
> library scheme.  With .a libraries, the linker can pick and choose what
> .o files it brings in.  With .so libraries, it's the whole library or
> nothing.  You'd have to redesign shared libraries so as to avoid this
> before you're likely to fix this.

I don't understand.  In my example with hello.c there is no reference to
any symbol within the library so there's no reason to force the library
to be "pull in" and thus no reason to require hello.c to define any
references required by such a library regardless of whether or not the
library is mentioned on the command-line with '-l'.  No re-design should
be necessary -- just better accounting of symbol references.  The
appearance of '-lwrap' on the comamnd-line has always been just a hint,
not an absolute requirement that the library be used in some way.  Why
should this suddenly change just because the system has foisted shared
libraries upon me by default?

If you keep the command-line syntax the same the assumptions should
remain the same otherwise the developer should be required to always
explicitly mention the shared library by name such as the old SysV
"-lc_s" or perhaps with "-lwrap.so" in this example.  Indeed since the
original SunOS-4 implementation did keep the assumptions the same w.r.t.
'-l' there should be no reason why *BSD linkers can't be fixed to do so
as well.

-- 
							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>