After 'configure' on HP-UX, the 'libtool' script contains the following
'hardcode' values:
hardcode_action=relink
hardcode_into_libs=no
hardcode_libdir_flag_spec="\${wl}+b \${wl}\$libdir"
hardcode_libdir_separator=":"
hardcode_direct=yes
hardcode_minus_L=yes
hardcode_shlibpath_var=unsupported
Now, if I edit 'libtool' and change the hardcode_direct to:
hardcode_direct=no
then the problems I had described earlier (see below) are resolved.
However, if I make this change for hpux in 'libtool.m4' and reconfigure, then
the check for 'how to hardcode library paths into programs' results in:
hardcode_action=immediate
which does not resolve my problem and may not be appropriate for HP-UX (I don't
know). The 'libtool' script handles the following settings the way I need it,
but libtool.m4 won't allow such a configuration. Are these settings
inconsistent with each other?
hardcode_action=relink
hardcode_direct=no
hardcode_minus_L=yes
--
Thanks,
Paul
Paul Berrevoets wrote:
> I've tried this now, but unfortunately it doesn't work.
>
> The man page for ld says:
> +s Indicates that at run-time, the shared library
> loader can use the environment variable SHLIB_PATH
> to locate shared libraries needed by the
> executable output file that were specified with
> either the -l or -l: option. The SHLIB_PATH
> environment variable should be set to a colon-
> separated list of directories. If both +s and +b
> are used, their relative order on the command line
> indicates which path list will be searched first
> (see the +b option).
>
> but the problem is that my link line:
> /bin/sh ./libtool --mode=link gcc -Wl,+s -o foo -L/usr/local/lib -lbar
> foo.o
> executes the following:
> gcc -Wl,+s -o foo foo.o -L/usr/local/lib /usr/local/lib/libbar.sl
> -Wl,+b -Wl,/usr/local/lib
> which does not use a -l option to specify the file libbar.sl, and therefore
> the executeable will not search the SHLIB_PATH to find libbar.sl if it is
> not in /usr/local/lib.
>
> Therefore, in order for -Wl,+s to work, -lbar must not be expanded to
> /usr/local/lib/libbar.sl. But I don't know why this expansion is done in
> the first place, and therefore I wouldn't know how to fix it properly.
>
> Makefile.am:
> lib_LTLIBRARIES = libbar.la
> bin_PROGRAMS = foo
> foo_LDFLAGS = -L$(libdir) -lbar
> --
> Regards,
> Paul
>
> Alexandre Oliva wrote:
>
> > On Oct 26, 2000, Paul Berrevoets <[EMAIL PROTECTED]> wrote:
> >
> > > (hpux*, hardcode_libdir_flag_spec): Do not use +s by default.
> >
> > > What was the rational for this?
> >
> > It's not default, and there's no good reason to change the default.
> >
> > > I would like to have my application support the SHLIB_PATH
> > > environment variable, what would be the recommended way to add the
> > > +s to my configure.in?
> >
> > LDFLAGS=-Wl,+s.
> >
> > But you shouldn't add it to your configure.in; if you do, you'll be
> > making decisions that people who *build* your package should be
> > allowed to do.
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
