Axel.Thimm(a)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