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?,...:

> > Yes, it does.  With your patch, there are no changes to output in the
> > libtool test suite on Tru64 (so it didn't break anything that the tests
> > catch), and libtool no longer removes /local/gnu/lib/libintl.so from the
> > link for GNU libaspell.so.
> >
> > Thanks for the patch, it appears to be exactly what I needed!
>
> Hmm.  Is there a /local/gnu/lib/libintl.la file?

Yes:

$cat /local/gnu/lib/libintl.la
# libintl.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5.14 (1.1220.2.195 2005/02/12
# 12:12:33)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='libintl.so.3'

# Names of this library.
library_names='libintl.so.7.4.3 libintl.so.3 libintl.so'

# The name of the static archive.
old_library='libintl.a'

# Libraries that this one depends upon.
dependency_libs=' -liconv -lc'

# Version information for libintl.
current=7
age=4
revision=3

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/local/gnu/lib'




>  If so, shouldn't
> lib-link be producing that as deplib instead?  I.e., aspell should be
> using the value of LTLIBINTL instead, I believe.

I did notice that LTLIBINTL was correct (i.e. used -L/local/gnu/lib -lintl
instead of /local/gnu/lib/libintl.so) but that's not what aspell was
using (it's using LIBINTL).

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