e: Problem to use VFS modules

[Michael Sweet]

Alexandre Oliva wrote:
> 
> On May  8, 2001, Andrew Tridgell <tridge at sevenofnine.su.valinux.com> wrote:
> 
> > So do you think we can use libtool in such a restrained way?
> 
> Yep
> ...

Everything you described points to libtool being used for EVERY
program and object file.  That's not restrained...

Here are my "standard" objections to using libtool:

    1. libtool adds another layer to the compiler tools and hides
       compiler options, etc. making it difficult to fix problems
       when they occur.
    2. libtool creates a .libs directory and puts all object files,
       libraries, and executables in that directory.  Symlinks or
       scripts are created in the main directory pointing to those
       files, doubling the number of files that are created.
    3. Separate PIC and non-PIC object files are created for
       shared and static libraries (.lo and .po).  This is
       unnecessary and doubles the number of files, compile time,
       etc.
    4. The script created by libtool for executables doesn't work
       on most commercial UNIX's.  This script is created to help
       resolve DSO dependencies, but unfortunately most commercial
       run-time linkers don't work like the Linux/BSD run-time
       linker, so this script is useless and misleading.
    5. When linking against DSOs, libtool uses the path to the
       file and not the appropriate linker options.  This causes
       the run-time linker on some operating systems to look
       relative to the current directory (e.g. ../lib) for the
       DSO, opening up potential security and testing issues.
    6. Once you decide to use libtool, you have to use it for
       everything.  You won't be able to access the libraries
       or object files from the standard tools without a great
       deal of effort (i.e. the .libs thing)
    7. Libtool will link against the shared library if you build
       one, and doesn't give you the option of just linking
       against a static library for a test program, for example.

As you can see, I'm *not* being restrained about my criticism for
libtool.  It is always touted as the be-all end-all solution to
compiling problems, but in my experience it has been nothing short
of a nuisance.  I will grant that most of the larger problems in
libtool have been ironed out, but the basic design and philosophy
behind it is flawed.  Tools like these should *simplify* the
build process, not make it more complicated!

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