e: Problem to use VFS modules

[Alexandre Oliva]

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

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

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.

>     1. libtool adds another layer to the compiler tools and hides
>        compiler options, etc. making it difficult to fix problems
>        when they occur.

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.

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

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.

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

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
or with a macro in configure.in.  Oh, and the files are actually named
.lo and .o.  The .Po you're talking about is probably the automake
dependency file, which has nothing to do with libtool.

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

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

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.

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

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

On systems that might be affected by this, the program you run at
build time is different from the one that gets installed, and the one
that is installed will look for libraries at the place they're
installed.  If you have proof to the contrary, please file a bug
report.

>     6. Once you decide to use libtool, you have to use it for
>        everything.

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

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

You shouldn't have to do it, and, in fact, you shouldn't do it.
Whenever you do it, you're breaking encapsulation, so, if the internal
implementation changes, you'll be screwed.  Use the libtool-provided
interface and all will be fine.

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

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

> Tools like these should *simplify* the build process, not make it
> more complicated!

I fail to see why you find it more complicated.  All you have to do is
use libtool to compile object files you intend to use in libtool
libraries, to link them into libtool libraries, and to link
executables that use libtool libraries.  What's so complicated about
it?

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