[ On Thursday, November 21, 2002 at 23:23:33 (-0500), Andrew Brown wrote: ]
> Subject: Re: libtool-base-1.4.20010614nb9/+REQUIRED_BY
>
> >> as i go to upgrade some pkgs, i see (on one machine) that libtool-base
> >> is required by dict-client.  on another, libtool-base is required by
> >> guile.
> >> 
> >> this seems strange.  there did not used to be anything that explicitly
> >> required libtool-base in this manner.  perhaps the buildlink2 file for
> >> libtool is a little wrong?
> >
> >Packages should only use libtool/buildlink2.mk if they need to link
> >against the libltdl shared library in ${LOCALBASE}.  Otherwise, just
> >setting USE_LIBTOOL in the package (to get a build dependency on libtool)
> >is enough.
> 
> can't say i see *why* they'd need that.

indeed nothing in dict-client actually needs to link with libltdl.so

However dict-client is just one program built from dict-server.  It uses
some of the same source files.  Some of those source files need to
include <ltdl.h> in order to compile correctly.  In reality all of the
code needing that header could be #ifdef'ed out for the client.

In order to have that header available in a buildlink2 world that means
including libtool/buildlink2.mk, which necessarily drags in all the
dependencies (which turn out to be unnecessary in this particular case)

Since I have support for LDSTATIC=-static in my local pkgsrc I was able
to work around the problem of having a bogus runtime dependency on
libtool in dict-client by simply compiling dict-client statically.

>  the dict-client pkg, for
> example, never needed such a thing before.  fwiw...

before 1.8 there was no stupid mandatory plugin support in dictd.

See the TODO in the dict source distribution, in particular the note
about separating the client program into a separate source distribution.

> what does that library do, exactly?  provide an alternative to the
> regular dlopen() foo or something?

"info libtool" and search for ltdl

it's a "portable" wrapper for libdl, as well as offering dlpreopen for
static-only platforms, i.e. semi-useful replacement for libdl.

(in the end all of libtool is just a whole lot of unnecessary red tape :-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>