FAQ Search Today's Posts Mark Forums Read

» Linux Archive
Home
New Posts
Search
FAQ


Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-01-2008, 05:28 PM
Toshio Kuratomi
 
Default Dia has .la files

Michael Schwendt wrote:
> On Sat, 01 Nov 2008 08:33:31 -0700, Toshio Kuratomi wrote:
>
>> Also, as Patrice erroneously points out, some packages will break
>> without the *.la files. I have yet to see a package where that's
>> actually a "needs" case. However, I have seen places where the upstream
>> code looks for the *.la file when libltdl (the libtool library) is
>> willing to look for either the *.so or the *.la.
>
> There are old libltdl libs that don't work if the libtool archives
> are missing. The packagers of such apps should know about that.
>
It's been a while since I looked at this but isn't libltdl a shared
library? So in Fedora we should be running against the newer version of
libltdl that does work with missing libtool archives?

> The other case where removing libtool archives causes breakage is
> if there are inter-library dependencies in the .la files. Then you
> need to remove all .la files.
>
True. That doesn't conflict with removing .la files everywhere, though.

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-01-2008, 06:08 PM
Michael Schwendt
 
Default Dia has .la files

On Sat, 01 Nov 2008 10:28:43 -0700, Toshio Kuratomi wrote:

> It's been a while since I looked at this but isn't libltdl a shared
> library? So in Fedora we should be running against the newer version of
> libltdl that does work with missing libtool archives?

Unless an old or customised copy of libltdl is used -- which has been the
case several times before. One of the more prominent examples was KDE,
albeit a few years ago. Wow, lots of hits at Google when searching for
such issues related to Fedora.

> > The other case where removing libtool archives causes breakage is
> > if there are inter-library dependencies in the .la files. Then you
> > need to remove all .la files.
> >
> True. That doesn't conflict with removing .la files everywhere, though.

Except that there has been resistance from some packagers, as they
refuse[d] to remove libtool archives. Perhaps this has changed
meanwhile.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-01-2008, 06:17 PM
Toshio Kuratomi
 
Default Dia has .la files

Michael Schwendt wrote:
> On Sat, 01 Nov 2008 10:28:43 -0700, Toshio Kuratomi wrote:
>
>> It's been a while since I looked at this but isn't libltdl a shared
>> library? So in Fedora we should be running against the newer version of
>> libltdl that does work with missing libtool archives?
>
> Unless an old or customised copy of libltdl is used -- which has been the
> case several times before. One of the more prominent examples was KDE,
> albeit a few years ago. Wow, lots of hits at Google when searching for
> such issues related to Fedora.
>
Yeah. KDE3 I showed how to fix it but it was decided to move to KDE4
which doesn't use libltdl rather than fix it in KDE3.

As a general rule, using a private copy of a system library would be a
violation of the Packaging Guidelines for security reasons so it's
probably something we want to patch whenever we find it.

>>> The other case where removing libtool archives causes breakage is
>>> if there are inter-library dependencies in the .la files. Then you
>>> need to remove all .la files.
>>>
>> True. That doesn't conflict with removing .la files everywhere, though.
>
> Except that there has been resistance from some packagers, as they
> refuse[d] to remove libtool archives. Perhaps this has changed
> meanwhile.
>
heh :-) That's a good point. But if it's causing issues for dependent
packages that want to get rid of the .la then it makes even more sense
to tell them they must remove the .la's in their package.

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-01-2008, 08:06 PM
"Dan Nicholson"
 
Default Dia has .la files

On Fri, Oct 31, 2008 at 4:24 PM, Dan Nicholson <dbn.lists@gmail.com> wrote:
> On Fri, Oct 31, 2008 at 4:17 PM, Colin Walters <walters@verbum.org> wrote:
>> On Fri, Oct 31, 2008 at 7:15 PM, Dan Nicholson <dbn.lists@gmail.com> wrote:
>>> On Fri, Oct 31, 2008 at 2:21 PM, Colin Walters <walters@verbum.org> wrote:
>>>>
>>>> The ideal of course would be to convince libtool upstream that trying
>>>> to change the entire world to use libtool makes a lot less sense than
>>>> having those few modules that interact with shared libraries have
>>>> platform-specific code.
>>>
>>> The libtool developers understand that the .la files aren't needed in
>>> normal operation. The reason that they insist on keeping them is so
>>> that `make uninstall' works since the .la files are the only place
>>> that store information about the actual libraries (.so + links vs. .a,
>>> etc.).
>>
>> Right - we have a "make uninstall", it's called "rpm -e".
>
> OK, now convince the libtool developers to break everyone's `make
> distcheck'. Might be tough. But I certainly would support a way to opt
> out of that situation at build time. Something like:
>
> export LIBTOOLFLAGS="--no-installed-la-files"

Here's a patch against libtool-1.5.24 (should apply to F-9 or rawhide)
that adds a --no-la-files option. If the source tree libtool has been
generated using the patched libtool, then setting
LIBTOOLFLAGS="--no-la-files" will suppress installing the .la files.
However, older automake does not pass LIBTOOLFLAGS during the install
phase, so it may not work in all cases.

To test, you can just apply to your system ltmain.sh:

# sudo patch -b /usr/share/libtool/ltmain.sh
libtool-1.5.24-no-la-files.patch
# sudo patch -b /usr/share/libtool/libltdl/ltmain.sh
libtool-1.5.24-no-la-files.patch

Find a simple libtooled package to test (I've been using libpciaccess
since it's clean), run `autoreconf -iv', export
LIBTOOLFLAGS=--no-la-files and build away.

--
Dan
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-01-2008, 10:24 PM
Ralf Corsepius
 
Default Dia has .la files

On Sat, 2008-11-01 at 19:08 +0100, Michael Schwendt wrote:
> On Sat, 01 Nov 2008 10:28:43 -0700, Toshio Kuratomi wrote:

> Except that there has been resistance from some packagers, as they
> refuse[d] to remove libtool archives. Perhaps this has changed
> meanwhile.
No, it hasn't changed. What has changed is the packagers.

Newcomer maintainers tend to blindly follow the what others tell them,
no matter how wrong it is (Such as the lies on *.la's).


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-02-2008, 12:48 PM
"Richard W.M. Jones"
 
Default Dia has .la files

On Sat, Nov 01, 2008 at 08:33:31AM -0700, Toshio Kuratomi wrote:
> Richard W.M. Jones wrote:
> > On Fri, Oct 31, 2008 at 05:21:55PM -0400, Colin Walters wrote:
> >> Really we need a post-build (BRP) hook in RPM to nuke them instead of
> >> copy&paste of rm into spec files.
> >
> > We need the *.la files for MinGW packages.
> >
> Is that a "We need the *.la files for MinGW packages" or "We need the
> *.la files in MinGW packages"?

I'm going to do a bit more testing on this tomorrow to make sure this
is really true, then get back to you about it ...

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 08:17 AM.

VBulletin, Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org