[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Don't install .la files when --no-la-files is used

From: Roumen Petrov
Subject: Re: [PATCH] Don't install .la files when --no-la-files is used
Date: Sat, 08 Nov 2008 17:00:16 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20080925 SeaMonkey/1.1.12

Russ Allbery wrote:
Roumen Petrov <address@hidden> writes:
Russ Allbery wrote:

Debian's experience to date is that --as-needed is buggy and breaks a
lot of software, and overall is not a particularly stable solution.
Removing *.la files so that the unneeded shared libraries aren't linked
in the first place works considerably better at the moment.

Could you point by example how libtool add "pile of unnecessary
dependencies" ?  Whit this example could you confirm that libtool add
more(extra) libraries then specified by project authors ?

When you create a libtool library, libtool records every library against
which that library was linked into the *.la file.  If you then link
another shared library against that shared library using libtool, libtool
reads that list of libraries from the *.la file and links the new library
against them as well.

But problem is not in the libtool.

This is not necessary.  For distribution packages, it's actually harmful.

This depend from platform.

To see why, consider some library libfoo which uses readline.  Suppose
that libreadline is linked and installed with libtool, so it has a *.la
file saying that it depends on libncurses.  When you link libfoo against
libreadline using libtool, libtool will also link it against libncurses,
so it now acquires a dependency on libncurses as well.

This is one of the good samples.
Libtool don't add dependency if is not specified by project makefiles, i.e. LDFLAGS/LDADD.

Readline has to be build without dependent libraries to allow application to link with readline but with different compatible libraries: ncursesw, ncurses, curses, termcap, etc.

But if readline project make rule specify that library has to linked with a particular curses library, libtool has to use this rule, when link an application with readline.

So I think that projects are responsible how to list library dependencies.

Also this mail thread show that --as-needed flag is not universal solution for platforms that allow shared libraries with unresolved externals. I quick internet search show problems with ld from binutils series < 2.17 and some version of 2.17.x. Another "--as-needed" problem is that some projects use xxx_LDFLAGS to add libraries to applications instead xxx_LDADD in
Other projects use LDFLAGS instead LIBS in configure scripts.
This is most common problem for package build rules and I could not understand why libtool is responsible to fix incorrect project build rules.

Also removing la-files won't help. Another tool that list all package libs is pkg-tool. It is so common projects to append all libraries returned from pkg-tool :) . And of course the whole list go in la-files.

Libtool is for multi-platform use and list with complete dependent libraries help me to build binaries on platform that don't support unresolved symbols, as example windows. On this platform libtool don't create shared library if flags -no-undefined is not specified. Many projects don't set this libtool flags and patches for their build system stay open couple of years. In this case command 'make LDFLAGS="-no-undefined ..."' help a lot to build without to touch project files.

I guess that a new flag that order libtool do not link a shared library with dependent libraries is more useful then removing la-files.
This flag may overcome --as-needed problems.

In this case is vendor decision how to build a library



reply via email to

[Prev in Thread] Current Thread [Next in Thread]