Since I have been still fighting with the damned .la files and I’m pretty sure that even though I have explained some use cases most of my colleagues haven’t really applied them, I decided to go with a different approach this time: graphical guides.
Since the post about the tree size has gotten so much feedback, probably because the graphs impacted on people, this might actually prove useful.
Note: I first tried to draw the chart with Inkscape, but the connector available on its code only draws straight lines, which are unusable for stuff like this; I found no way to anchor lines to an arbitrary point of objects either, so I gave up; dia is tremendously bad to work with; kivio 2 is not in Portage nor available as binary package for either Windows or OSX; OpenOffice to the rescue, worked almost flawlessly, unfortunately I didn’t want to waste time to define customised colours so you get the bad and boring ones in the image.
As you can see from this graph, my idea is that, at the end, every .la file is removed. Of course this is not immediate and depends on a series of factors; this graph shows at least the basic question you got to ask yourself when you have to deal with shared libraries. Please note that this does not apply the same to plugins and for that I’ll post another, different flow chart.
- Does the package install internal libraries only? A lot of packages provide convenience libraries to share code between different executable programs (see this post for more information about it); this can be detected easily: there are no include files installed by default, the library is not in the ld path (such as
/usr/lib/packagename). In this case, the.lafiles are not useful at all, and can be removed straight away. - Does the package only install shared objects? The
.lafiles are only meaningful for static libraries that have no dependency information; if a package is not installing static libraries (.afiles) it needs not the.lafiles. - Do the libraries in the package need other libraries? If the libraries are standalone, and only depend on the C library (
libc.so), then there is no dependency information useful in the.lafile, and can be dropped. - Is
pkg-configthe official way to link to the libraries? When usingpkg-config, the dependency information is moved inside the.pcfile, so the copy in the.lafile is redundant, and thus unnecessary. - Is the package new? When adding a new package into Portage, there is no reason to keep the
.lafiles around when the conditions shown above apply. For packages that are already in portage, the removal of.lafiles need to be considerate, or you’ll get the same kind of fire I got for trying to remove some (useless).lafiles out of the blue. Not a situation that I like, but so is life.
non sono invertiti {Y,N} in “New Package”?
RTFA francesco sorry for the noise
One question – how to build shared library in autotools w/out libtool?
libtool upstream is talking about ignoring dependency_libs when compiling with shared libs on sane platforms.
Next time you want to make a flowchart, I recommend app-office/dia.It’s pretty light on dependencies and works perfectly for this kind of thing.
@AnonymousDid you really read the full text? He mentioned dia…
For the casual Gentoo developer that reads this. Before you follow, please make sure a global discussion about the topic has taken place in the gentoo-dev mailing list. Following blog posts about a “global goal” without global discussion of it first is not really appropriate.
Mart, do we need a “global discussion” even to fix parallel make failures? Because this is in the same bloody category.*@.la@ files are totally useless, and the only reason why we cannot massively remove them is that they weren’t removed earlier.*New packages *should really not install @.la@ files*.
I agree completely. For a new package, the packager is free to drop whatever files he pleases from the installation.Making portage automatically remove them from every package would need a wider discussion, of course.
@Mark, the proper way to discuss the .la issue is into the ML gentoo-qa and not gentoo-dev as it’s a job for the Gentoo QA Team.
@equilibrium:It is a global suggestion to drop .la files. It should be discussed and suggested in the global developer mail, instead of a random blog, before put into full practice.And my name is not Mark, it’s Mart.@Flameeyes:Having .la files is not something that needs fixing for any sense of the word that applies to things like “parallel make failures”. It works just fine with .la files, just because of a libtool bug you get indirect deps forced as well. Fixing libtool to not do that is something that falls into the same category as “parallel make failures”, and NOT global removal of .la files.We need a global plan, and I have also ideas on how to do this properly and globally, but it needs to be discussed in gentoo-dev and I’d take part of that discussion next week.So Diego, if you want it happen, please make it happen in the proper way – post to gentoo-dev with these instructions instead of using your personal blog space to get Gentoo developers to drop libtool files without any global discussion yet (someone might know corner cases if it were discussed on gentoo-dev, etc). Lets make a proper plan and page that explains all the implications, and then we can announce the plan on gentoo-dev-announce and get cracking.I’d prefer libtool being fixed though to separate indirect and direct deps in .la files though…
I keep on disagreeing with you.First “fixing libtool” is something that is _also_ being said so many times, and I see nobody stepping up to do that. I won’t either, because _I simply don’t care enough about @.la@ files_. They are useless for any modern operating system for dynamic linking (all the formats used nowadays support something along the lines of the NEEDED field for ELF files); they are only useful for static libraries, and even in that case, since nowadays the default is to use pkg-config to discover the dependencies, you don’t need to have a special, autotools-only piece of crap (that is libtool) to deal with the remaining dependencies.And I don’t buy your “someone might know corner cases” crap because *this has been discussed before* and nobody found any good reason to keep @.la@ files around if not “that’ll require users running something to fix those which remain”.@.la@ files *are just a piece of shit that should have died a long time ago*!
I very well agree with the intent, just not the current process …Just no-mail subscribe to gentoo-dev and go ahead with all this on there instead of a blog post. Blogs are not the medium for this, as you’ve been said multiple times by other people too.That said, the information is good for other people reading your blog. Might want to mention building breaks horribly for users if you remove a .la file of a lower level library that a higher level libraries .la file refers to, which is the reason you were “getting fire for trying to remove some (useless) .la files out of the blue”
@Mart: as Diego have well explained, the topic has just been discussed several times and a lot of time ago; there is not need to restart the discussion in gentoo-dev ml, so the only thing to discuss about the topic is “how to implement the global removal of .la files” which is a topic that belong to the Gentoo QA Team and not to the gentoo-dev mailing list.
I don’t see any reason why this would be considered a Gentoo QA Team concern. It is not something the QA team should go and touch all over maintained ebuilds. It should be discussed in gentoo-dev mailing list, a global plan and so on.For example I would suggest an eclass for it, with a well known way to disable the removal if really needed for someone, and some good ways to specify what will get removed and what not. But I can’t suggest that as it is not discussed on gentoo-dev. It’s pointless to talk about it in someones blog comments.Also, it hasn’t been discussed on gentoo-dev several times. It has been discussed on Diego’s blog countless times though.
>> Since I have been still fighting with the damned .la files and I’m pretty sure that even though I have explained some use cases most of my colleagues haven’t really applied them, I decided to go with a different approach this time: graphical guides.Yes Diego, because we all subscribe to your blog and follow your every word. 😛 If you want to write a guide for QA then do so, but don’t call people dummies because they don’t follow random shit you post on your blog. If you want something done about it then you actually have to talk with us (!).And if you want this fixed for good, why aren’t you talking to upstream? There was an in-depth discussion about removing .la files on the libtool mailing list recently. If you’re so sure about it, you should be able to convince them of their foolish ways.