Subject: Re: CVS commit: pkgsrc
To: Johnny C. Lam <lamj@stat.cmu.edu>
From: Nick Hudson <skrll@netbsd.org>
List: pkgsrc-changes
Date: 05/30/2001 20:53:33
"Johnny C. Lam" wrote:
> 
> Nick Hudson <skrll@netbsd.org> writes:
> > >
> > > Log Message:
> > > Add a target to generate a libtool archive file for libedit.
> >
> > Please don't do this. At least not this way. Why do you need to fool
> > libtool like this? Can I help?
> 
> If you've seen several commits related to "buildlink.mk" files lately,
> it's because I'm experimenting with a way to very isolate the
> libraries and headers available to the configure and build process of
> packages.  This is an attempt to solve the "hidden dependencies"
> problem.
> 
> This particular buildlink.mk deals with our libedit readline emulation
> by optionally linking either the libedit library or the GNU readline
> library and associated headers as ${BUILDLINK_LIBDIR}/libreadline.*
> and as ${BUILDLINK_INCDIR}/readline/*.h.  This way, consumers of
> readline can simply pass -I${BUILDLINK_INCDIR} and
> -L${BUILDLINK_LIBDIR} to the compiler and can always find the readline
> library by using "-lreadline".  This works very well except when
> libtool is used to link a program.  In the case of amanda-client,
> BUILDLINK_LIBDIR is /usr/pkgsrc/sysutils/amanda-client/work/lib, and
> the following line:
> 
> /usr/pkg/bin/libtool --mode=link cc -O2 -mcpu=pentiumpro -mcpu=pentiumpro \
>         -L/usr/pkgsrc/sysutils/amanda-client/work/lib                   \
>         -Wl,-R/usr/pkg/lib -L/usr/pkg/lib                               \
>         -L/usr/pkgsrc/sysutils/amanda-client/work/lib                   \
>         -Wl,-R/usr/pkg/lib -L/usr/pkg/lib  -L/usr/pkg/lib               \
>         -o amrecover                                                    \
>         amrecover.o display_commands.o  extract_list.o help.o           \
>         set_commands.o uparse.o uscan.o                                 \
>         -lfl ../client-src/libamclient.la -lamanda -lreadline -ltermcap -lm
> 
> gets munged by libtool to:
> 
> cc -O2 -mcpu=pentiumpro -mcpu=pentiumpro                                \
>         -Wl,-R/usr/pkg/lib -Wl,-R/usr/pkg/lib                           \
>         -o .libs/amrecover                                              \
>         amrecover.o display_commands.o extract_list.o help.o            \
>         set_commands.o uparse.o uscan.o                                 \
>         -L/usr/pkgsrc/sysutils/amanda-client/work/lib                   \
>         -L/usr/pkg/lib                                                  \
>         -lfl ../client-src/.libs/libamclient.so                         \
>         /usr/pkg/lib/libamanda.so                                       \
>         /usr/pkg/lib/libreadline.so -ltermcap -lm                       \
>         -Wl,--rpath -Wl,/usr/pkg/lib
> 
> To my eyes, it's ignoring the libreadine.so library in
> ${BUILDLINK_LIBDIR} and using the libreadline.la in /usr/pkg/lib,
> despite the fact that the former is listed earlier in the library
> search path.  Unfortunately, I _really_ want to libreadline.so from
> ${BUILDLINK_LIBDIR} to be used, as it's a symbolic link to
> /usr/lib/libedit.so.
> 
> If you examine the libtool line above, you can see that if those flags
> were just passed to the compiler, my expectation that the compiler
> would resolve "-lreadline" to the one in ${BUILDLINK_LIBDIR} because
> that directory is specified earlier to the linker is met.
> Unfortunately, libtool seems to first check for .la files in the
> library search path first, then replace those libraries with the
> corresponding .la files, then passing the results to the linker.
> Given this algorithm, the only way I could think of to force libtool
> to use the libreadline.* in ${BUILDLINK_LIBDIR} was to create a
> libreadline.la in ${BUILDLINK_LIBDIR} so that it would be found
> _before_ the one in /usr/pkg/lib.
> 
> What's the right way to do this?

OK. So I don't think that libtool is easily "fixable" so that it picks
up libraries instead of libtool .la files. So the problem then is to
create a libedit.la without knowing what the libtool internals are.

mkdir ${BUILDLINK_LIBDIR}
libtool --mode=link cc -o libedit.la -rpath /usr/lib
libtool --mode=install cp libedit.la ${BUILDLINK_LIBDIR}

Will create dummy libedit{.a,.la,.so*} files. You'll probably have to
replace the created libedit{.a,so*} with links to the real ones (if I
understand the buildlink.mk stuff)

Nick