[gentoo-user] Library file formats

[gentoo-user] Library file formats

[Peter Humphrey]

Hello list,

I thought I'd have a play with swami, but the emerge fails with "/bin/sed: 
can't read /usr/lib64/libogg.la: No such file or directory", and indeed there 
is none such.

I have libogg installed, and the files it's put into /usr/lib64 are:
/usr/lib64/libogg.a
/usr/lib64/libogg.so -> libogg.so.0.6.0
/usr/lib64/libogg.so.0 -> libogg.so.0.6.0
/usr/lib64/libogg.so.0.6.0

I'm not familiar with library file formats; what are my options here?

-- 
Rgds
Peter

Re: [gentoo-user] Library file formats

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Fri, 16 Oct 2009 12:20:30 +0100, Peter Humphrey wrote:

> I thought I'd have a play with swami, but the emerge fails with
> "/bin/sed: can't read /usr/lib64/libogg.la: No such file or directory",
> and indeed there is none such.

The elog message from the last libogg install explains this. Run
lafilefixer --justfixit.


-- 
Neil Bothwick

Barth's Distinction:
There are two types of people: those who divide people into two types, and
those who don't.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Library file formats

[Peter Humphrey]

On Friday 16 October 2009 12:37:04 Neil Bothwick wrote:

> The elog message from the last libogg install explains this.

Hmm, I think that's too long ago.

> Run lafilefixer --justfixit.

I don't have an lafilefixer; which package is it in?

-- 
Rgds
Peter

Re: [gentoo-user] Library file formats

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

On Fri, 16 Oct 2009 12:59:46 +0100, Peter Humphrey wrote:

> > Run lafilefixer --justfixit.  
> 
> I don't have an lafilefixer; which package is it in?

eix could have told you that.


-- 
Neil Bothwick

Duct tape is the just like the Force: it has a light side, a dark side,
and binds the universe together.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Library file formats

[Volker Armin Hemmann]

On Freitag 16 Oktober 2009, Neil Bothwick wrote:
> On Fri, 16 Oct 2009 12:59:46 +0100, Peter Humphrey wrote:
> > > Run lafilefixer --justfixit.
> >
> > I don't have an lafilefixer; which package is it in?
> 
> eix could have told you that.
> 

or emerge -s

Re: [gentoo-user] Library file formats

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

On Fri, 16 Oct 2009 14:10:22 +0200, Volker Armin Hemmann wrote:

> > eix could have told you that.
> 
> or emerge -s

My point was that using eix is faster than posting to the list and
awaiting a reply. The same is not necessarily true of emerge -s :(


-- 
Neil Bothwick

Politicians are like nappies
Both should be changed regularly, and for the same reason

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Library file formats

[Volker Armin Hemmann]

On Samstag 17 Oktober 2009, Neil Bothwick wrote:
> On Fri, 16 Oct 2009 14:10:22 +0200, Volker Armin Hemmann wrote:
> > > eix could have told you that.
> >
> > or emerge -s
> 
> My point was that using eix is faster than posting to the list and
> awaiting a reply. The same is not necessarily true of emerge -s :(
> 

depends on your harddisk and filesystem. emerge -s can be as fast as eix on my 
box.

emerge -S on the other hand ....

Re: [gentoo-user] Library file formats

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On Sat, 17 Oct 2009 11:30:32 +0200, Volker Armin Hemmann wrote:

> > My point was that using eix is faster than posting to the list and
> > awaiting a reply. The same is not necessarily true of emerge -s :(
> >   
> 
> depends on your harddisk and filesystem. emerge -s can be as fast as
> eix on my box.

On a reasonably fast system (dual core 64 bit with RAID5 over SATA2):

eix lafilefixer  0.03s user 0.01s system 13% cpu 0.288 total
emerge -s lafilefixer  1.37s user 0.19s system 63% cpu 2.460 total

almost ten times as long.

On a much slower system, Dell Mini 10:

eix lafilefixer  0.17s user 0.05s system 17% cpu 1.251 total
emerge -s lafilefixer  8.64s user 1.46s system 42% cpu 23.803 total

Nearer twenty times as long.

So the conclusion is that if you spend enough on hardware, emerge -s is
only ten times slower than eix :-O


-- 
Neil Bothwick

Press any key... no, no, no, NOT THAT ONE!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Library file formats

[Volker Armin Hemmann]

On Samstag 17 Oktober 2009, Neil Bothwick wrote:
> On Sat, 17 Oct 2009 11:30:32 +0200, Volker Armin Hemmann wrote:
> > > My point was that using eix is faster than posting to the list and
> > > awaiting a reply. The same is not necessarily true of emerge -s :(
> >
> > depends on your harddisk and filesystem. emerge -s can be as fast as
> > eix on my box.
> 
> On a reasonably fast system (dual core 64 bit with RAID5 over SATA2):
> 
> eix lafilefixer  0.03s user 0.01s system 13% cpu 0.288 total
> emerge -s lafilefixer  1.37s user 0.19s system 63% cpu 2.460 total
> 
> almost ten times as long.
> 
> On a much slower system, Dell Mini 10:
> 
> eix lafilefixer  0.17s user 0.05s system 17% cpu 1.251 total
> emerge -s lafilefixer  8.64s user 1.46s system 42% cpu 23.803 total
> 
> Nearer twenty times as long.
> 
> So the conclusion is that if you spend enough on hardware, emerge -s is
> only ten times slower than eix :-O
> 

and the difference is still just a second

Re: [gentoo-user] Library file formats

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

On Sat, 17 Oct 2009 19:10:22 +0200, Volker Armin Hemmann wrote:

> > eix lafilefixer  0.17s user 0.05s system 17% cpu 1.251 total
> > emerge -s lafilefixer  8.64s user 1.46s system 42% cpu 23.803 total

> and the difference is still just a second

I think your calculator needs new batteries. 23.8 -1.2 was != 1 when I
was at school :(


-- 
Neil Bothwick

This fortune soaks up 47 times its own weight in excess memory.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Library file formats

[Volker Armin Hemmann]

On Sonntag 18 Oktober 2009, Neil Bothwick wrote:
> On Sat, 17 Oct 2009 19:10:22 +0200, Volker Armin Hemmann wrote:
> > > eix lafilefixer  0.17s user 0.05s system 17% cpu 1.251 total
> > > emerge -s lafilefixer  8.64s user 1.46s system 42% cpu 23.803 total
> >
> > and the difference is still just a second
> 
> I think your calculator needs new batteries. 23.8 -1.2 was != 1 when I
> was at school :(
> 

oops, sorry, I misread. Major brainfart while reading.

btw, here:
emerge -s lafilefixer  1,42s user 0,15s system 98% cpu 1,595 total

eix lafilefixer  0,09s user 0,05s system 47% cpu 0,287 total

just a bit over a second.

Re: [gentoo-user] Library file formats

[peter]

On Friday 16 October 2009 13:04:31 Neil Bothwick wrote:
> On Fri, 16 Oct 2009 12:59:46 +0100, Peter Humphrey wrote:
> > > Run lafilefixer --justfixit.
> >
> > I don't have an lafilefixer; which package is it in?
> 
> eix could have told you that.

Ah, yes, sorry - it didn't look like a package name but a utility from 
another package.

Must try harder not to ask stupid questions in the morning...

[gentoo-user] Re: Library file formats

[walt]

On 10/16/2009 04:37 AM, Neil Bothwick wrote:
> On Fri, 16 Oct 2009 12:20:30 +0100, Peter Humphrey wrote:
> 
>> I thought I'd have a play with swami, but the emerge fails with
>> "/bin/sed: can't read /usr/lib64/libogg.la: No such file or directory",
>> and indeed there is none such.
> 
> The elog message from the last libogg install explains this. Run
> lafilefixer --justfixit.

There is no manpage for lafilefixer, but the --help flag prints:

      --justfixit       Choose some reasonable dirs, such as /usr/lib*, etc. ,
                        find all .la files and fix them to not use .la files
                        for linking

I can't make sense out of that -- one of the major uses of libtool (I thought)
is for linking.  Can anyone 'splain that to me?

Thanks.

Re: [gentoo-user] Re: Library file formats

[Volker Armin Hemmann]

On Freitag 16 Oktober 2009, walt wrote:
> On 10/16/2009 04:37 AM, Neil Bothwick wrote:
> > On Fri, 16 Oct 2009 12:20:30 +0100, Peter Humphrey wrote:
> >> I thought I'd have a play with swami, but the emerge fails with
> >> "/bin/sed: can't read /usr/lib64/libogg.la: No such file or directory",
> >> and indeed there is none such.
> >
> > The elog message from the last libogg install explains this. Run
> > lafilefixer --justfixit.
> 
> There is no manpage for lafilefixer, but the --help flag prints:
> 
>       --justfixit       Choose some reasonable dirs, such as /usr/lib*,
>  etc. , find all .la files and fix them to not use .la files for linking
> 
> I can't make sense out of that -- one of the major uses of libtool (I
>  thought) is for linking.  Can anyone 'splain that to me?
> 
> Thanks.
> 

AFAIK the help printout is not entirely correct. It corrects the path' used in 
the la files,

I recommend this reads:
http://blog.flameeyes.eu/2008/04/14/what-about-those-la-files
http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-
killed-off-sooner-rather-than-later
http://blog.flameeyes.eu/2009/04/18/some-details-about-our-old-friends-the-la-
files
http://blog.flameeyes.eu/2009/09/28/removing-la-files-for-dum-w-uncertain-people

Re: [gentoo-user] Re: Library file formats

[Mike Edenfield]

On 10/16/2009 12:54 PM, walt wrote:
> On 10/16/2009 04:37 AM, Neil Bothwick wrote:
>> On Fri, 16 Oct 2009 12:20:30 +0100, Peter Humphrey wrote:
>>
>>> I thought I'd have a play with swami, but the emerge fails with
>>> "/bin/sed: can't read /usr/lib64/libogg.la: No such file or directory",
>>> and indeed there is none such.
>>
>> The elog message from the last libogg install explains this. Run
>> lafilefixer --justfixit.
>
> There is no manpage for lafilefixer, but the --help flag prints:
>
>        --justfixit       Choose some reasonable dirs, such as /usr/lib*, etc. ,
>                          find all .la files and fix them to not use .la files
>                          for linking
>
> I can't make sense out of that -- one of the major uses of libtool (I thought)
> is for linking.  Can anyone 'splain that to me?

One of the major problems with .la files (besides being mostly useless 
on Linux/FreeBSD/any other ELF-based OS) is when they refer to other .la 
files instead of linking directly to the binaries.  This breaks things 
when they get removed from a ebuild for a library that other libraries 
depend on.

The only time that libtool archives provide a real benefit is when 
there's a need to link in static libraries that have external 
dependencies -- the libtool archive defines the dependency information 
that can't be stored in the static archive format.  If you don't have 
any publicly-consumed static libraries, .la files are just pointless 
clutter, so package maintainers very often remove them.  Any build 
system depending on libtool for its linking then breaks because the 
dependency chain is broken.

Take, for example, this very real example from my system.  I have both 
hal and dbus installed; hal depends on dbus, and both packages install 
libtool archives.  In /usr/lib/libhal.la, there is the following:

# Libraries that this one depends upon.
dependency_libs=' /usr/lib/libdbus-1.la -lcap -lpthread -lrt'

Thus, whenever a package that uses hal tells libtool to link to 
libhal.la, libtool recursively links to libdbus-1.la as well.

Now, say the dbus maintainer suddenly doesn't like .la files (perhaps a 
bad break-up in Los Angeles), and removes them from the ebuild.  The 
next time I true to use libtool to link in hal, it will fail because the 
latest dbus does not include /usr/lib/libdbus-1.la.

The fix is to run lafilefixer, which changes the above line to say:

# Libraries that this one depends upon.
dependency_libs=' -L/usr/lib -ldbus-1 -lcap -lpthread -lrt'

So that hal no longer cares whether or not the dbus package installed 
its libtool archive, and all is well.

--Mike

[gentoo-user] Re: Library file formats

[walt]

On 10/16/2009 11:06 AM, Mike Edenfield wrote:
> On 10/16/2009 12:54 PM, walt wrote:
>> On 10/16/2009 04:37 AM, Neil Bothwick wrote:
>>> On Fri, 16 Oct 2009 12:20:30 +0100, Peter Humphrey wrote:
>>>
>>>> I thought I'd have a play with swami, but the emerge fails with
>>>> "/bin/sed: can't read /usr/lib64/libogg.la: No such file or directory",
>>>> and indeed there is none such.
>>>
>>> The elog message from the last libogg install explains this. Run
>>> lafilefixer --justfixit.
>>
>> There is no manpage for lafilefixer, but the --help flag prints:
>>
>>        --justfixit       Choose some reasonable dirs, such as
>> /usr/lib*, etc. ,
>>                          find all .la files and fix them to not use
>> .la files
>>                          for linking
>>
>> I can't make sense out of that -- one of the major uses of libtool (I
>> thought)
>> is for linking.  Can anyone 'splain that to me?
> 
> One of the major problems with .la files (besides being mostly useless
> on Linux/FreeBSD/any other ELF-based OS) is when they refer to other .la
> files instead of linking directly to the binaries.  This breaks things
> when they get removed from a ebuild for a library that other libraries
> depend on.
> 
> The only time that libtool archives provide a real benefit is when
> there's a need to link in static libraries that have external
> dependencies -- the libtool archive defines the dependency information
> that can't be stored in the static archive format.  If you don't have
> any publicly-consumed static libraries, .la files are just pointless
> clutter, so package maintainers very often remove them.  Any build
> system depending on libtool for its linking then breaks because the
> dependency chain is broken.
> 
> Take, for example, this very real example from my system.  I have both
> hal and dbus installed; hal depends on dbus, and both packages install
> libtool archives.  In /usr/lib/libhal.la, there is the following:
> 
> # Libraries that this one depends upon.
> dependency_libs=' /usr/lib/libdbus-1.la -lcap -lpthread -lrt'
> 
> Thus, whenever a package that uses hal tells libtool to link to
> libhal.la, libtool recursively links to libdbus-1.la as well.
> 
> Now, say the dbus maintainer suddenly doesn't like .la files (perhaps a
> bad break-up in Los Angeles), and removes them from the ebuild.

I think .la files are an adequate reason to dislike .la files :o)
They have certainly wasted many frustrated hours for me.

> The
> next time I true to use libtool to link in hal, it will fail because the
> latest dbus does not include /usr/lib/libdbus-1.la.
> 
> The fix is to run lafilefixer, which changes the above line to say:
> 
> # Libraries that this one depends upon.
> dependency_libs=' -L/usr/lib -ldbus-1 -lcap -lpthread -lrt'
> 
> So that hal no longer cares whether or not the dbus package installed
> its libtool archive, and all is well.

An excellent 'splain, thank you very much :o)  Thanks also to Volker for
the links to Diego's blogs.  I'm about halfway through them now.