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