Axel.Thimm@xxxxxxxxxx (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
Attachment:
pgpw1sLzYPpkJ.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
