On Wed, Apr 03, 2002 at 10:39:55AM +0100, Nick Hudson wrote:
> On Wednesday 20 March 2002 2:00 pm, Johnny Lam wrote:
> > On Wed, Mar 20, 2002 at 09:30:30PM +1000, Rene Hexel wrote:
> > > 
> > >   Can you please back this out again or fix it?  At least on i386 this
> > > causes all buildlinked packages that link against libintl to horribly
> > > fail!  At the moment there is a ton of packages that no longer build
> > > because of this.
> > 
> > I'm struggling with this because I don't see this problem on my machine.
> > I'll back it out, but can you aid in debugging why this is causing things
> > to break?
> 
> What's the plan with this change that is needed for Solaris/a.out platforms?

I've think I've discovered the source of the problem that described by Rene
and also in pkg/15964.  I'll try to restate the problem.  Suppose you have
(on ELF):

	/usr/lib/libintl.a
	/usr/lib/libintl.so
	/usr/lib/libintl.so.0
	/usr/lib/libintl.so.0.0

	/usr/pkg/lib/libintl.a
	/usr/pkg/lib/libintl.la	<-------- libtool archive
	/usr/pkg/lib/libintl.so
	/usr/pkg/lib/libintl.so.1
	/usr/pkg/lib/libintl.so.1.0

	/usr/pkg/lib/libbase.a
	/usr/pkg/lib/libbase.la
	/usr/pkg/lib/libbase.so
	/usr/pkg/lib/libbase.so.0
	/usr/pkg/lib/libbase.so.0.0

	${BUILDLINK_DIR}/lib/libintl.a      --> /usr/lib/libintl.a
	${BUILDLINK_DIR}/lib/libintl.so     --> /usr/lib/libintl.so
	${BUILDLINK_DIR}/lib/libintl.so.0   --> /usr/lib/libintl.so.0
	${BUILDLINK_DIR}/lib/libintl.so.0.0 --> /usr/lib/libintl.so.0.0

	${BUILDLINK_DIR}/lib/libbase.a      --> /usr/pkg/lib/libbase.a
	${BUILDLINK_DIR}/lib/libbase.la     --> /usr/pkg/lib/libbase.la
	${BUILDLINK_DIR}/lib/libbase.so     --> /usr/pkg/lib/libbase.so
	${BUILDLINK_DIR}/lib/libbase.so.0   --> /usr/pkg/lib/libbase.so.0
	${BUILDLINK_DIR}/lib/libbase.so.0.0 --> /usr/pkg/lib/libbase.so.0.0

The libtool archives in ${BUILDLINK_DIR} are created by the code in
bsd.buildlink.mk that is delimited by checks for _BUILDLINK_LIBTOOL_ARCHIVE.
They're just the installed libtool archives run through sed to replace
/usr/pkg/lib/libfoo.la with ${BUILDLINK_DIR}/lib/libfoo.la.

Now suppose you want to link libext.so against both libbase.so and
libintl.so.  You execute:

	libtool --mode=link -o libext.la ext.lo \
		-L${BUILDLINK_DIR}/lib -lbase -lintl

What you want is:

	cc -shared -nodefaultlibs .libs/ext.o \
		-Wl,--rpath -Wl,/usr/pkg/lib -L${BUILDLINK_DIR}/lib \
		/usr/pkg/lib/libbase.so -lintl \
		-Wl,-soname -Wl,libext.so.0 .libs/libext.so.0.0

but what you actually get is (tested using the nb8 version of libtool):

	cc -shared -nodefaultlibs .libs/ext.o \
		-Wl,--rpath -Wl,/usr/pkg/lib -L${BUILDLINK_DIR}/lib \
		/usr/pkg/lib/libbase.so /usr/pkg/lib/libintl.so \
		-Wl,-soname -Wl,libext.so.0 .libs/libext.so.0.0

Note the difference in the third line in that we want to link against the
libintl.so that is in ${BUILDLINK_DIR}, but instead we link against the
libintl.so in /usr/pkg.  Also note that despite having
-L${BUILDLINK_DIR}/lib come before all of the libraries that it still won't
links against the correct libintl.so.

The line that causes this is line 2633 of /usr/pkg/bin/libtool:

          newlib_search_path="$newlib_search_path $absdir"

In the libtool script, "absdir" is set to the location of the true
installed location of a .la file, so for libbase.la above,
$absdir == /usr/pkg/lib.  "newlib_search_path" is used in the libtool
script to find libNAME.la when it encounters "-lNAME" on the command line.
The result of the above line is that when libtool sees
"-L${BUILDLINK_DIR}/lib -lbase", it correctly turns it into
"/usr/pkg/lib/libbase.so", but it also adds "/usr/pkg/lib" to the search
path, so that when libtool then encounters "-lintl", it will find
/usr/pkg/lib/libintl.la and prefer it over the libintl libraries in
${BUILDLINK_DIR}.

I'd trying the understand the ramifications of removing this line from
libtool.  It appears to be safe, but I haven't yet tried my test case of
rebuilding KDE2 yet.

Nick, do you have any thoughts on this?  I haven't check on the libtool
mailing list, yet, but I will soon.

	-- Johnny Lam <jlam@jgrind.org>