Re: HP-UX and +s

[Paul Berrevoets]

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.