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

[Roumen Petrov]

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


> [SNIP]

Roumen