You should probably also mention /etc/ld.so.conf.d. I hope it's not necessary to note specifically that a package can't have .la files in directories that it adds to the ld search path.
- J<
Jason L Tibbitts III wrote:
You should probably also mention /etc/ld.so.conf.d.
Since that's (should be!) already referenced in /etc/ld.so.conf, I figured it didn't need to be explictly mentioned. Maybe I was being too optimistic.
I hope it's not necessary to note specifically that a package can't have .la files in directories that it adds to the ld search path.
I hope that too. (:
-- Rex
On Tue, 26 Sep 2006 10:53:25 -0500, Rex Dieter wrote:
See http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives
Comments?
Better. Originally we just didn't take the time to cover and explain corner-cases, because the longer it gets, the less easy it becomes for new contributors.
As a strict "MUST NOT" it is still insufficient, as it may happen that an application still uses an old libtool ltdl to link libtool archives at run-time. You simply cannot avoid the lengthy discussion about the pitfalls of including linkable libtool archives (as outlined in the foot-note) and the consequences of exluding them or removing them when it's too late. It's similar to the "*.so -> devel" problem, which is not understood widely yet either and cannot be covered sufficiently with a one-line policy.
/lib is included in run-time linker's standard search path, too, btw.
On Tue, Sep 26, 2006 at 10:53:25AM -0500, Rex Dieter wrote:
See http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives
Comments?
-- Rex
| Here's a crazy-but-not-too-far-from-reality example: Build shared-lib | pkg 'b' which links against 'a'. b's .la files now include references | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which | links against 'b', whose own libc.la file includes | references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end | up with a pkg z, and a libz.la, which, when all is said and done, | | * will have a direct dependancy upon y's liby.la | * and because of liby.la file references/dependances, will have | (indirect) dependancies upon liba.la, libb.la, ..., libx.la | | When, generally, *none* of these are really required nor desired.
I'm not sure about that, but maybe I understand something wrongly:
- If -la was needed for building libb, then there exists a real dependency between liba and libb and libb.la is correct about that.
- If -la was unneccessary in building libb, libb.la will indeed contain an unneccessary reference to liba. But that should be considered a bug in the build of libb, or not? Fixing that bug may also ease on the BuildRequires, so we should really be interested in fixing such bugs.
In this simplistic view, *.la's are either in order, or there's a bug that we'd like to remove anyway.
From a different view: *.la files aren't much different than *.pc files, in fact they contain a subset of their information. One wouldn't argue to remove all *.pc files because some may contain too many references to libs.
On Mon, 2 Oct 2006 12:32:12 +0200, Axel Thimm wrote:
| Here's a crazy-but-not-too-far-from-reality example: Build shared-lib | pkg 'b' which links against 'a'. b's .la files now include references | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which | links against 'b', whose own libc.la file includes | references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end | up with a pkg z, and a libz.la, which, when all is said and done, | | * will have a direct dependancy upon y's liby.la | * and because of liby.la file references/dependances, will have | (indirect) dependancies upon liba.la, libb.la, ..., libx.la | | When, generally, *none* of these are really required nor desired.
I'm not sure about that, but maybe I understand something wrongly:
- If -la was needed for building libb, then there exists a real dependency between liba and libb and libb.la is correct about that.
So far so good. But here, mixing of build-time and run-time dependencies starts. Run-time deps enter the build-time dep-chain. Add Rex's "c" to the set. "c", which needs just "b" at build-time, sees the indirect dep on "a" (=> liba.la) through libb.la. libb-devel needs to "Requires: liba-devel" just because of a .la dependency.
At build-time, shared-lib "c", which only requires libb, links via libb.la, which in turn needs liba.la (because libb.la lists it as a dependency). And it creates in libfoo.la the more complex libb.la -> liba.la dep-chain. Application "foo", which needs only libfoo, now also needs libb.la + liba.la when the linking is done via libfoo.la instead of just -lfoo.
The BuildRequires pile up -- unless the packagers fix them bottom-up because they examine the new .la file(s). If they don't, wrong BR move up in the dep-chain. Guess what happens if libfoo is upgraded and now build-requires libd.la. This requires additional BR in "foo", although "foo" doesn't depend on libd directly.
Worse, libtool inter-library dependencies often are hardcoded as absolute paths, e.g. /usr/lib/liba.la.
Removal of any .la from the entire dep-chain bears a very big risk of requiring a rebuild of the entire dep-chain bottom-up plus pruning the spec BR/Reqs, also bottom-up.
From a different view: *.la files aren't much different than *.pc files, in fact they contain a subset of their information. One wouldn't argue to remove all *.pc files because some may contain too many references to libs.
These are broken and partially have their origin in "extreme static linking". (For static linking you need the full chain of -lfoo arguments, as everything else would result in missing symbols).
pkgconfig "Requires" in libfoo.pc should list the options that are needed to build with libfoo, NOT the options that were used to build libfoo. With sane linking, the shared libfoo has a run-time dep already on any other libs it needs and is linked against, e.g. liba and libb, so adding -la -lb and so on is not needed when linking shared against -lfoo.
Michael Schwendt wrote:
On Mon, 2 Oct 2006 12:32:12 +0200, Axel Thimm wrote:
From a different view: *.la files aren't much different than *.pc files, in fact they contain a subset of their information. One wouldn't argue to remove all *.pc files because some may contain too many references to libs.
These are broken and partially have their origin in "extreme static linking". (For static linking you need the full chain of -lfoo arguments, as everything else would result in missing symbols).
pkgconfig "Requires" in libfoo.pc should list the options that are needed to build with libfoo, NOT the options that were used to build libfoo. With sane linking, the shared libfoo has a run-time dep already on any other libs it needs and is linked against, e.g. liba and libb, so adding -la -lb and so on is not needed when linking shared against -lfoo.
Thankfully, pkgconfig has both Libs: Libs.private: The former for *real* lib dependencies, the latter for private/static ones. Unfortunately, not many developers are aware-of or use Libs.private, but it least the feature is there. I'm not aware of any similar functionality for libtool (yet).
-- Rex
On Mon, 2006-10-02 at 13:31 +0200, Michael Schwendt wrote:
On Mon, 2 Oct 2006 12:32:12 +0200, Axel Thimm wrote:
| Here's a crazy-but-not-too-far-from-reality example: Build shared-lib | pkg 'b' which links against 'a'. b's .la files now include references | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which | links against 'b', whose own libc.la file includes | references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end | up with a pkg z, and a libz.la, which, when all is said and done, | | * will have a direct dependancy upon y's liby.la | * and because of liby.la file references/dependances, will have | (indirect) dependancies upon liba.la, libb.la, ..., libx.la | | When, generally, *none* of these are really required nor desired.
I'm not sure about that, but maybe I understand something wrongly:
- If -la was needed for building libb, then there exists a real dependency between liba and libb and libb.la is correct about that.
So far so good. But here, mixing of build-time and run-time dependencies starts. Run-time deps enter the build-time dep-chain. Add Rex's "c" to the set. "c", which needs just "b" at build-time, sees the indirect dep on "a" (=> liba.la) through libb.la. libb-devel needs to "Requires: liba-devel" just because of a .la dependency.
Yes, because libtool aims at portability. What you call "indirect deps" is non-portable, therefore libtool keeps this info around.
The BuildRequires pile up -- unless the packagers fix them bottom-up because they examine the new .la file(s). If they don't, wrong BR move up in the dep-chain. Guess what happens if libfoo is upgraded and now build-requires libd.la. This requires additional BR in "foo", although "foo" doesn't depend on libd directly.
Worse, libtool inter-library dependencies often are hardcoded as absolute paths, e.g. /usr/lib/liba.la.
And what is the problem? Outside of the linux world, shared-libs are non-relocatible.
Removal of any .la from the entire dep-chain bears a very big risk of requiring a rebuild of the entire dep-chain bottom-up plus pruning the spec BR/Reqs, also bottom-up.
This is not a risk - this is a feature.
From a different view: *.la files aren't much different than *.pc files, in fact they contain a subset of their information. One wouldn't argue to remove all *.pc files because some may contain too many references to libs.
These are broken and partially have their origin in "extreme static linking". (For static linking you need the full chain of -lfoo arguments, as everything else would result in missing symbols).
Wrong: They have their origin in portability. Only fully linking is portable. Packages aiming at portability can not and must not avoid these deps.
pkgconfig "Requires" in libfoo.pc should list the options that are needed to build with libfoo, NOT the options that were used to build libfoo. With sane linking, the shared libfoo has a run-time dep already on any other libs it needs and is linked against, e.g. liba and libb, so adding -la -lb and so on is not needed when linking shared against -lfoo. From a libtool focused perspective, *.la's and *.pc aim share some
aspects, that's all. *.la's provide features, *.pc provide others.
The main disadvantage of *.pc's is them not being automatically generated which enables users to outsmart themselves by "presuming portability on proprietary features" (Very common bug in linux sources).
Ralf
On Mon, 02 Oct 2006 19:36:48 +0200, Ralf Corsepius wrote:
Yes, because libtool aims at portability. What you call "indirect deps" is non-portable, therefore libtool keeps this info around.
The BuildRequires pile up -- unless the packagers fix them bottom-up because they examine the new .la file(s). If they don't, wrong BR move up in the dep-chain. Guess what happens if libfoo is upgraded and now build-requires libd.la. This requires additional BR in "foo", although "foo" doesn't depend on libd directly.
Worse, libtool inter-library dependencies often are hardcoded as absolute paths, e.g. /usr/lib/liba.la.
And what is the problem? Outside of the linux world, shared-libs are non-relocatible.
We're not "outside of the linux world". You make a big thing out of "features", which we don't need, because they increase the trouble. They also add the possibility of "feature abuse". Source tarball vendors who hack "stuff" into libtool files to make the end-product work even less good.
Removal of any .la from the entire dep-chain bears a very big risk of requiring a rebuild of the entire dep-chain bottom-up plus pruning the spec BR/Reqs, also bottom-up.
This is not a risk - this is a feature.
So what? It means: increased maintenance requirements that sucks.
From a different view: *.la files aren't much different than *.pc files, in fact they contain a subset of their information. One wouldn't argue to remove all *.pc files because some may contain too many references to libs.
These are broken and partially have their origin in "extreme static linking". (For static linking you need the full chain of -lfoo arguments, as everything else would result in missing symbols).
Wrong: They have their origin in portability. Only fully linking is portable. Packages aiming at portability can not and must not avoid these deps.
Insert comment from above here, too. It's fine from the perspective of the vendor of the source tarball. I've made good use of libtool long ago. Still the "feature bloat" is a hindrance at the RPM packaging level the longer the inter-library dependency-chain becomes.
On Tue, 2006-10-03 at 01:56 +0200, Michael Schwendt wrote:
On Mon, 02 Oct 2006 19:36:48 +0200, Ralf Corsepius wrote:
Yes, because libtool aims at portability. What you call "indirect deps" is non-portable, therefore libtool keeps this info around.
The BuildRequires pile up -- unless the packagers fix them bottom-up because they examine the new .la file(s). If they don't, wrong BR move up in the dep-chain. Guess what happens if libfoo is upgraded and now build-requires libd.la. This requires additional BR in "foo", although "foo" doesn't depend on libd directly.
Worse, libtool inter-library dependencies often are hardcoded as absolute paths, e.g. /usr/lib/liba.la.
And what is the problem? Outside of the linux world, shared-libs are non-relocatible.
We're not "outside of the linux world".
Yes, I sense certain circles around here are striving for "living on the island of RH/Fedora" ;)
You make a big thing out of "features", which we don't need,
That's the point we both repeatedly have clashed:
You are ignoring the API aspect of *.la's - *.la's are meant to be a (semi-standardized) portability layer on top of library implementation details, such as library names, versions, rpath etc.
Removal of any .la from the entire dep-chain bears a very big risk of requiring a rebuild of the entire dep-chain bottom-up plus pruning the spec BR/Reqs, also bottom-up.
This is not a risk - this is a feature.
So what? It means: increased maintenance requirements that sucks.
I beg to differ. Install libs outside of /usr/lib and in parallel to those in /usr/lib and you'll probably pretty soon notice, why RH/Fedora's habits/conventions are troublesome.
From a different view: *.la files aren't much different than *.pc files, in fact they contain a subset of their information. One wouldn't argue to remove all *.pc files because some may contain too many references to libs.
These are broken and partially have their origin in "extreme static linking". (For static linking you need the full chain of -lfoo arguments, as everything else would result in missing symbols).
Wrong: They have their origin in portability. Only fully linking is portable. Packages aiming at portability can not and must not avoid these deps.
Insert comment from above here, too. It's fine from the perspective of the vendor of the source tarball. I've made good use of libtool long ago. Still the "feature bloat" is a hindrance at the RPM packaging level the longer the inter-library dependency-chain becomes.
And? There is a lot of (low quality) SW around, which simply ignore the defacto existing implications of inter-library dependencies on other OSes, and expect other OS to provide the same functionalities as Linux does. libtool only propagates some amount of these packages' bad designs to Linux, you'd be facing almost anywhere else outside of Linux.
That's why I consider Fedora's conventions on "removing *.la's" NOT to be HELPFUL.
Also consider: Any package using libtool by default installs *.la's, any package's author (Note: author, not Fedora package maintainer) has the liberty of removing them upon installation as part of his package's "installation step", if he thinks they are harmful/not useful.
From a practical POV, I can live with package maintainer's removing
*.la's on Fedora, because they are rarely useful on the "island of Fedora", but changing this into "MUST REMOVE", to me is going waaaay too far.
From a developer's POV, if YOU think libtool on Linux's behavior must be
changed to not installing *.la's, I'd propose you to come up with a proposal on the libtool lists and try to have libtool changed in general.
Ralf
On Wed, 2006-10-04 at 06:25 +0200, Ralf Corsepius wrote:
Also consider: Any package using libtool by default installs *.la's, any package's author (Note: author, not Fedora package maintainer) has the liberty of removing them upon installation as part of his package's "installation step", if he thinks they are harmful/not useful.
You're wrong. *.la's provides benefit to upstream. It does not always provide benefits to downstream. Therefore it is downstream which must make the decision whether to remove the .la files.
*.la's guarantee that upstream will get a certain set of features when people try to link against their library and provide a means of portably implementing loadable modules with libltdl. In Fedora these are provided without the *.la files present (as long as the application doesn't explicitly ask for the *.la's which, if the purpose is portability, they shouldn't.) *.la's might make some sense when linking statically, but if our general Fedora Policy is to remove static libraries then our general *.la policy should be removal as well.
If you know of a feature that *.la's provide on Fedora that otherwise is not present, feel free to share it so we can refine the Guidelines to do the right thing.
-Toshio
On Tue, 2006-10-03 at 22:16 -0700, Toshio Kuratomi wrote:
On Wed, 2006-10-04 at 06:25 +0200, Ralf Corsepius wrote:
Also consider: Any package using libtool by default installs *.la's, any package's author (Note: author, not Fedora package maintainer) has the liberty of removing them upon installation as part of his package's "installation step", if he thinks they are harmful/not useful.
You're wrong. *.la's provides benefit to upstream. It does not always provide benefits to downstream. Therefore it is downstream which must make the decision whether to remove the .la files.
If you know of a feature that *.la's provide on Fedora that otherwise is not present,
* library dependencies. * rpath (consider parallel installed package, e.g. openmotif in parallel to lesscrap) * redundancy - Remember: Conflicts between *.la's, *.pc's, ld.so.conf and rpm deps not always are libtool's fault. Esp. *.pc's are MANUALLY written. * Inconsistent flags: Remember *.pc's are manually written. Some people tend to abuse CFlags in *.pcs.
Ralf
On Wed, 2006-10-04 at 07:54 +0200, Ralf Corsepius wrote:
On Tue, 2006-10-03 at 22:16 -0700, Toshio Kuratomi wrote:
On Wed, 2006-10-04 at 06:25 +0200, Ralf Corsepius wrote:
Also consider: Any package using libtool by default installs *.la's, any package's author (Note: author, not Fedora package maintainer) has the liberty of removing them upon installation as part of his package's "installation step", if he thinks they are harmful/not useful.
You're wrong. *.la's provides benefit to upstream. It does not always provide benefits to downstream. Therefore it is downstream which must make the decision whether to remove the .la files.
If you know of a feature that *.la's provide on Fedora that otherwise is not present,
- library dependencies.
We have this already.
- rpath (consider parallel installed package, e.g. openmotif in parallel to lesscrap)
We have this manually, *.la's add it automatically. For the motif case, it seems that lesstif installs to %{_libdir} and has no rpath set so it doesn't need a *.la. openmotif, as a non-Fedora package, is free to install wherever it pleases with whatever rpath it likes and use *.la's to implement its choice. Can you point me to two Fedora packages that need to parallel install libraries?
- redundancy - Remember: Conflicts between *.la's, *.pc's, ld.so.conf
and rpm deps not always are libtool's fault. Esp. *.pc's are MANUALLY written.
- Inconsistent flags: Remember *.pc's are manually written. Some people
tend to abuse CFlags in *.pcs.
Unless I'm misunderstanding what you mean, these are bugs and should be fixed, not ignored because we have *.la's.
-Toshio
On Wed, 2006-10-04 at 00:31 -0700, Toshio Kuratomi wrote:
On Wed, 2006-10-04 at 07:54 +0200, Ralf Corsepius wrote:
On Tue, 2006-10-03 at 22:16 -0700, Toshio Kuratomi wrote:
On Wed, 2006-10-04 at 06:25 +0200, Ralf Corsepius wrote:
Also consider: Any package using libtool by default installs *.la's, any package's author (Note: author, not Fedora package maintainer) has the liberty of removing them upon installation as part of his package's "installation step", if he thinks they are harmful/not useful.
You're wrong. *.la's provides benefit to upstream. It does not always provide benefits to downstream. Therefore it is downstream which must make the decision whether to remove the .la files.
If you know of a feature that *.la's provide on Fedora that otherwise is not present,
- library dependencies.
We have this already.
Where?
All Fedora has is libs somewhere on the file system, being searched for at run-time by ld.so, and searched for by GCC/ld/etc. at link-time with paths being composed by arbitrary "configure scripts".
There is no guarantee run-time deps are satisfied or complete, neither at run-time nor at link-time, but rpm's deps.
=> Without *.la you can exchange (and brake) a libraries/applications dependencies unnoticed.
- rpath (consider parallel installed package, e.g. openmotif in parallel to lesscrap)
We have this manually, *.la's add it automatically. For the motif case, it seems that lesstif installs to %{_libdir} and has no rpath set so it doesn't need a *.la. openmotif, as a non-Fedora package, is free to install wherever it pleases with whatever rpath it likes and use *.la's to implement its choice. Can you point me to two Fedora packages that need to parallel install libraries?
ATM, this case doesn't exist, but it would be easy to construct, e.g. by introducing compat-*devel packages being designed to exist in parallel.
- redundancy - Remember: Conflicts between *.la's, *.pc's, ld.so.conf
and rpm deps not always are libtool's fault. Esp. *.pc's are MANUALLY written.
- Inconsistent flags: Remember *.pc's are manually written. Some people
tend to abuse CFlags in *.pcs.
Unless I'm misunderstanding what you mean, these are bugs and should be fixed, not ignored because we have *.la's.
In a nutshell, I mean "*.pc's are equally broken and not any better than *.la's".
They don't suffer from the same issues as *.la's but they also suffer from defects, e.g. * language specific compiler flags in *.pc * compiler/compiler-version specific compiler flags in *.pc * Incorrect hard-coded libs (-l<something>) * Incorrect (Missing rsp. superfluous) deps (Requires: foo) * pkgconfig not properly separating CPPFLAGS/CFLAGS/CXXFLAGS/FFLAGS * being manually written. * being static (They denote a situation having being valid at one point in time - There is no guarantee it still is, nor that they match ld.so's configuration.). ...
Ralf
On Wed, 04 Oct 2006 10:40:37 +0200, Ralf Corsepius wrote:
In a nutshell, I mean "*.pc's are equally broken and not any better than *.la's".
They don't suffer from the same issues as *.la's but they also suffer from defects, e.g.
- language specific compiler flags in *.pc
- compiler/compiler-version specific compiler flags in *.pc
- Incorrect hard-coded libs (-l<something>)
- Incorrect (Missing rsp. superfluous) deps (Requires: foo)
- pkgconfig not properly separating CPPFLAGS/CFLAGS/CXXFLAGS/FFLAGS
- being manually written.
- being static (They denote a situation having being valid at one point
in time - There is no guarantee it still is, nor that they match ld.so's configuration.). ...
In *many* cases they are much more better/useful, however, because with the pkg-config front-end (man pkg-config) they give very easy access to meta-information of installed packages in a similar way like custom "foo-config" scripts. This makes them an extremely popular choice whereas a big chunk of the "libtool stuff" is transparent to the package author.
Additionally, .pc files in many cases are a strict build-requirement of the software to be built, as else the software set-up utility would not find installed libraries or be unable to use them. Unlike .la files.
All you've come up with above is a list of potential bugs in .pc files without comparing it with a similarly extensive list of potential bugs in .la files.
Sure, a big hindrance of .pc files is also that they suffer badly from the same dep-chain breakage, where "Requires" within a .pc file are not mirrored in the RPM package's "Requires" (neither automatically nor manually). As a result, -devel package users at the root of the dep-chain need to work around missing dependencies exactly as causes by incomplete .la packaging. A difference compared with .la files is that .la files add additional dependencies on absolute paths to other .la files, which makes it much more easy to break the chain, whereas .pc files just create links to other pkg names.
On Oct 4, 2006, Toshio Kuratomi a.badger@gmail.com wrote:
- library dependencies.
We have this already.
Only for dynamic libraries.
If you want to link statically, you still need to list the static dependencies explicitly, and the .la file is where the dependencies are.
Sure enough, most packages don't rely on libtool for that and just take care of finding dependencies themselves, so this is hardly a strong argument to keep the .la files around.
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
| Here's a crazy-but-not-too-far-from-reality example: Build shared-lib | pkg 'b' which links against 'a'. b's .la files now include references | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which | links against 'b', whose own libc.la file includes | references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end | up with a pkg z, and a libz.la, which, when all is said and done, | | * will have a direct dependancy upon y's liby.la | * and because of liby.la file references/dependances, will have | (indirect) dependancies upon liba.la, libb.la, ..., libx.la | | When, generally, *none* of these are really required nor desired.
I'm not sure about that, but maybe I understand something wrongly:
- If -la was needed for building libb, then there exists a real dependency between liba and libb and libb.la is correct about that.
No, this dependency does not need to be handled explicitly with dynamic libraries.
E.g. a dep-tree of
liba.so -> libb.so -> libc.so -> app
would suffice. Having the '-la' in libb.la and '-lb' in libc.la would cause a tree like
--------------------------- / ,---------------- \ / / `v v liba.so -> libb.so -> libc.so -> app \ ^ `----------------'
Unfortunately, widely used tools like 'libtool' or 'cmake' are creating such trees (at least when the libs and apps are in the same project). For 'cmake' there is a workaround to put '-Wl,--as-needed' into the linker flags but for 'libtool' you have to patch ltmain.
A good check to verify cleaness of libraries/binaries is
| ldd -u -r <lib>
This should neither output undefined symbols nor unused direct dependencies.
From a different view: *.la files aren't much different than *.pc files, in fact they contain a subset of their information.
ACK. Often, 'pkgconfig' is used wrongly and contains superflous Requires: resulting into a tree like above.
'pkgconfig' might make sense in providing certain C(PP)FLAGS; but .la files are completely superflous (at least for for dynamic linking).
Enrico
On Mon, Oct 02, 2006 at 02:11:58PM +0200, Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
| Here's a crazy-but-not-too-far-from-reality example: Build shared-lib | pkg 'b' which links against 'a'. b's .la files now include references | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which | links against 'b', whose own libc.la file includes | references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end | up with a pkg z, and a libz.la, which, when all is said and done, | | * will have a direct dependancy upon y's liby.la | * and because of liby.la file references/dependances, will have | (indirect) dependancies upon liba.la, libb.la, ..., libx.la | | When, generally, *none* of these are really required nor desired.
I'm not sure about that, but maybe I understand something wrongly:
- If -la was needed for building libb, then there exists a real dependency between liba and libb and libb.la is correct about that.
No, this dependency does not need to be handled explicitly with dynamic libraries.
E.g. a dep-tree of
liba.so -> libb.so -> libc.so -> app
would suffice. Having the '-la' in libb.la and '-lb' in libc.la would cause a tree like
--------------------------- / ,---------------- \ / / `v vliba.so -> libb.so -> libc.so -> app \ ^ `----------------'
Unfortunately, widely used tools like 'libtool' or 'cmake' are creating such trees (at least when the libs and apps are in the same project). For 'cmake' there is a workaround to put '-Wl,--as-needed' into the linker flags but for 'libtool' you have to patch ltmain.
E.g. you argue that this is a bug in libtool.
So, if libtool were to simply ignore dependency_libs when building against shared libs wouldn't that solve all issues? If so the patch looks almost trivial and is far better than to setup workflows on whether removing some *.la files and still have some false positives/negatives.
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
E.g. a dep-tree of
liba.so -> libb.so -> libc.so -> app
would suffice. Having the '-la' in libb.la and '-lb' in libc.la would cause a tree like
--------------------------- / ,---------------- \ / / `v vliba.so -> libb.so -> libc.so -> app \ ^ `----------------'
Unfortunately, widely used tools like 'libtool' or 'cmake' are creating such trees (at least when the libs and apps are in the same project). For 'cmake' there is a workaround to put '-Wl,--as-needed' into the linker flags but for 'libtool' you have to patch ltmain.
E.g. you argue that this is a bug in libtool.
So, if libtool were to simply ignore dependency_libs when building against shared libs wouldn't that solve all issues?
I do not know whether it would solve all issues, but the bad library-deps should be solved. But how shall such a fix be applied in practice?
1. somebody has to write a patch against ltmain.sh and probably libtool.m4. Quick look into ltmain.sh indicates that this is not a trivial job (some archs do not support indirect linking and need a graph like above).
2. somebody has to convince libtool people to apply this patch. Does not seem to be trivial either (look at the more or less trivial multilib patch in the Red Hat libtool-package which is still not applied).
Because this change is more an improvement than a bugfix and changes behavior significantly, it will be a candidate for upcoming libtool-2 but not for current libtool-1.5.
3. Most upstream authors will not use a beta versions of libtool. Hence, a huge amount of packages will need a 'libtoolize' (or 'autoreconf') against the patched libtool. This is heavily discouraged.
It seems to be much easier to omit *.la files completely because they do not offer anything (which might be relevant for dynamic linking).
If so the patch looks almost trivial and is far better than to setup workflows on whether removing some *.la files and still have some false positives/negatives.
I do not see which workflows are affected. *.la files are an holdover of the last millennium. No recent system requires them.
Enrico
On Mon, Oct 02, 2006 at 03:34:09PM +0200, Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
E.g. a dep-tree of
liba.so -> libb.so -> libc.so -> app
would suffice. Having the '-la' in libb.la and '-lb' in libc.la would cause a tree like
--------------------------- / ,---------------- \ / / `v vliba.so -> libb.so -> libc.so -> app \ ^ `----------------'
Unfortunately, widely used tools like 'libtool' or 'cmake' are creating such trees (at least when the libs and apps are in the same project). For 'cmake' there is a workaround to put '-Wl,--as-needed' into the linker flags but for 'libtool' you have to patch ltmain.
E.g. you argue that this is a bug in libtool.
So, if libtool were to simply ignore dependency_libs when building against shared libs wouldn't that solve all issues?
I do not know whether it would solve all issues, but the bad library-deps should be solved. But how shall such a fix be applied in practice?
- somebody has to write a patch against ltmain.sh and probably libtool.m4. Quick look into ltmain.sh indicates that this is not a trivial job (some archs do not support indirect linking and need a graph like above).
We currently care about Linux, so we'd need that patch for Linux at the beginning. More platforms could add themselves to the whitelist as they see fit.
- somebody has to convince libtool people to apply this patch. Does not seem to be trivial either (look at the more or less trivial multilib patch in the Red Hat libtool-package which is still not applied).
I wouldn't derive from one patch to another. What you perhaps consider trivial and acceptable may be different for the upstream authors and vice versa. I also didn't notice any discussion about the multilib patch on the libtool list, so perhaps this wasn't even submitted?
Because this change is more an improvement than a bugfix and changes behavior significantly, it will be a candidate for upcoming libtool-2 but not for current libtool-1.5.
- Most upstream authors will not use a beta versions of libtool. Hence, a huge amount of packages will need a 'libtoolize' (or 'autoreconf') against the patched libtool. This is heavily discouraged.
This is just our policy. If we decide it serves us better, then it will be changed.
It seems to be much easier to omit *.la files completely because they do not offer anything (which might be relevant for dynamic linking).
If so the patch looks almost trivial and is far better than to setup workflows on whether removing some *.la files and still have some false positives/negatives.
I do not see which workflows are affected. *.la files are an holdover of the last millennium. No recent system requires them.
You missed the beginning of this discussion: There *are* packages of this millenium that break when *.la files are blindly removed. Therefore Rex is trying to setup a workflow of when to omit or not *.la files.
Better fix something than deal with broken stuff after the fact is my opinion. Even if *.la files would had turned out to be completely unneccessary - which they are not, but let's suppose - then it would be better to had libtool patched up.
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
- somebody has to write a patch against ltmain.sh and probably libtool.m4. Quick look into ltmain.sh indicates that this is not a trivial job (some archs do not support indirect linking and need a graph like above).
We currently care about Linux, so we'd need that patch for Linux at the beginning. More platforms could add themselves to the whitelist as they see fit.
Defining and evaluating a 'whitelist' in ltmain.sh might be a problem...
- somebody has to convince libtool people to apply this patch. Does not seem to be trivial either (look at the more or less trivial multilib patch in the Red Hat libtool-package which is still not applied).
I wouldn't derive from one patch to another. What you perhaps consider trivial and acceptable may be different for the upstream authors and vice versa. I also didn't notice any discussion about the multilib patch on the libtool list, so perhaps this wasn't even submitted?
Dunno; patch exists for 4 years already so I would wonder when it was never submitted. I thought, RH packagers were active in libtool development but I might be wrong here.
I do not see which workflows are affected. *.la files are an holdover of the last millennium. No recent system requires them.
You missed the beginning of this discussion: There *are* packages of this millenium that break when *.la files are blindly removed.
Ok; there are some projects from the last millenium which are still requiring .la files. But it should be really trivial to fix them by writing
| lt_dlopenext("libfoo");
instead of
| lt_dlopen("libfoo.la");
Therefore Rex is trying to setup a workflow of when to omit or not *.la files.
.la files do not make sense nowadays and cause harm. E.g. look at '/usr/lib/kde3/textthumbnail.la':
|dependency_libs='... /usr/lib/libidn.la'
What would happen when libidn switches to another buildsystem not producing .la files anymore? RPM deps on libidn.so.11 would be still correct but plugin would suddenly stop to work.
Then: .la files MUST NOT be shipped in the -devel package but in the main one. Else, module loading will fail. I would not like such a rule...
Therefore: remove .la as far as possible and keep them only when they are needed.
Rex's rules (no .la files in LD_LIBRARY_PATH) are ok, but I would see them more as a guideline to decide whether a .la file is really required than as a strict MUST rule.
Better fix something
libtool is unfixable broken; adding features like correct RPATHs, linker flags at proper place (e.g. '-Wl,--as-needed' before libs) or omitting linking of indirect libs would require heavy changes in code which might change the current behavior and break lot of other projects.
Adding a 200k sized bash wrapper around gcc does not seem to be a clever idea either.
Enrico
On Mon, Oct 02, 2006 at 09:01:34PM +0200, Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
- somebody has to write a patch against ltmain.sh and probably libtool.m4. Quick look into ltmain.sh indicates that this is not a trivial job (some archs do not support indirect linking and need a graph like above).
We currently care about Linux, so we'd need that patch for Linux at the beginning. More platforms could add themselves to the whitelist as they see fit.
Defining and evaluating a 'whitelist' in ltmain.sh might be a problem...
Wow, looks like there already exists such a patch and that this patch only changes about a dozen lines. So much for a non-trivial job. ...
http://people.debian.org/~keybuk/keybuk-linux-deplibs.patch
I raised this up on the libtool list, which is probably better than guessing around. Looks like Debian is using this patch for some time now. I was told that this is still not the best way to slice bread, and am waiting for further details.
- somebody has to convince libtool people to apply this patch. Does not seem to be trivial either (look at the more or less trivial multilib patch in the Red Hat libtool-package which is still not applied).
I wouldn't derive from one patch to another. What you perhaps consider trivial and acceptable may be different for the upstream authors and vice versa. I also didn't notice any discussion about the multilib patch on the libtool list, so perhaps this wasn't even submitted?
Dunno; patch exists for 4 years already so I would wonder when it was never submitted. I thought, RH packagers were active in libtool development but I might be wrong here.
Did you take a look at the multilib patch? It breaks other Linux distributions, which is why it was never submitted to libtool-patches. Let's not blame upstream for that.
libtool has just received no love at all in Red Hat land for whatever reason.
On Mon, 2006-10-02 at 21:43 +0200, Axel Thimm wrote:
On Mon, Oct 02, 2006 at 09:01:34PM +0200, Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
- somebody has to convince libtool people to apply this patch. Does not seem to be trivial either (look at the more or less trivial multilib patch in the Red Hat libtool-package which is still not applied).
I wouldn't derive from one patch to another. What you perhaps consider trivial and acceptable may be different for the upstream authors and vice versa. I also didn't notice any discussion about the multilib patch on the libtool list, so perhaps this wasn't even submitted?
Dunno; patch exists for 4 years already so I would wonder when it was never submitted.
I recall an initial version had been submitted several years ago. Due to lack of generality it had never been applied. The RH dev never showed up again afterwards. Seemingly he didn't like what he had got to hear and resorted to "worksforme".
I thought, RH packagers were active in libtool development but I might be wrong here.
Though libtool to a large extend is a RH invention (Alex O. had been one of its key developers), RH devs had been more or less absent in libtool development for many years.
Did you take a look at the multilib patch? It breaks other Linux distributions, which is why it was never submitted to libtool-patches. Let's not blame upstream for that.
libtool has just received no love at all in Red Hat land for whatever reason.
I guess everybody agrees that libtool is mess, but ... it's still the best we've currently got, when it comes to portably building shared libs ;)
Ralf
On Tue, Oct 03, 2006 at 08:00:28AM +0200, Ralf Corsepius wrote:
On Mon, 2006-10-02 at 21:43 +0200, Axel Thimm wrote:
On Mon, Oct 02, 2006 at 09:01:34PM +0200, Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
- somebody has to convince libtool people to apply this patch. Does not seem to be trivial either (look at the more or less trivial multilib patch in the Red Hat libtool-package which is still not applied).
I wouldn't derive from one patch to another. What you perhaps consider trivial and acceptable may be different for the upstream authors and vice versa. I also didn't notice any discussion about the multilib patch on the libtool list, so perhaps this wasn't even submitted?
Dunno; patch exists for 4 years already so I would wonder when it was never submitted.
I recall an initial version had been submitted several years ago. Due to lack of generality it had never been applied. The RH dev never showed up again afterwards. Seemingly he didn't like what he had got to hear and resorted to "worksforme".
He only posted a first attempt on the list and explicitely mentioned that this is not ready for patch submission yet himself. There was no rejection or similar, there was just no momentum to push it further.
I thought, RH packagers were active in libtool development but I might be wrong here.
Though libtool to a large extend is a RH invention (Alex O. had been one of its key developers), RH devs had been more or less absent in libtool development for many years.
To be honest all people from RH that have worked on libtool did so before entering RH, comapring the dates of employment and their activity in libtool one might even assume the contrary ;) (in reality these people were pulled into different tasks like Alexandre going gcc and having to leave libtool behind).
Did you take a look at the multilib patch? It breaks other Linux distributions, which is why it was never submitted to libtool-patches. Let's not blame upstream for that.
libtool has just received no love at all in Red Hat land for whatever reason.
I guess everybody agrees that libtool is mess, but ... it's still the best we've currently got, when it comes to portably building shared libs ;)
And it is the best upstream has, so the argument "on Linux we need no libtool" doesn't carry (not that Ralf says so, I'm just extending his argument). Projects will continue to use libtool and if we want to do something then it's fixing aspects of libtool instead of flaming it.
But as I already said to someone here in PM: Personally I'm not interested in another crusade against windmills, I'm curious about how to improve stuff, but I'm not investing in brain-washing people anymore. ;)
On Oct 3, 2006, Ralf Corsepius rc040203@freenet.de wrote:
Though libtool to a large extend is a RH invention (Alex O. had been one of its key developers), RH devs had been more or less absent in libtool development for many years.
Actually, I inherited maintainership from Gord, who invented libtool, long before I joined Red Hat. And after I joined, I failed to keep up with it except for the first year or so.
On Mon, Oct 02, 2006 at 09:43:26PM +0200, Axel Thimm wrote:
On Mon, Oct 02, 2006 at 09:01:34PM +0200, Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
- somebody has to write a patch against ltmain.sh and probably libtool.m4. Quick look into ltmain.sh indicates that this is not a trivial job (some archs do not support indirect linking and need a graph like above).
We currently care about Linux, so we'd need that patch for Linux at the beginning. More platforms could add themselves to the whitelist as they see fit.
Defining and evaluating a 'whitelist' in ltmain.sh might be a problem...
Wow, looks like there already exists such a patch and that this patch only changes about a dozen lines. So much for a non-trivial job. ...
http://people.debian.org/~keybuk/keybuk-linux-deplibs.patchI raised this up on the libtool list, which is probably better than guessing around. Looks like Debian is using this patch for some time now. I was told that this is still not the best way to slice bread, and am waiting for further details.
OK, after browsing through the Debian bugs related to this patch it looks like there are two issues, both of which are fixable and not really a blocker for Fedora packaging:
o When libtool is told not to remember the dependent libs/rpaths of shared builds, a library being built as a subproject of a build may later be overrideen by an older version of itself under %{_libdir}.
This will never happen in a clean chroot build, but can happen with conventional non-package builds. But this happens outside of libtool anyway, an example is rpm itself that cannot be properly built in presence of rpm-devel. A fix could be a switch to turn this only on for packaging, or a proper permanent fix in libtool.
o Cross-compilation of libs may also lose their rpath and try the system's rpath.
A similar issue like above in a different domain.
Concerning upstream libtool, there is no input from vendors, be it Red Hat, Debian, Fedora etc. to push in patches or enhancements. This is true for multilib and the mentioned patch the same. The reasons look like vendor lazyness.
For example both Debian and Red Hat have their 10-line patches for years in their packages but never properly sumbitted this upstream or even tried to raise the issue to a level where libtool maintainers would address it. In the past there have been some small momentum from the outside, libtoolers then had some _positive_ discussion on the matter, but the feedback was missing.
I think if someone here outlines the issues/desires to upstream then libtool may have both patches plus further needed fixes in upstream really soon. I have started doing so, but I'm not going to fight in fedora-packaging for a lost cause again, I'll let someone else bleed his heart here this time. ;)
Of course that would only affect new upstream tarballs of libtoolized projects, so any packaging using such an improved system libtool on older tarballs would need to libtoolize.
On Mon, 2006-10-02 at 21:01 +0200, Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
You missed the beginning of this discussion: There *are* packages of this millenium that break when *.la files are blindly removed.
Ok; there are some projects from the last millenium which are still requiring .la files. But it should be really trivial to fix them by writing
| lt_dlopenext("libfoo");
instead of
| lt_dlopen("libfoo.la");
arts is an example of a program so broken. I'm attaching a patch that fixes it. It is a little more involved than I'd hoped as arts (and apparently other kde packages) include an older version of libtool with some broken .m4 files for detecting the shared object extension (The first half of this bug: http://bugs.kde.org/show_bug.cgi?id=93359 )
Explanation of patch: *.mcopclass: These files have the name of the module that needs to be loaded. Due to the use of lt_dlopen(), they use libfoo.la. With the switch to lt_dlopenext() these can safely become libfoo.
extensionloader.cc: Here's where we switch from lt_dlopen() to lt_dlopenext().
acinclude.m4, ltdl.m4: Probably only ltdl.m4 needs to be changed here. Basically I replaced the erroroneous detection with the simple check of newer libtools. This step is needed because arts includes its own, somewhat dated, copy of libltdl. Do we want to get rid of that anyway (because we want to use system libraries whenever possible)? Or does arts need this specific version of libltdl for some reason?
With this patch, I am able to build an artsd that doesn't segfault when running other KDE apps that generate sound. It's possible that there are other issues beyond this as I don't normally run KDE. Rex, if you can throw me some problem packages I'll be happy to look into what is causing things to break.
Note that this is not a vote for or against removing .la files when they are used as loadable modules. It's just a patch that demonstrates what has to be done to fix the code to not require .la files.
Also note that according to the wording of the proposed draft, arts would still be in violation even though the shared objects are loadable modules rather than libraries intended for linking.
-Toshio
Toshio Kuratomi wrote:
Explanation of patch:
...
acinclude.m4, ltdl.m4: Probably only ltdl.m4 needs to be changed here. Basically I replaced the erroroneous detection with the simple check of newer libtools. This step is needed because arts includes its own, somewhat dated, copy of libltdl. Do we want to get rid of that anyway (because we want to use system libraries whenever possible)? Or does arts need this specific version of libltdl for some reason?
How's the best way to use a newer/different libltdl? (Naively?) replace arts' libltdl/ with that from /usr/share/libtool/libltdl?
With this patch, I am able to build an artsd that doesn't segfault when running other KDE apps that generate sound. It's possible that there are other issues beyond this as I don't normally run KDE. Rex, if you can throw me some problem packages I'll be happy to look into what is causing things to break.
Install kdemultimedia-extras and try using 'juk' to play audio/music files. Or just login/use kde and all system sounds will use arts as well.
-- Rex
Rex Dieter wrote:
Toshio Kuratomi wrote:
Explanation of patch:
...
acinclude.m4, ltdl.m4: Probably only ltdl.m4 needs to be changed here. Basically I replaced the erroroneous detection with the simple check of newer libtools. This step is needed because arts includes its own, somewhat dated, copy of libltdl. Do we want to get rid of that anyway (because we want to use system libraries whenever possible)? Or does arts need this specific version of libltdl for some reason?
How's the best way to use a newer/different libltdl? (Naively?) replace arts' libltdl/ with that from /usr/share/libtool/libltdl?
Or just: $ libtoolize --ltdl --force ? (:
-- Rex
On Tue, 2006-10-03 at 14:54 -0500, Rex Dieter wrote:
Rex Dieter wrote:
Toshio Kuratomi wrote:
Explanation of patch:
...
acinclude.m4, ltdl.m4: Probably only ltdl.m4 needs to be changed here. Basically I replaced the erroroneous detection with the simple check of newer libtools. This step is needed because arts includes its own, somewhat dated, copy of libltdl. Do we want to get rid of that anyway (because we want to use system libraries whenever possible)? Or does arts need this specific version of libltdl for some reason?
How's the best way to use a newer/different libltdl? (Naively?) replace arts' libltdl/ with that from /usr/share/libtool/libltdl?
Or just: $ libtoolize --ltdl --force ? (:
My recommendation for best is to use what's installed by the system libtool-ltdl(-devel). Without knowing why KDE packages are including a local copy of ltdl in the first place, though, I don't know whether this would be a change welcomed or refused by upstream. (If rejected, your other suggestions would work as well.)
-Toshio
P.S. I'll try out juk later this week.
On Oct 2, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
So, if libtool were to simply ignore dependency_libs when building against shared libs wouldn't that solve all issues?
Nope, it would only solve the common case.
It is perfectly possible for a dynamic library to depend on a static-only library. And it's even possible to create other dynamic libraries out of that, if the static-only library is PIC or the platform can handle non-PIC in dynamic libraries.
If so the patch looks almost trivial and is far better than to setup workflows on whether removing some *.la files and still have some false positives/negatives.
Breaking the libtool sources that get installed for packagers all over the world to use, for deployment on various operating systems, is not really an option I'd recommend.
On Thu, Oct 05, 2006 at 02:15:58AM -0300, Alexandre Oliva wrote:
On Oct 2, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
So, if libtool were to simply ignore dependency_libs when building against shared libs wouldn't that solve all issues?
Nope, it would only solve the common case.
It is perfectly possible for a dynamic library to depend on a static-only library. And it's even possible to create other dynamic libraries out of that, if the static-only library is PIC or the platform can handle non-PIC in dynamic libraries.
So? That's not a problem with the mentioned patch.
If so the patch looks almost trivial and is far better than to setup workflows on whether removing some *.la files and still have some false positives/negatives.
Breaking the libtool sources that get installed for packagers all over the world to use, for deployment on various operating systems, is not really an option I'd recommend.
Nobody suggested breaking anything.
On Oct 5, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
On Thu, Oct 05, 2006 at 02:15:58AM -0300, Alexandre Oliva wrote:
On Oct 2, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
So, if libtool were to simply ignore dependency_libs when building against shared libs wouldn't that solve all issues?
Nope, it would only solve the common case.
It is perfectly possible for a dynamic library to depend on a static-only library. And it's even possible to create other dynamic libraries out of that, if the static-only library is PIC or the platform can handle non-PIC in dynamic libraries.
So? That's not a problem with the mentioned patch.
Ignoring dependency_libs would break the following case:
- libA.la, static only, provides symbol A
- libB.la is linked with libA but doesn't bring in symbol A
- program links with libB rightfully expecting it to provide a definition for A
Alexandre Oliva wrote:
On Oct 5, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
So? That's not a problem with the mentioned patch.
Ignoring dependency_libs would break the following case:
- libA.la, static only...
Right, but: 1. That's why I mentioned on the libtool ml that the patch should only apply in non-static lib cases (though I haven't the foggiest the complications involved in implementing that). 2. Good thing we don't package static libs (or at least *strongly* discouraged).
-- Rex
On Oct 6, 2006, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
On Oct 5, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
So? That's not a problem with the mentioned patch.
Ignoring dependency_libs would break the following case:
- libA.la, static only...
- Good thing we don't package static libs (or at least *strongly*
discouraged).
This is too narrow a vision.
Fedora is a major development platform for packages that ship libtool-using packages for many different platforms.
If we break libtool such that it still works for us, but won't work for others, people who develop their packages on Fedora will think libtool will get them the portability they expect, but it won't because Fedora broke the portability.
Thinking of Fedora-only changes for libtool is completely missing the point about how libtool is used.
Alexandre Oliva wrote:
- Good thing we don't package static libs (or at least *strongly*
discouraged).
This is too narrow a vision.
Fedora is a major development platform for packages that ship libtool-using packages for many different platforms.
If we break libtool such that it still works for us
I fail to see how simply not including static libs (or needless .la files) in rpms shipped in Fedora, yields the conclusion that we're breaking libtool.
Or, are you arguing against the existing "no static lib" policy?
-- Rex
On Oct 12, 2006, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
- Good thing we don't package static libs (or at least *strongly*
discouraged).
This is too narrow a vision.
Fedora is a major development platform for packages that ship libtool-using packages for many different platforms.
If we break libtool such that it still works for us
I fail to see how simply not including static libs (or needless .la files) in rpms shipped in Fedora, yields the conclusion that we're breaking libtool.
It doesn't. It's what you snipped out of my response that clarifies that I objected to a patch to ignore dependency_libs, because *that* would break libtool on other OSes, even though it would make no visible difference for us.
Or, are you arguing against the existing "no static lib" policy?
No, I'm not arguing against the "no static lib" policy, and I'm not arguing against removing .la files. I'm only arguing against patching libtool in ways that have negative consequences for other OSes, because this would affect Fedora users that develop on Fedora and expect the libtool in it to deliver them portability to other OSes.
Alexandre Oliva wrote:
I'm not arguing against the "no static lib" policy, and I'm not arguing against removing .la files. I'm only arguing against patching libtool in ways that have negative consequences for other OSes, because this would affect Fedora users that develop on Fedora and expect the libtool in it to deliver them portability to other OSes.
Ah, and you must've missed that I qualified the use of ignoring dependancy_libs only on platforms that *can* (ie, linux) and not using it in the case of static linking. (:
-- Rex
On Oct 12, 2006, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
I'm not arguing against the "no static lib" policy, and I'm not arguing against removing .la files. I'm only arguing against patching libtool in ways that have negative consequences for other OSes, because this would affect Fedora users that develop on Fedora and expect the libtool in it to deliver them portability to other OSes.
Ah, and you must've missed that I qualified the use of ignoring dependancy_libs only on platforms that *can* (ie, linux)
You can only given a very specific set of assumptions, such as no static libs, no non-default lib dirs. There's nothing GNU/Linux-specific about that. The same probably applies to any recent ELF platforms.
and not using it in the case of static linking. (:
Point still holds that, if a patch to improve libtool in this regard is available, it shouldn't be in our copy of libtool only, it should be upstream, because it's useful for everybody, and then we don't get the heat if our patch accidentally breaks libtool's portability features for other OSes.
On Oct 2, 2006, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
- If -la was needed for building libb, then there exists a real
dependency between liba and libb and libb.la is correct about that.
No, this dependency does not need to be handled explicitly with dynamic libraries.
And it's actually harmful if you move the .so link to the -devel package, which is the general recommendation.
Consider that foo-devel provides libfoo.so, which is a link to libfoo.so.0 provided by foo-libs.
Consider that libfoo.so.0 depends on libbar.so.0, provided by bar-libs.
If you link with -lfoo without libtool, it just works.
If you link with -lfoo with libtool, and libtool finds the .la file that lists -lbar as a dependency of libfoo.la, then you lose unless you list bar-devel as a dependency of foo-devel.
Is the absence of such an otherwise-unnecessary dependency a bug in package foo?
On Tue, 2006-09-26 at 10:53 -0500, Rex Dieter wrote:
See http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives
Comments?
-INF
It's a fault to remove *.la's.
Ralf
Ralf Corsepius wrote:
On Tue, 2006-09-26 at 10:53 -0500, Rex Dieter wrote:
See http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives Comments?
It's a fault to remove *.la's.
Thanks so much for the constructive input.
-- Rex
Rex Dieter wrote:
Ralf Corsepius wrote:
On Tue, 2006-09-26 at 10:53 -0500, Rex Dieter wrote:
See http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives Comments?
It's a fault to remove *.la's.
Thanks so much for the constructive input.
Or put another way, do you have any better suggestions to workaround the problems introduced by not omitting .la files?
-- Rex
On Mon, 2006-10-02 at 07:51 -0500, Rex Dieter wrote:
Ralf Corsepius wrote:
On Tue, 2006-09-26 at 10:53 -0500, Rex Dieter wrote:
See http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives Comments?
It's a fault to remove *.la's.
Thanks so much for the constructive input.
What do you expect as an answer to somebody who has been and is spreading FUD on libtool for a very long time, has a web page called "libtool sucks" and despite the fact he is agitating against libtool, has NEVER EVER shown up on any libtool list, nor reported a bug?
If you have got something to say against libtool, report it upstream or stop this foul propaganda.
Ralf
Ralf Corsepius wrote:
On Mon, 2006-10-02 at 07:51 -0500, Rex Dieter wrote:
Ralf Corsepius wrote:
On Tue, 2006-09-26 at 10:53 -0500, Rex Dieter wrote:
See http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives Comments?
It's a fault to remove *.la's.
Thanks so much for the constructive input.
What do you expect as an answer to somebody who has been and is spreading FUD on libtool for a very long time, has a web page called "libtool sucks" ...
So, if I retitled the webpage "libtool rocks! (except when dealing with .la files in rpm packaging)" would that help? (Hmm... sounds good, I think I'll do that anyway)
Regardless, there are *real* problems outlined and addressed in this proposal and said webpage. If I've made errors/omissions, please point them out, but jumping on a soapbox and yelling "FUD!" isn't helping anyone.
-- Rex
Revisting the root of evil. What exactly is wrong with not removing all *.la files? Bloated dependencies in *-devel packages? If that's the only reason, was the (ongoing) pain worth the trouble?
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
Revisting the root of evil. What exactly is wrong with not removing all *.la files?
- .la files must be shipped in main package, not in -devel - they add untracked dependencies to the rpm packages: when B was built against A which has libA.la, B will stop to work when A does not ship libA.la anymore (e.g. because it uses now cmake). - .la files are not required
Enrico
On Thu, Oct 12, 2006 at 12:58:24PM +0200, Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
Revisting the root of evil. What exactly is wrong with not removing all *.la files?
- .la files must be shipped in main package, not in -devel
Obviously "must" is the wrong word since they are currently nuked away. And the issue seems to be when using the information on the dependent libraries inside which only affects *-devel files independent whether *.la is part of the main or the *-devel file.
E.g. keep the *.la if you like in the main packge or elsewhere, the issue is still only "bloat in BRs in *-devel". Do you agree?
- they add untracked dependencies to the rpm packages: when B was built against A which has libA.la, B will stop to work when A does not ship libA.la anymore (e.g. because it uses now cmake).
It will also break when libA changes the soname, an API, add/remove include files and the like. And changes to the build system of a package are certainly far less often than changes to it' API/ABI, so we can certainly live with that.
- .la files are not required
Seems to really depend on the software generating/using them. Or from a different viewpoint: if they really were not required (on Linux), then why are libtool authors installing them (on Linux)? We wouldn't be having this thread if the simple statement ".la files are not required" would indeed hold true.
So ATM I'm still not convinced that there is any other drawback than a couple too many BRs on *-devel packages. And IMHO that doesn't compare to the pain and complexity we have created in having packagers selectively judge on the necessity or not of *.la files. I just saw yet another report on fedora-list that is induced by removing *.la files on some packages and not all.
And to mention it again: The libtool authors are open to any improvement that would please us. Some patches that do 95% of what we want are already floating around or are even in production at other distributions.
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
Revisting the root of evil. What exactly is wrong with not removing all *.la files?
- .la files must be shipped in main package, not in -devel
Obviously "must" is the wrong word since they are currently nuked away.
Sentence was written under the assumption that all .la files will be shipped (as suggested by your question).
And the issue seems to be when using the information on the dependent libraries inside which only affects *-devel files independent whether *.la is part of the main or the *-devel file.
No; modules (which are non-devel files) can contain something like
| dependency_libs='... /usr/lib/libkickermain.la ...'
--> non-devel file requires .la file --> .la files must not be in -devel package
E.g. keep the *.la if you like in the main packge or elsewhere, the issue is still only "bloat in BRs in *-devel". Do you agree?
When it would be only the small .la file in -devel, I agree.
But I have problems with shipping a useless file without a good reason in -lib packages.
- they add untracked dependencies to the rpm packages: when B was built against A which has libA.la, B will stop to work when A does not ship libA.la anymore (e.g. because it uses now cmake).
It will also break when libA changes the soname, an API, add/remove include files and the like.
rpm would bark loudly about broken dependencies in these casees.
- .la files are not required
Seems to really depend on the software generating/using them. Or from a different viewpoint: if they really were not required (on Linux), then why are libtool authors installing them (on Linux)?
I know exactly one case where they are required: when software uses 'lt_dlopen("foo.la")'.
This can be fixed easily by writing 'lt_dlopenext("foo")'.
Installing .la files happens probably only due to legacy reasons.
We wouldn't be having this thread if the simple statement ".la files are not required" would indeed hold true.
See above about lt_dlopen(); KDE (which requires .la) moved away from .la recently.
Enrico
On Thu, Oct 12, 2006 at 04:00:24PM +0200, Enrico Scholz wrote:
E.g. keep the *.la if you like in the main packge or elsewhere, the issue is still only "bloat in BRs in *-devel". Do you agree?
When it would be only the small .la file in -devel, I agree.
The question on agreeing wasn't on putting it in *-devel or whereever, it was on whether the final issue is simply "bloat in BRs in *-devel" or more. Still agree?
- they add untracked dependencies to the rpm packages: when B was built against A which has libA.la, B will stop to work when A does not ship libA.la anymore (e.g. because it uses now cmake).
It will also break when libA changes the soname, an API, add/remove include files and the like.
rpm would bark loudly about broken dependencies in these casees.
Indeed? You never hit any funny bugs where gcc happily *warns* you about missing include files and continues to build?
- .la files are not required
Seems to really depend on the software generating/using them. Or from a different viewpoint: if they really were not required (on Linux), then why are libtool authors installing them (on Linux)?
I know exactly one case where they are required: when software uses 'lt_dlopen("foo.la")'.
This can be fixed easily by writing 'lt_dlopenext("foo")'.
Is this portable, so that upstream can accept this? What about the normal libtool use where it is required? Removing *.la means that you need to take care of adding non-trivial required flags to the linker manually. E.g. any ISV/IHV packaging under /opt (as the standards tell him to) suddenly needs special handling only for Fedora because we kill *.la.
Installing .la files happens probably only due to legacy reasons.
Not really. That would imply that the libtool folks are too dumb to track modern development which is not the case. I raised the issue last week or so and the people there seem knowledgeable enough on it. See also Alexandre's replies to this thread.
See also my initial replies to this list discussing about if la files were legacy indeed, that this should be reflected by adapting libtool, not nuking-after-the-fact.
We wouldn't be having this thread if the simple statement ".la files are not required" would indeed hold true.
See above about lt_dlopen(); KDE (which requires .la) moved away from .la recently.
Check fedora-list for packages breaking outside of kde world, I just saw a report yesterday again. The nuke-la solution has created more problems than it thought it solved.
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
E.g. keep the *.la if you like in the main packge or elsewhere, the issue is still only "bloat in BRs in *-devel". Do you agree?
When it would be only the small .la file in -devel, I agree.
The question on agreeing wasn't on putting it in *-devel or whereever, it was on whether the final issue is simply "bloat in BRs in *-devel" or more. Still agree?
no
Final issues are, whether we want useless files with sideeffects in main packages.
Another issue: .la files are slowing down library loading significantly because a text file must parsed additionally, instead of interpreting an ELF header.
- they add untracked dependencies to the rpm packages: when B was built against A which has libA.la, B will stop to work when A does not ship libA.la anymore (e.g. because it uses now cmake).
It will also break when libA changes the soname, an API, add/remove include files and the like.
rpm would bark loudly about broken dependencies in these casees.
Indeed? You never hit any funny bugs where gcc happily *warns* you about missing include files and continues to build?
Include files are a documented part of an API. .la files are stuff where most developers are unaware of its existence and do not care about it.
I know exactly one case where they are required: when software uses 'lt_dlopen("foo.la")'.
This can be fixed easily by writing 'lt_dlopenext("foo")'.
Is this portable, so that upstream can accept this?
yes
What about the normal libtool use where it is required?
Which "normal use"? libtool .la files:
* might be required for static linking where static libs have dependencies.
--> this is discouraged in Fedora and there exist more powerful alternatives (pkgconfig)
* might be required when architecture supports flat library dependencies only (e.g. on Darwin)
--> uninteresting for Fedora and there exist more powerful alternatives (pkgconfig)
* are used internally when building a package consisting of multiple libs and/or applications
--> uninteresting for packaging
* are required for 'lt_dlopen("foo.la")'
--> can be replaced by 'lt_dlopenext("foo")'
Removing *.la means that you need to take care of adding non-trivial required flags to the linker manually.
Due to reordering of linker options by libtool, only '-l' and '-L' make sense in linker flags.
Most dynamic libs should not need '-l' overall and pkgconfig provides the same (and more) functionality.
E.g. any ISV/IHV packaging under /opt
I do not see, how /opt fits into any Fedora packaging discussion...
(as the standards tell him to) suddenly needs special handling only for Fedora because we kill *.la.
Installing .la files happens probably only due to legacy reasons.
Not really. That would imply that the libtool folks are too dumb to track modern development
lt_dlopenext() was probably added while tracking modern development.
Declaring a (former) elementary feature (installed .la files) as obsolete requires a quorum and convincing reasons which cover all possible use cases.
For Fedora, we can ignore use cases like static linking and flat library dependencies.
See above about lt_dlopen(); KDE (which requires .la) moved away from .la recently.
Check fedora-list for packages breaking outside of kde world, I just saw a report yesterday again. The nuke-la solution has created more problems than it thought it solved.
I would make it a packager's decision whether he adds a small patch (lt_dlopenext()) or whether he packages .la files.
Enrico
Axel Thimm wrote:
So ATM I'm still not convinced that there is any other drawback than a couple too many BRs on *-devel packages.
It's more than a "couple too many BRs", some complex pkgs would/could get 10+. For one concrete example, see kdelibs: http://bugzilla.redhat.com/170602
Take this to an extreme, and we might as well go back to dropping the minimal buildroot and simply do BuildRequires: world for everything.
-- Rex
On Thu, Oct 12, 2006 at 09:31:20AM -0500, Rex Dieter wrote:
Axel Thimm wrote:
So ATM I'm still not convinced that there is any other drawback than a couple too many BRs on *-devel packages.
It's more than a "couple too many BRs", some complex pkgs would/could get 10+. For one concrete example, see kdelibs: http://bugzilla.redhat.com/170602
Take this to an extreme, and we might as well go back to dropping the minimal buildroot and simply do BuildRequires: world for everything.
I haven't really checked on what is considered a minimal buildroot these days, but I think nothing in it even comes close to kdelibs :)
The issue with a couple more BR or a dozen for some packages like kdelibs just mean that for some chroot builds the build system would install a couple (or dozen) too many *-devel packages (along with the mandatory in both cases non devel packages). The drawback is that these packages will need a couple of seconds more to build. Do we really care?
On Oct 12, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
Seems to really depend on the software generating/using them. Or from a different viewpoint: if they really were not required (on Linux), then why are libtool authors installing them (on Linux)? We wouldn't be having this thread if the simple statement ".la files are not required" would indeed hold true.
They're part of the portable libtool library abstraction. Removing them means you give up some of the portability. On GNU/Linux, with the further constraint of not using static libraries, and only installing libraries in directories searched by both ld and ld.so, you don't lose or miss anything.
On Thu, Oct 12, 2006 at 05:01:03PM -0300, Alexandre Oliva wrote:
On Oct 12, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
Seems to really depend on the software generating/using them. Or from a different viewpoint: if they really were not required (on Linux), then why are libtool authors installing them (on Linux)? We wouldn't be having this thread if the simple statement ".la files are not required" would indeed hold true.
They're part of the portable libtool library abstraction. Removing them means you give up some of the portability.
Pretending not to have read the following restricting paragraph: If *.la files were indeed unnecessary/redundant on a platform, let's call it *-redhat-no-static-linux-gnu, then *.la file installation could be skipped. But since we only think we live on such a platform this isn't happening.
On GNU/Linux, with the further constraint of not using static libraries, and only installing libraries in directories searched by both ld and ld.so, you don't lose or miss anything.
So you would lose on /opt and if some lib needs static linking, and this decision is non-local as you properly explained in some other part of this thread. E.g. we would globally remove degrees of freedom for little gain.
On Oct 12, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
On Thu, Oct 12, 2006 at 05:01:03PM -0300, Alexandre Oliva wrote:
On GNU/Linux, with the further constraint of not using static libraries, and only installing libraries in directories searched by both ld and ld.so, you don't lose or miss anything.
So you would lose on /opt and if some lib needs static linking, and this decision is non-local as you properly explained in some other part of this thread. E.g. we would globally remove degrees of freedom for little gain.
Right. Keeping the .la files for these rare cases makes a lot of sense to me. I get the impression they never occur in Fedora packages (I mean Core and Extras here, not packages *for* Fedora), so the Fedora policy might very well rule out .la files entirely, even if with a rationale explaining the assumptions behind it and recommendations about when to break this rule in third-party packages.
On Oct 12, 2006, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
Revisting the root of evil. What exactly is wrong with not removing all *.la files?
- .la files must be shipped in main package, not in -devel
Only if users of the library rely on libltdl and explicitly refer to the .la files.
- they add untracked dependencies to the rpm packages: when B was built against A which has libA.la, B will stop to work when A does not ship libA.la anymore (e.g. because it uses now cmake).
rpm might be improved to track such dependencies automatically. Or the package ought to list its dependencies explicitly. That's just a packaging bug. Quite inconvenient, I agree.
But if A changes its interface by removing the .la file (and that is a change of interface for libtool users), then someone must deal with the consequences. It's not really much different from renaming a library or a header file or moving them to a different directory. Users (as in dependent packages, not people who run the software) are affected by such changes, and that's unfortunate.
But it's not libtool that is to blame, it's the removal of the .la file, that was in place before and went missing, and the absence of an rpm dependency reflecting the actual dependency given by the .la files.
If you remove a header file from a library, users of that header file will lose just the same.
- .la files are not required
In the absence of static libraries, on GNU/Linux systems, they aren't, indeed.
In their presence, given a few additional constraints that are relatively easy to comply with, it makes things a bit smaller and faster, so the move is probably a reasonable step, in spite kf the breakage that the removal of interface files (I'm talking about the .la files) is going to cause.
Alexandre Oliva aoliva@redhat.com writes:
Revisting the root of evil. What exactly is wrong with not removing all *.la files?
- .la files must be shipped in main package, not in -devel
Only if users of the library rely on libltdl and explicitly refer to the .la files.
no; when some package contains a dynamic loadable module with .la files, this .la file will be used for dependency resolving. When such a dependency is expressed as
| dependency_libs='... /usr/lib/libkickermain.la ...'
'libkickermain.la' must be a main package but not in -devel.
Because a library can be linked against arbitrary .la modules, a library must either remove .la files completely or ship them in the main package.
Enrico
On Oct 12, 2006, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
Alexandre Oliva aoliva@redhat.com writes:
Revisting the root of evil. What exactly is wrong with not removing all *.la files?
- .la files must be shipped in main package, not in -devel
Only if users of the library rely on libltdl and explicitly refer to the .la files.
no; when some package contains a dynamic loadable module with .la files, this .la file will be used for dependency resolving.
Err... I don't follow. Is this any different from the libltdl case I mentioned above?
When such a dependency is expressed as
| dependency_libs='... /usr/lib/libkickermain.la ...'
'libkickermain.la' must be a main package but not in -devel.
Aah, I think I see what you mean.
libfoo.la is a loadable module.
libbar.la is a library in a separate package that libfoo.la was linked with.
Someone lt_dlopenext()s libfoo, and that fails if libbar.la is not available.
Is this what you mean?
If you, you're right. I hadn't considered this case.
That said, if libbar.la had never had its .la file present at libfoo's build time, libfoo.la couldn't possibly refer to libbar.la.
/me wonders if his reasoning breaks if both libfoo and libbar are in the same package. In this case, libfoo.la might refer to libbar.la, indeed. But then, since they're both part of the same build, that's a single spec file, and one might easily arrange to keep libbar.la installed. So indeed there may have to be an exception to the rule for this case.
Unless you also remove the libfoo.la, and call it a bug if any package that relies on lt_dlopen("libfoo.la"), instead of lt_dlopenext("libfoo"). Then, you can do away with the .la files even in this case.
Right? Or am I still missing anything?
Because a library can be linked against arbitrary .la modules, a library must either remove .la files completely or ship them in the main package.
I don't think this follows. It does hold that they probably ought to be in the same package, or arranged such that the package containing libfoo.la requires that containing libbar.la. But I still fail to see a need for the .la file in the main package, except for lt_dlopen("libfoo.la")
Alexandre Oliva aoliva@redhat.com writes:
- .la files must be shipped in main package, not in -devel
... Aah, I think I see what you mean.
libfoo.la is a loadable module.
libbar.la is a library in a separate package that libfoo.la was linked with.
Someone lt_dlopenext()s libfoo, and that fails if libbar.la is not available.
Is this what you mean?
yes
/me wonders if his reasoning breaks if both libfoo and libbar are in the same package.
no; 'libbar.la' might be used by a 'libbaz.la' loadable module which is added to the repository a year later by a different maintainer.
Therefore, 'libbar.la' must be handled like 'libbar.so.0' and must be in the main package but not in devel.
Because a library can be linked against arbitrary .la modules, a library must either remove .la files completely or ship them in the main package.
I don't think this follows. It does hold that they probably ought to be in the same package, or arranged such that the package containing libfoo.la requires that containing libbar.la.
Exactly. Because (usually) main packages (e.g. this with 'libfoo.la') must not depend on -devel packages, the required 'libbar.la' must not be in -devel but in a main package.
Automatic dependencies (by interpreting 'dependency_libs') will prevent silent breakage but do not change this rule. Checking only the current state of the repository does not help. There exists always the chance that 'libX.la' is used later by some loadable module (which is shipped in a main package).
Enrico
Enrico Scholz wrote:
Alexandre Oliva aoliva@redhat.com writes:
- .la files must be shipped in main package, not in -devel
... Aah, I think I see what you mean.
libfoo.la is a loadable module.
libbar.la is a library in a separate package that libfoo.la was linked with.
Someone lt_dlopenext()s libfoo, and that fails if libbar.la is not available.
Is this what you mean?
yes
In my experience, this only fails if libfoo has undefined symbols.
-- Rex
On Oct 13, 2006, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
Alexandre Oliva aoliva@redhat.com writes:
/me wonders if his reasoning breaks if both libfoo and libbar are in the same package.
no; 'libbar.la' might be used by a 'libbaz.la' loadable module which is added to the repository a year later by a different maintainer.
Not if libbar.la was not installed.
Exactly. Because (usually) main packages (e.g. this with 'libfoo.la') must not depend on -devel packages, the required 'libbar.la' must not be in -devel but in a main package.
But if you add the .la to the main package, that brings in references to the .so and .a files, if present, so you'd then have to add the undesired dependency.
On Oct 13, 2006, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
aoliva@redhat.com (Alexandre Oliva) writes:
no; 'libbar.la' might be used by a 'libbaz.la' loadable module which is added to the repository a year later by a different maintainer.
Not if libbar.la was not installed.
So you suggest to avoid packaging of .la files?
I understand that was the proposal on the table, and I don't see reasons against that given the constraints exposed so far. It's not my suggestion, and I wouldn't say I actively promote it, but I don't mind it, and I did mind arguments that were brought up against it, so I voiced my opinion against the arguments ;-)
On Sat, Oct 14, 2006 at 03:53:01AM -0300, Alexandre Oliva wrote:
On Oct 13, 2006, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
aoliva@redhat.com (Alexandre Oliva) writes:
no; 'libbar.la' might be used by a 'libbaz.la' loadable module which is added to the repository a year later by a different maintainer.
Not if libbar.la was not installed.
So you suggest to avoid packaging of .la files?
I understand that was the proposal on the table, and I don't see reasons against that given the constraints exposed so far. It's not my suggestion, and I wouldn't say I actively promote it, but I don't mind it, and I did mind arguments that were brought up against it, so I voiced my opinion against the arguments ;-)
How about fixing the issues we *think* we have with *.la files upstream, so that we don't even have to undo what libtool does? Alexandre seems to have the best insight of libtool and our issues with *.la around here, so he could setup the specs of what we'd like to see improved in libtool and open up a dialogue with the current libtool maintainers.
The outcome for me is that the "drawback" of keeping *.la files unconditionally is that some *.devel files get a couple too many BRs, and a very few (like kdelibs) get a dozen too many. That doesn't break any minimal buildroots, it simply adds a few seconds during build time (note that the non devel parts of the dependent libs are installed during the builds anyway).
Compared to that we have random breakage in some packages eating up developer and user time and endless discussions on lists. So let the build systems spend a couple of CPU seconds instead. ;)
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
The outcome for me is that the "drawback" of keeping *.la files unconditionally is that some *.devel files get a couple too many BRs, and a very few (like kdelibs) get a dozen too many.
... and that you have to put .la files into main packages (which is adding untracked dependencies) and you slow down module loading...
Enrico
On Sat, Oct 14, 2006 at 01:05:25PM +0200, Enrico Scholz wrote:
... and that you have to put .la files into main packages (which is adding untracked dependencies) and you slow down module loading...
You are exaggerating. How did RHL, RHEL and FC survive so far?
o Can you show a list of bugs related to main packages missing *.la files to compare the pains? And doesn't this contradict your statement "*.la files are unneccessary"? So your complete statement is "*.la files are unneccessary, but they are required in the main package"? Simple logic implies that then the main package is unneccessary, too. ;)
o How many milliseconds are we losing for module loading through *.la files? How much faster in percentage do the modules load w/o *.la files? Are we really going to compare a few hundred ms to several seconds, especially in light of where dynamic module loading is really used? Are we then going to rebuild Fedora based on dietlibc to gain a couple seconds, too?
No, I think the pain and *.la-micro-surgery needs to end. Get *.la files back and address any remaining issues with libtool upstream. We can live with a couple more BR in *-devel until this gets resolved. We did so for several years.
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
... and that you have to put .la files into main packages (which is adding untracked dependencies) and you slow down module loading...
o Can you show a list of bugs related to main packages missing *.la files to compare the pains? And doesn't this contradict your statement "*.la files are unneccessary"?
AGAIN (and citing [1]): Sentence was written under the assumption that all .la files will be shipped.
When .la will not be shipped they do not need to be in main packages (nor in -devel ones) because they are not shipped.
o How many milliseconds are we losing for module loading through *.la files? How much faster in percentage do the modules load w/o *.la files?
Dunno. But we can save these few milliseconds without any costs by removing the .la files.
Enrico
Footnotes: [1] https://www.redhat.com/archives/fedora-packaging/2006-October/msg00062.html
On Sat, Oct 14, 2006 at 01:47:08PM +0200, Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
... and that you have to put .la files into main packages (which is adding untracked dependencies) and you slow down module loading...
o Can you show a list of bugs related to main packages missing *.la files to compare the pains? And doesn't this contradict your statement "*.la files are unneccessary"?
AGAIN (and citing [1]): Sentence was written under the assumption that all .la files will be shipped.
When .la will not be shipped they do not need to be in main packages (nor in -devel ones) because they are not shipped.
The standard procedure until now is to have *.la files in *-devel files and only have *.la files for dlopen in the main packages. That's what is being discussed.
o How many milliseconds are we losing for module loading through *.la files? How much faster in percentage do the modules load w/o *.la files?
Dunno. But we can save these few milliseconds without any costs by removing the .la files.
Gosh, asserting on every mail that there are no issues with removing *.la files won't make that turn to truth. In fact if you present your arguments as biased I (and others) can't judge on the validity of any of your argumentation.
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
... and that you have to put .la files into main packages (which is adding untracked dependencies) and you slow down module loading...
... The standard procedure until now is to have *.la files in *-devel files
no; standard procedure until now is to remove .la files.
When we allow .la files when they are not needed, then they must be in main packages, not in -devel. This thread shows why.
Enrico
On Sat, Oct 14, 2006 at 02:05:17PM +0200, Enrico Scholz wrote:
then they must be in main packages, not in -devel. This thread shows why.
Makes one wonder how RHL/RHEL/FC worked w/o doing so. Or given that they did work one wonders what makes you say that.
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
then they must be in main packages, not in -devel. This thread shows why.
Makes one wonder how RHL/RHEL/FC worked w/o doing so.
'rpm -qf /usr/lib/*.la' tells that there is no rule how FC is packaging .la.
Packaging in main instead of -devel seems to be the preferred method; and it seems that this is intentionally:
| * Wed Mar 05 2003 Than Ngo than@redhat.com 1.1-8 | - move la files in arts package (bug #83607)
Enrico
Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
then they must be in main packages, not in -devel. This thread shows why.
Makes one wonder how RHL/RHEL/FC worked w/o doing so.
'rpm -qf /usr/lib/*.la' tells that there is no rule how FC is packaging .la.
Packaging in main instead of -devel seems to be the preferred method; and it seems that this is intentionally:
| * Wed Mar 05 2003 Than Ngo than@redhat.com 1.1-8 | - move la files in arts package (bug #83607)
No, arts (and kde bits in general) are an exception, don't use them to draw generalities. In fact, in general, .la files (associated with shared libs, no loadable modules), if packaged at all, belong in -devel.
-- Rex
rdieter@math.unl.edu (Rex Dieter) writes:
then they must be in main packages, not in -devel. This thread shows why.
... No, arts (and kde bits in general) are an exception, don't use them to draw generalities. In fact, in general, .la files (associated with shared libs, no loadable modules), if packaged at all, belong in -devel.
No; .la files can be referred by .la modules and must be in main therefore (for Axel: when packaged at all). See rest of the thread.
Enrico
Enrico Scholz wrote:
rdieter@math.unl.edu (Rex Dieter) writes:
then they must be in main packages, not in -devel. This thread shows why.
... No, arts (and kde bits in general) are an exception, don't use them to draw generalities. In fact, in general, .la files (associated with shared libs, no loadable modules), if packaged at all, belong in -devel.
No; .la files can be referred by .la modules and must be in main therefore (for Axel: when packaged at all). See rest of the thread.
Yeah, I read it, and I disagreed then (and still do), but hadn't bothered to reply until now.
-- Rex
On Sat, 2006-10-14 at 13:05 +0200, Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
The outcome for me is that the "drawback" of keeping *.la files unconditionally is that some *.devel files get a couple too many BRs,
-devel packages get bloated Requires, not BuildRequires. Or if they're not there, other packages in a lot of cases need bloated BuildRequires in order to only accomplish also unnecessarily bloating the resulting binaries/libs, see below.
and a very few (like kdelibs) get a dozen too many.
... and that you have to put .la files into main packages (which is adding untracked dependencies) and you slow down module loading...
...and in many cases, end up unnecessarily bloating linkage of binaries/libs in main packages too, making things like soname changes even more painful than they already are...
On Sat, Oct 14, 2006 at 02:20:19PM +0300, Ville Skyttä wrote:
On Sat, 2006-10-14 at 13:05 +0200, Enrico Scholz wrote:
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
The outcome for me is that the "drawback" of keeping *.la files unconditionally is that some *.devel files get a couple too many BRs,
-devel packages get bloated Requires, not BuildRequires.
Yes, thanks, that's correct and what I meant.
...and in many cases, end up unnecessarily bloating linkage of binaries/libs in main packages too, making things like soname changes even more painful than they already are...
I think the thread made clear that this is not the case.
On Sat, 2006-10-14 at 13:29 +0200, Axel Thimm wrote:
On Sat, Oct 14, 2006 at 02:20:19PM +0300, Ville Skyttä wrote:
...and in many cases, end up unnecessarily bloating linkage of binaries/libs in main packages too, making things like soname changes even more painful than they already are...
I think the thread made clear that this is not the case.
If it did, I missed it. Got any pointers to posts that support the above conclusion to share?
On Sat, Oct 14, 2006 at 02:45:31PM +0300, Ville Skyttä wrote:
On Sat, 2006-10-14 at 13:29 +0200, Axel Thimm wrote:
On Sat, Oct 14, 2006 at 02:20:19PM +0300, Ville Skyttä wrote:
...and in many cases, end up unnecessarily bloating linkage of binaries/libs in main packages too, making things like soname changes even more painful than they already are...
I think the thread made clear that this is not the case.
If it did, I missed it. Got any pointers to posts that support the above conclusion to share?
How about this thread? No, honestly check the discussion especially Alexandre's posts who goes into the details of both libtool and non-libtool library internals.
On Sat, 2006-10-14 at 13:58 +0200, Axel Thimm wrote:
On Sat, Oct 14, 2006 at 02:45:31PM +0300, Ville Skyttä wrote:
On Sat, 2006-10-14 at 13:29 +0200, Axel Thimm wrote:
On Sat, Oct 14, 2006 at 02:20:19PM +0300, Ville Skyttä wrote:
...and in many cases, end up unnecessarily bloating linkage of binaries/libs in main packages too, making things like soname changes even more painful than they already are...
I think the thread made clear that this is not the case.
If it did, I missed it. Got any pointers to posts that support the above conclusion to share?
How about this thread? No, honestly check the discussion especially Alexandre's posts who goes into the details of both libtool and non-libtool library internals.
Sorry, that's too much for me to dig into again now, so I'll exit the thread with an observation: compare the output of these (attached also for convenience):
rpm -qRp http://download.fedora.redhat.com/pub/fedora/linux/extras/4/i386/apt-0.5.15l... rpm -qRp http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/apt-0.5.15l...
What happened between FC4 and FC5 was that *.la were dropped from rpm-devel and some other related -devel packages. No changes to the apt specfile, and the result is that apt in FE4 has 15+ more AFAICT useless library dependencies than the same package in FE5, with no change in apt functionality. In addition to being unneeded, they're actually harmful: if any of those libs would get a soname bump, it'd break apt's dependencies and require a rebuild for no gain whatsoever. (Note that this is just an example, don't pay attention to the probabilities of soname bumps in this particular case this particular time.)
Another thing is that the apt specfile in FE devel still has a lot of BR's that were apparently sometime required because they were in rpm-devel's *.la but were not pulled in by rpm-devel. As the above example shows, they were there only in order to cause unneeded bloat to the resulting apt binaries, and now that they're most likely no longer needed, they remain as bloat in the apt specfile.
Maybe removing *.la from rpm-devel and friends would have not been the only possible solution to the apt runtime package dependency bloat problem, dunno. It seems to have worked very well, though.
On Sat, 2006-10-14 at 13:58 +0200, Axel Thimm wrote:
On Sat, Oct 14, 2006 at 02:45:31PM +0300, Ville Skyttä wrote:
On Sat, 2006-10-14 at 13:29 +0200, Axel Thimm wrote:
On Sat, Oct 14, 2006 at 02:20:19PM +0300, Ville Skyttä wrote:
...and in many cases, end up unnecessarily bloating linkage of binaries/libs in main packages too, making things like soname changes even more painful than they already are...
I think the thread made clear that this is not the case.
If it did, I missed it. Got any pointers to posts that support the above conclusion to share?
How about this thread? No, honestly check the discussion especially Alexandre's posts who goes into the details of both libtool and non-libtool library internals.
https://www.redhat.com/archives/fedora-packaging/2006-October/msg00080.html
I think this is the best statement from Alexandre of the facts which he works out over the course of the message. I think there are two options for what to do about it:
A) Get rid of .la's with the possible exception of when static libraries are kept (maybe this can go along with Ralf's Static Library proposal). Uses of lt_dlopen("foo.la") are bugs and should be fixed by converting to lt_dlopenext("foo")
B) Keep all *.la's and create the complete Requires chains specified by the .la file (could be automated some day.) And also have Application packages that use lt_dlopen("foo.la") Require: the chains of library file *.la's that contain them. (Which either means application packages Requiring: *-devel packages or application and main library packages (libfoo rather than libfoo-devel) holding the *.la's)
-Toshio
On Oct 12, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
Revisting the root of evil. What exactly is wrong with not removing all *.la files?
Removing all .la files is fine as long as (i) static libraries are not in use at all, or (ii.a) dependent libraries of static libraries are explicitly listed along with the static libraries in link commands using libtool and (ii.b) emulation of dlopening of static libraries is not required.
On Thu, Oct 12, 2006 at 04:47:56PM -0300, Alexandre Oliva wrote:
On Oct 12, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
Revisting the root of evil. What exactly is wrong with not removing
^^^
all *.la files?
Removing all .la files is fine as long as (i) [...] (ii.a) [...] (ii.b) [...]
Wrong answer, the question was what is wrong with *not* removing them, not what is wrong with doing so. :)
On Oct 12, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
On Thu, Oct 12, 2006 at 04:47:56PM -0300, Alexandre Oliva wrote:
On Oct 12, 2006, Axel Thimm Axel.Thimm@ATrpms.net wrote:
Revisting the root of evil. What exactly is wrong with not removing
^^^all *.la files?
Removing all .la files is fine as long as (i) [...] (ii.a) [...] (ii.b) [...]
Wrong answer, the question was what is wrong with *not* removing them, not what is wrong with doing so. :)
Oh, I thought you just misunderstood that I was opposing that move, so I thought I'd clarify my position and justify it.
There's nothing wrong in keeping .la files, for sure.
packaging@lists.fedoraproject.org
-
Alexandre Oliva -
Axel Thimm -
Enrico Scholz -
Jason L Tibbitts III -
Michael Schwendt -
Ralf Corsepius -
Rex Dieter -
Toshio Kuratomi -
Ville Skyttä