Re: mode=link and full path to dependent shared library?

[Tim Mooney]

In regard to: Re: mode=link and full path to dependent shared library?,...:

> > I'm talking about a situation like this:
> >
> > /bin/sh ./libtool --tag=CXX --mode=link cxx  -some_compiler_flags -o
> > libfoo.la -rpath /path/to/lib -version-info 16:3:1 -no-undefined foo.lo
> > bar.lo baz.lo /path/to/lib/libdep.so -llib2 -lc -rpath /path/to/lib
>
> > libtool should be creating libfoo.la (and both shared and archive libfoo
> > libraries) and should be linking against /path/to/lib/libdep.so, but it's
> > eliding the /path/to/lib/libdep.so from the shared library creation line.
> > I'm just trying to find where this behavior is discussed, so I can
> > understand why it's doing that.
>
> Can you use `-L/path/to/lib -ldep' instead, given that libdep is not
> part of the package, or maybe `/path/to/lib/libdep.la' if it's a libtool
> library?

The thing is, I'm not the one doing it.  The package that exhibits this
behavior is GNU aspell, the (dependency) shared library is
libintl.so (the GNU gettext library for systems that don't have it in
libc), and its full path is coming out of a call to AM_GNU_GETTEXT.
After the package (GNU aspell) calls that macro and the Makefiles are
generated, the Makefile ends up with

LIBINTL = /local/gnu/lib/libintl.so -liconv -lc -rpath /local/gnu/lib

Later in the Makefile is the line:

libaspell_la_LIBADD = $(LIBINTL) $(PTHREAD_LIB)

So, when libtool attempts to create libaspell, the creation of the shared
library results in missing symbols, because libtool removed
/local/gnu/lib/libintl.so from the link line.

> I'm pretty sure there is a libtool bug lingering here, but also have a
> vague feeling that passing this argument to the linker unmodified does
> not have the same effect on all systems.  At least the path hardcoding
> semantics vary, but maybe taking advantage of this is your intention?

I more or less stumbled on this by accident, and was just trying to
understand why libtool was removing the shared library that was specified
by path.  I assumed that the AM_GNU_GETTEXT was doing that for a reason.

Tim
--
Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164