Subject: Re: autoconf doesn't find getopt
To: Martti Kuparinen <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 07/16/2001 15:20:00
[ On Monday, July 16, 2001 at 16:51:17 (+0300), Martti Kuparinen wrote: ]
> Subject: Re: autoconf doesn't find getopt
> On Mon, 16 Jul 2001, Martti Kuparinen wrote:
> > I "fixed" this by moving the libwrap test to the end of configure.in
> FreeBSD has src/lib/libwrap/libvars.c which has just these lines:
> int allow_severity;
> int deny_severity;
> Should we have something similar to avoid unresolved symbols
> when linking against libwrap while not using anything from there?
> Should I submit a PR with ready-to-run patch included?
This problem has been around since the half-baked introduction of shared
libraries to NetBSD. It was never an issue in the original SunOS
implementation. Unfortunately it's always been a problem in *BSD.
I'm not so sure the FreeBSD hack is safe in all situations because it
would seem to change the libwrap API in an incompatible way. Hmmm... or
does it? I would work for any static link because then the linker would
simply not need to reference libvars.o from libwrap.a; but what does the
ld.so runtime linker do when it finds a global variable definition in
both the main program and a shared library? Do they become one in the
same, and if not how does the shared library see the correct storage in
the main program? Does this work the same on a.out and ELF?
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>