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 at ATrpms.net
Attachment:
pgprCuzFfmtRe.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
