Subject: Re: qpopper needs gdbm?
To: None <tech-pkg@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-pkg
Date: 05/11/1999 02:49:46
[ On Tuesday, May 11, 1999 at 01:52:18 (+0200), Hubert Feyrer wrote: ]
> Subject: Re: qpopper needs gdbm? 
>
> On Mon, 10 May 1999, Dean Huxley wrote:
> > checking for gdbm_open in -lgdbm... yes
> > 
> > This sets '#define GDBM 1' in config.h which causes a bunch of files to
> > include gdbm.h.
> 
> Can you have a look at the generated config.log?

FYI, if a package uses GNU Autoconf's AC_CHECK_LIB() macro then there's
no existing way for the package system to know if that library was found
or not during the configuration of the package.  If this library happens
to be of the "shared" variety, and is not a truly standard part of the
system, then the resulting package will not be viable for binary-only
installs.  There are only three possible ways to deal with this
situation:  1) the library must be added as a package dependency (and
one can then only hope that configure finds the packaged library), or 2)
the AC_CHECK_LIB() call must be removed from the package's configure.in
removed and the configure script must be regenerated, or 3) the package
must be linked statically.

At this point it seems unlikely that any short-term release of GNU
Autoconf will have any way to deal with this issue from the command line
interface, though I have raised the issue on the mailing list and have
had some positive response.  The real problem is that the assumption
that the build machine is the target machine, especially with respect to
dynamic linking, is rather hard wired into Autoconf, even despite the
efforts of libtool.

In fact it seems that even with internally used shared libraries there
exists the possiblity that the build will not work unless any and all
previous releases of the package are first removed.  For example this
happens with the most recent version of Amanda, despite the fact that
Amanda tries to use libtool natively (though this hurdle may finally be
cleared with this latest version).

Personally I prefer the idea of going back to static binaries across the
board, at least until we use languages and build systems that can
guarantee we don't mix and match the wrong interfaces.

In the mean time I'm beginning to think the only safe way to build
abinary-only package is on a completely virgin system....

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