[Fedora-packaging] Re: libtool(.la) archive policy proposal

[Enrico Scholz]

Axel.Thimm at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20061012/6398208b/attachment.sig>