e: Problem to use VFS modules

[Alexandre Oliva]

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

> Alexandre Oliva wrote:
>> ...
>> You don't have to use it for object files that are going to be linked
>> into programs.  Only for those who are going to be used to build
>> libtool libraries.  And you only have to use libtool to link programs
>> if they're linked with libtool libraries.

> But if you are using "make", you'll either need to define a rule for
> each object file you don't want to compile with libtool, or visa-
> versa...

Define regular rules for .c.o, and libtool rules for .c.lo.  No big
deal.

>> ...
>> Agreed.  The whole point is that of abstraction.  It's a trade off.
>> It works well 99% of the time.  Unfortunately, when problems show up,
>> you indeed have to delve into the implementation details.  Just like
>> any custom shared-library building system you might create.

> Except that you have everything in front of you that tells you
> immediately why something is not working or where a particular
> option is coming from.  You don't get that with libtool.

You have everything in front of you when you wrote the shared-library
building mechanism.  For anyone else, it's certainly as easy to find
as it is in libtool.

>> ...
>> Whether an object file or executable is placed in .libs or not
>> depends on configuration options and on the platform on which
>> it's running.

> I have yet to find a platform or package using libtool that
> *doesn't* create a .libs directory.

Libraries are always put in .libs.  Executables are put in .libs when
the wrapper script is needed.  PIC object files are put in .libs in
libtool MLB.

> Sigh... PIC files *CAN* be used in a static library.  It's
> perfectly legal to do so

Except on MS-Windows, in which it just doesn't work because of the DLL
brain-damage.

> (required on many platforms, in fact),

It's not required on any platform I know of.

> and the performance hit (if any) is negligible.

Except on that register-starved seldom-used platform known as x86.
Taking %ebx away from the register allocator makes a *huge*
difference.

> and the problem still remains for any library that is not installed
> in /usr/lib or /usr/lib32.  (something which libtool also does not
> understand)

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)

>> ...
>> On the contrary: this script is useful exactly because it saves you
>> from having to know the details of most commercial run-time linkers.
>> Perhaps you've had bad experiences in the past, when this indeed
>> failed to work.

> I continue to have bad experiences.

Which version of libtool are you using, 1.2?  0.9? :-)

> 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:

    case `/usr/bin/file conftest.$ac_objext` in
    *32-bit*)
      LD="${LD-ld} -32"
      ;;
    *N32*)
      LD="${LD-ld} -n32"
      ;;
    *64-bit*)
      LD="${LD-ld} -64"
      ;;
    esac

    case $LD in # libtool.m4 will add one of these switches to LD
    *-32|*"-32 ") libsuff= shlibsuff= libmagic=32-bit;;
    *-n32|*"-n32 ") libsuff=32 shlibsuff=N32 libmagic=N32;;
    *-64|*"-64 ") libsuff=64 shlibsuff=64 libmagic=64-bit;;
    *) libsuff= shlibsuff= libmagic=never-match;;
    esac

  sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
  sys_lib_dlsearch_path_spec="/usr/lib${libsuff} /lib${libsuff}"

> and HP-UX will ALWAYS load the DSO under the standard directories
> *before* anything you specify in LD_LIBRARY_PATH

FYI, on HP-UX the environment variable is called SHLIB_PATH.  And this
variable, or its equivalent, is searched after directories encoded in
the executable not only on HP-UX, but also GNU/Linux with glibc 2.1 or
newer, FreeBSD 3.0 or newer, IRIX and a number of SysV Unices.  In
fact, this is in accord with the POSIX specification.  That's why
libtool creates two different executables on these systems: one that
uses uninstalled libraries, to be run in the build tree (created upon
the first execution of the wrapper script, unless
--disable-fast-install is specified), and one to be installed, that
searches for libraries in the install tree only.

> (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.

>> >     5. When linking against DSOs, libtool uses the path to the
>> >        file and not the appropriate linker options.
>> 
>> On systems on which this is essential to make sure the linker
>> will use that particular library.

> No, on all systems.  I found this when testing the latest GIMP
> from the wrong directory...

Not all systems, for sure.  Some systems, such as AIX with old
versions of GCC, don't even support this.  But naming the path to the
file is indeed the preferred method, and it is used when we do intend
to have the executable search for the library in that exact pathname.

>> ...
>> ... that is used in building or using libtool libraries.  Sounds a
>> reasonable compromise.

> For all programs unless you want to hack individual object files
> and binaries for non-libtool stuff!

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.

>> ...
>> implementation changes, you'll be screwed.  Use the libtool-provided
>> interface and all will be fine.

> Uhuh.

>> ...
>> You seem to have forgotten about the -static flag, documented in the
>> libtool manual.

> The -static flag applies to all libraries (and the program itself),
> IIRC.  What if I *just* want a static libfoo, but still want the
> shared system libraries?

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

>> ...
>> executables that use libtool libraries.  What's so complicated about
>> it?

> It adds another layer of indirection that makes it difficult to
> track down problems *when* they occur, and it creates a lot of
> unnecessary files that make it difficult to know what files to
> install.

You should use libtool to install.  On a number of platforms,
libraries and programs have to be relinked at install time so that
they search for shared libraries on the right directories.

> Finally, the requirement to use libtool to install programs properly
> on all platforms makes it ill-suited for packaging with anything
> but RPM.

The right approach for packaging is to install using an alternate
DESTDIR, and then create the tarball off DESTDIR, not out of the build
tree.  This will guarantee things work unless install-time relinking
is necessary, in which case you really must install in the location
where shared libraries are going to live.  Fortunately, the only
system on which this is really necessary is HPsUX.

> All other vendor packaging formats want to read the
> binary and remap it separately.

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.

> Unless you know what libtool is doing to "prepare" an executable
> (and/or know where the executable lives in this particular version
> of libtool), it is impossible to package the software!

You're trying to break abstraction layers.  Don't do that.  Use `make
install DESTDIR=/tmp/my-install-root', and get the installed files
from there.

-- 
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