e: Problem to use VFS modules

[Michael Sweet]

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

Bzzt.  Wrong answer.  You *can* (and we regularly do) use PIC
objects in static libraries using the "Multithreaded DLL" code
generation mode.

The main requirement under Windows is that all objects must be of
the same type; just use PIC for everything...

> > (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.  I believe that most older Motorola processors are the same -
I know they were in my days of OS-9 (not MacOS) and OS-9000,
which included the 680x and 68k CPUs...

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

Interesting that I've never seen a performance difference in any
of our Windows or Linux code that is compiled as PIC...

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

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

Whatever is included with GIMP/GLIB/GTK+ (the bulk of my experience
with libtool)  I don't have the sources handy right now, but it
should be easy enough to check.

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

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

FYI, both LD_LIBRARY_PATH and SHLIB_PATH are reported as supported
in 11.00, at least.  And I know from experience that these don't
override the libraries in the standard search path from testing.

> ...
> fact, this is in accord with the POSIX specification.  That's why

POSIX: The standard of non-standards.

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

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

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).  The latter
is the only way to do it, combined either the the appropriate
run-time library path stuff or putting the library DSO in the
standard locations.

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

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

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

Unfortunately, this is an unacceptable process.  You double disk
space usage and further complicate the build process (making sure
that makefiles can handle install redirection, etc.)  It's one
of the reasons we developed EPM, since RPM (and other free software
package managers) are so brain-dead about packaging.

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

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com