e: Problem to use VFS modules

[Alexandre Oliva]

On May 12, 2001, Michael Sweet <mike at easysw.com> wrote:

>> > (required on many platforms, in fact),
>> 
>> It's not required on any platform I know of.

> IRIX (and any MIPS-based system, for that matter) requires PIC
> code (even in the kernel now), so PIC is the default (and only)
> mode.

Oh, I understand what you mean.  Indeed, on platforms in which PIC is
the default, libtool will not even try to compile a non-PIC object,
and will use the PIC one for static libraries.

>> One of the big points of libtool is that it doesn't require
>> libraries to be installed in /usr/lib.  What makes you think it
>> does?  (Details, please)

> The libtool script puts /usr/lib in the LD_LIBRARY_PATH.  This
> causes 32-bit libraries to be used with 64-bit programs, and
> of course you app won't work...

It certainly doesn't put /usr/lib in there by default.  Perhaps you're
using -R /usr/lib, or linking with some library that is configured to
install on /usr/lib?  This would indeed cause /usr/lib to be added to
the default search path of the program, unless /usr/lib was listed in
the system library search path.  But if /usr/lib64 is listed in there,
/usr/lib isn't.

>> > Under IRIX the script does not use the right library path (/usr/lib
>> > instead of /usr/lib32 for n32 apps or /usr/lib64 for 64-bit apps),
>> 
>> Doesn't this code in libtool.m4 help:
>> ...

> You'd think it should, but the "helper" script doesn't use it
> (or misses it.)

It doesn't have to use it.  libtool uses this information to tell
which directories are in the system library search path, so that they
don't have to be added to executables' search paths.

> FYI, both LD_LIBRARY_PATH and SHLIB_PATH are reported as supported
> in 11.00, at least.

Not on older versions of HP-UX.

> And I know from experience that these don't override the libraries
> in the standard search path from testing.

It  depends on whether +s appears before or after +b in the link
command.  If +s is not given, SHLIB_PATH is not used at all.

>> ...
>> > (if you have a previous version installed, there is no way to test
>> > without installing)
>> 
>> Nope.  This is exactly where libtool wins.  Old versions didn't get
>> this right, but this was fixed during the 1.3.* series.  The current
>> release is 1.4.

> Sigh... The HP-UX bug prevents this type of testing, because of
> the library search order problems I've seen.

That's why libtool creates different executables for execution in the
build tree and for installation.  This is where all other shared
library build systems I know fall apart.

> cc -o foo foo.o ../lib/libfoo.so

> is not the same as:

> cc -o foo foo.o -L../lib -lfoo

> The former does not work on most System V platforms (the library
> always must be in the ../lib/libfoo.so path).

That's why hardcode_direct is set to yes on such platforms, and
libtool will use some other way to find the library on such platforms.
-L../lib will also be avoided if hardcode_minusL is yes.

> The latter is the only way to do it

There are systems that use -L flags as run-time library search paths,
so you don't always want to use it.  Libtool has information about
how to get a certain pathname added to the run-time search path, and
how to avoid having them accidentally added when a library is not at
its installation place.  On HPsUX and AIX, there's no way to do it
properly, so executables have to be relinked at install time, after
libraries are already in place.  On all other systems I know of, this
is not necessary, and libtool finds at least some way to link with a
library while specifying a different path in which it should be
searched at run-time, in the case of an executable linked with a
shared library.  In the case of inter-library dependencies, things get
much harder, and relinking is necessary in more cases.

>> ...
>> I don't understand what you mean.  When you link a program with a
>> libtool library, you of course have to use libtool to link.
>> Otherwise, you don't.

> Sigh...  Since all libraries must be built using libtool, and
> and most programs will be linked against those libraries, most
> programs must be linked with libtool.  Am I missing something
> here?

You don't have to (and, in fact, you shouldn't) compile the object
files that are going to be used in programs using libtool.  I.e., you
don't use libtool for everything.

>> ...
>> -static applies only to libtool libraries.  It's -all-static that
>> applies to all system libraries.

> OK, so you've changed the meaning of a (more or less) standard
> compiler/linker option, then?

Nope, I just inherited it from the original author of libtool.  I'd
have used -prefer-static instead, and keep -static with its original
meaning, but I'm not willing to change this at this point.

>> ...
>> The right approach for packaging is to install using an alternate
>> DESTDIR

> Unfortunately, this is an unacceptable process.

Well, you can choose whether you want it to work or not.  I've already
said, but I'll repeat: on a number of systems, it's necessary to
relink executables and, more commonly, shared libraries that depend on
them, after they're installed, to get them to find the libraries in
the proper place.  If you're not willing to do that, you're not
willing to support those systems.  It's your call.

>> Relocating install trees won't always work without setting
>> LD_LIBRARY_PATH or equivalent.  If a program or a library is created
>> such that it expects to find libraries in a certain directory, if the
>> libraries aren't there, you'll have to set LD_LIBRARY_PATH or
>> equivalent for them to be found.

> *Or* use the appropriate linker option to tell the run-time linker
> where to find the libraries.  We've used this method for years
> with 100% success.

Go figure how to do that properly on HPsUX 10.20, for example.  There
are options to specify the search path, but if you use either
$builddir/libfoo.sl or -L$builddir -lfoo, HPsUX will look for
libfoo.sl in $builddir before the specified search path, which you
don't want.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me