FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 10-05-2010, 07:52 AM
Angelo Arrifano
 
Default .la files and their future on Gentoo

On 05-10-2010 03:55, Diego Elio Pettenň wrote:
> Il giorno lun, 04/10/2010 alle 11.19 -0400, Richard Freeman ha scritto:
>>
>> That said, supporting this use case should not interfere with more
>> mainstream use of the distro. I like the USE flag proposal because it
>> lets us have our cake and eat it too. Those who don't need .la files
>> don't get them except where absolutely essential, and those who need
>> and
>> are willing to live with tons of them can have it their way.
>
> USE flags add complexity, and in real use cases there are near to no
> good reasons at all to keep .la files around.

Like Richard said "Gentoo is about choice...

By removing .la files, you are taking away that choice from the user.
For you they might be useless, for some user (or entire software house)
it can be its holly grail for library versioning and linking. I don't
really feel like forcing users to change their build setups just because
we think they are useless, do you?
- It is decisions like this one that *might* give us bad reputation.

Should we also start removing package-config files just because there
are better ways to detect if a certain package is installed?
>
> I don't want to sound like a douchebag, but can you (or anyone else
> supporting the USE flag notion) explain what .la files actually do?

You don't sound like a douchebag, just someone who wants to force stuff
into others. It happens all the time when we have strong feelings about
something or when we think we are totally correct. - But hey, guess
what? The world spins around sun after all.
>
> What I'm quite sure of is that about half the people who express their
> opinion regarding .la files have no idea what they are used for, they
> expect them to be some kind of magic problem-solving fairy dust. They
> are not.

Careful.. There is people that might take this as an "attack"..
>
> They are a legacy of older operating system and static linking notions;
> they are also not magical enough as they are only consumed back by
> libtool. And not all the packages out there use libtool to link the
> final application even if they were to use autotools.
>
>
 
Old 10-05-2010, 10:03 AM
Diego Elio Pettenò
 
Default .la files and their future on Gentoo

Il giorno mar, 05/10/2010 alle 09.52 +0200, Angelo Arrifano ha scritto:
>
> Like Richard said "Gentoo is about choice...
>
> By removing .la files, you are taking away that choice from the user.
> For you they might be useless, for some user (or entire software
> house)
> it can be its holly grail for library versioning and linking. I don't
> really feel like forcing users to change their build setups just
> because
> we think they are useless, do you?
> - It is decisions like this one that *might* give us bad reputation.
>
> Should we also start removing package-config files just because there
> are better ways to detect if a certain package is installed?

Again, I ask you: how do libtool archive work? What is lost by removing
them? How can any software out there rely on them?

Can you provide any specific use case, or are you now arguing for
"choice for choice's sake"?

Should we remove /usr/bin/xml2-config? No. Why? Because there are
packages out there not using pkg-config to detect libxml2, upstream
libxml2 provides that explicitly and allows it to be used as such:

$(CC) $(CFLAGS) $(LDFLAGS) `xml2-config --cflags` foo.c -o foo
`xml2-config --libs`

Should we remove /usr/lib/libxml2.la? Yes. Why? Because upstream does
not explicitly provide it (it's a byproduct of libtool), and they don't
require/ask to rely on it (otherwise it wouldn't provide pkg-config
or .pc files).

Again, I'm not arguing over semantics or feelings here, I'm arguing with
facts; can you argue with facts or are you just going to quote Richard
again and propose "choice for choice's sake"?

--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
 
Old 10-05-2010, 11:04 AM
Angelo Arrifano
 
Default .la files and their future on Gentoo

On 05-10-2010 12:03, Diego Elio Pettenň wrote:
> Il giorno mar, 05/10/2010 alle 09.52 +0200, Angelo Arrifano ha scritto:
>>
>> Like Richard said "Gentoo is about choice...
>>
>> By removing .la files, you are taking away that choice from the user.
>> For you they might be useless, for some user (or entire software
>> house)
>> it can be its holly grail for library versioning and linking. I don't
>> really feel like forcing users to change their build setups just
>> because
>> we think they are useless, do you?
>> - It is decisions like this one that *might* give us bad reputation.
>>
>> Should we also start removing package-config files just because there
>> are better ways to detect if a certain package is installed?
>
> Again, I ask you: how do libtool archive work? What is lost by removing
> them? How can any software out there rely on them?

You can extract from a .la things like the library name, version and
linking information (lib dependencies and paths). The information is
there and nothing prevented anyone from using it.
>
> Can you provide any specific use case, or are you now arguing for
> "choice for choice's sake"?

There are a lot of packages that need this information to correctly link
against libtool managed libraries, for example, there are packages that
linked against GL but didn't set -lGL -lGLU because it was relying on
libtool to get that information (guess from where?). Things get worse
when they also expect libtool to also provide libraries path. There are
even packages that expects libtool to provide linker flags for its
direct dependencies and flags for the dependencies of its dependencies.
For example:
foo links with GL (expects libtool to provide -lGL -lGLU)
foo also links with the backend of GL (expects libtool to provide -lX11
for example, which is a dependency of GL)

In a perfect world everyone would be using pkg-config or whatever, but
not. I happen to be bitching about this because I came across some of
these when cross-compiling.
>
> Should we remove /usr/bin/xml2-config? No. Why? Because there are
> packages out there not using pkg-config to detect libxml2, upstream
> libxml2 provides that explicitly and allows it to be used as such:
>
> $(CC) $(CFLAGS) $(LDFLAGS) `xml2-config --cflags` foo.c -o foo
> `xml2-config --libs`
>
> Should we remove /usr/lib/libxml2.la? Yes. Why? Because upstream does
> not explicitly provide it (it's a byproduct of libtool), and they don't
> require/ask to rely on it (otherwise it wouldn't provide pkg-config
> or .pc files).
>
> Again, I'm not arguing over semantics or feelings here, I'm arguing with
> facts; can you argue with facts or are you just going to quote Richard
> again and propose "choice for choice's sake"?
>

Mind you that the community is wider than one can imagine. I happen to
work in the academia and I know a lot of nasty stuff people do to save
time (at least is what they think) for deadlines. As a user, I would
hate to have my research program/script broken just because some dev
decided to make the distribution I use his personal sandbox.

Besides, doesn't this kind of changes belong in upstream and then
eventually come to the distros? Why don't you make a patch and send
upstream if these libtool files are so useless?
 
Old 10-05-2010, 11:25 AM
Diego Elio Pettenò
 
Default .la files and their future on Gentoo

Il giorno mar, 05/10/2010 alle 13.04 +0200, Angelo Arrifano ha scritto:
> There are a lot of packages that need this information to correctly link
> against libtool managed libraries, for example, there are packages that
> linked against GL but didn't set -lGL -lGLU because it was relying on
> libtool to get that information (guess from where?).

Definitely not from /usr/lib/libGL.la given that libGL is part of mesa
and mesa did not use libtool for linking until very recently, so it's
either something relying on just the most recent versions of mesa, or
it's screwed. For your information, mesa has supported pkg-config for a
longer time than it used libtool to build.

Other interesting note: libGL on non-Xorg systems has no reason to use
libtool at all, even today.

Where does the linker find this information? For dynamic linking, from
the ELF files. The problem sticks for static linking, but I have my
sincere doubts that anyone in his sane mind is going to statically link
libGL for the simple reason that it can depend on the driver used (mesa,
nvidia, ATI, ...) and might even use dynamic linking against other
backends.

> Mind you that the community is wider than one can imagine. I happen to
> work in the academia and I know a lot of nasty stuff people do to save
> time (at least is what they think) for deadlines. As a user, I would
> hate to have my research program/script broken just because some dev
> decided to make the distribution I use his personal sandbox.

No, you'd just have to do things sanely. I sincerely don't see Gentoo
needing to not move forward (or add much more complexity in the already
complex mix) just because some student decided that it's cooler to hack
something up rather than learning how the thing is done to begin with.

We already don't support many other things that do break hacky scripts
that are written in academic (and not just) circles; does that mean we
have to revert those and pad around everything for our users, lest some
thing that never should have worked actually stop working?

> Besides, doesn't this kind of changes belong in upstream and then
> eventually come to the distros? Why don't you make a patch and send
> upstream if these libtool files are so useless?

I see you haven't read my post on the matter I linked at the root of the
thread. Please do so and don't ask me questions I answered already
there.

http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points

--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
 
Old 10-05-2010, 11:28 AM
Diego Elio Pettenò
 
Default .la files and their future on Gentoo

Il giorno mar, 05/10/2010 alle 13.25 +0200, Diego Elio Pettenò ha
scritto:
> Definitely not from /usr/lib/libGL.la given that libGL is part of mesa
> and mesa did not use libtool for linking until very recently,

Actually, scratch that, mesa IS NOT USING LIBTOOL AT ALL.

So you hit the jackpot: you brought up a libtool use case that... does
not use libtool at all! Congratulations!

Now, can you please let people express _informed_ opinions?

--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
 
Old 10-05-2010, 11:40 AM
Samuli Suominen
 
Default .la files and their future on Gentoo

On 10/05/2010 02:04 PM, Angelo Arrifano wrote:
> You can extract from a .la things like the library name, version and
> linking information (lib dependencies and paths). The information is
> there and nothing prevented anyone from using it.
>>
>> Can you provide any specific use case, or are you now arguing for
>> "choice for choice's sake"?
>
> There are a lot of packages that need this information to correctly link
> against libtool managed libraries, for example, there are packages that
> linked against GL but didn't set -lGL -lGLU because it was relying on
> libtool to get that information (guess from where?). Things get worse
> when they also expect libtool to also provide libraries path. There are
> even packages that expects libtool to provide linker flags for its
> direct dependencies and flags for the dependencies of its dependencies.
> For example:
> foo links with GL (expects libtool to provide -lGL -lGLU)
> foo also links with the backend of GL (expects libtool to provide -lX11
> for example, which is a dependency of GL)

Yeah, that's called overlinking[1]. There's no need to link to -lX11 if
really only -lGL is required. Exactly what we are trying to protect
users from.

Full stop.

[1] http://wiki.mandriva.com/en/Libtool_archives#shared_build

"Worse, default libtool causes overlinking when it uses *.la."

- Samuli
 
Old 10-05-2010, 11:49 AM
Luca Barbato
 
Default .la files and their future on Gentoo

On 10/5/10 9:52 AM, Angelo Arrifano wrote:


By removing .la files, you are taking away that choice from the user.
For you they might be useless, for some user (or entire software house)
it can be its holly grail for library versioning and linking. I don't
really feel like forcing users to change their build setups just because
we think they are useless, do you?
- It is decisions like this one that *might* give us bad reputation.


Bluntly put, you seem to not know how libtool exactly works and further
down in the thread how linking exactly works. Please try to learn the
fine Gentoo docs on the subject and feel free to ask more details on irc.


lu
 
Old 10-05-2010, 12:13 PM
Angelo Arrifano
 
Default .la files and their future on Gentoo

On 05-10-2010 13:28, Diego Elio Pettenň wrote:
> Il giorno mar, 05/10/2010 alle 13.25 +0200, Diego Elio Pettenň ha
> scritto:
>> Definitely not from /usr/lib/libGL.la given that libGL is part of mesa
>> and mesa did not use libtool for linking until very recently,
>
> Actually, scratch that, mesa IS NOT USING LIBTOOL AT ALL.
>
> So you hit the jackpot: you brought up a libtool use case that... does
> not use libtool at all! Congratulations!
>
> Now, can you please let people express _informed_ opinions?
>

I don't want to interrupt your celebration of winning a war or
something. Just want to say that mesa is not the only opengl
implementation. The examples I gave work with any other libtool managed
library.
 
Old 10-05-2010, 01:44 PM
Angelo Arrifano
 
Default .la files and their future on Gentoo

On 05-10-2010 13:49, Luca Barbato wrote:
> On 10/5/10 9:52 AM, Angelo Arrifano wrote:
>
>> By removing .la files, you are taking away that choice from the user.
>> For you they might be useless, for some user (or entire software house)
>> it can be its holly grail for library versioning and linking. I don't
>> really feel like forcing users to change their build setups just because
>> we think they are useless, do you?
>> - It is decisions like this one that *might* give us bad reputation.
>
> Bluntly put, you seem to not know how libtool exactly works and further
> down in the thread how linking exactly works. Please try to learn the
> fine Gentoo docs on the subject and feel free to ask more details on irc.
>
> lu
>
>

I just talked with Samuli and Luca at IRC and indeed there were some
issues in my reasoning about libtool's behavior. Applications expecting
overlinking to link correctly would be broken anyway due to
-Wl,--as-needed .

Since all the issues I tried to point will not be verified anyway, I
don't see anymore why we can't proceed with the proposal. Moreover, due
to my past in fixing .la files to let programs cross-compile correctly I
actually welcome this change. So here it is my
+1
 
Old 10-05-2010, 02:33 PM
Ciaran McCreesh
 
Default .la files and their future on Gentoo

On Tue, 05 Oct 2010 13:49:43 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Bluntly put, you seem to not know how libtool exactly works and
> further down in the thread how linking exactly works. Please try to
> learn the fine Gentoo docs on the subject and feel free to ask more
> details on irc.

Ah, so you do know exactly how libtool works? Great! It should be easy
for you to fix it to only specify direct link dependencies then, thus
solving the underlying problem in one place rather than working around
it by fixing thousands of individual packages.

I look forward to testing your patch!

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 10:31 PM.

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