Re: HP-UX and +s

[Paul Berrevoets]

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 <address@hidden> 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.