e: Problem to use VFS modules

[Michael Sweet]

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...  And since all programs a likely to link against the
libraries you made with libtool, you're stuck there as well...

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

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

> By default, libtool will attempt to create PIC and non-PIC object
> files on systems that don't use PIC by default.  It's perfectly
> possible to disable the creation of the non-PIC object files,
> disabling static libraries by default.  This can be done by the user

Sigh... PIC files *CAN* be used in a static library.  It's
perfectly legal to do so (required on many platforms, in fact),
and the performance hit (if any) is negligible.

> ...
> .lo and .o.  The .Po you're talking about is probably the automake
> dependency file, which has nothing to do with libtool.

OK, sorry.  Most of the packages that use libtool also use
automake.  It's hard to separate what comes from where...

> >     4. The script created by libtool for executables doesn't work
> >        on most commercial UNIX's.
> 
> Please file bug reports.  The libtool testsuite tests this, and
> nobody has reported problems about it, except on MS-Windows, in
> which the script is named foo whereas the Makefile is expecting
> foo.exe.

I did when GIMP first started using libtool.  They were ignored,
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)

> ...
> 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.  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), and HP-UX will
ALWAYS load the DSO under the standard directories *before*
anything you specify in LD_LIBRARY_PATH (if you have a previous
version installed, there is no way to test without installing)

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

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

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

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

Finally, the requirement to use libtool to install programs properly
on all platforms makes it ill-suited for packaging with anything
but RPM.  All other vendor packaging formats want to read the
binary and remap it separately.  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!

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