Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
On Friday 14 November 2008, Ryan Hill wrote: [Snip more pie-in-the-sky] Show me the code, please. If you weren't interested in hearing differing opinions, then why did you ask in the first place? :P I just thought it sounded like a tall order, saying that fixing libtool .la files would take some weekends to do, when this problem has existed for so long, yet noone has been able to fix it in a way that causes less pain than removal of all .la files does. IOW, I will believe promises of code when I see it. I won't be touching libtool. You can break that thing by just looking at it the wrong way. It'll eval your buttocks off and expr your behind, it's .3 MB of all posix-sh and it will make you regret you ever tried to wrap your head around it. [in re pulseaudio, I believed the news for 0.9.1 http://www.pulseaudio.org/wiki/OldNews] [Responding to the rest of the thread] I've given this some thought and I think I've been convinced that dberkholz' position is probably the most tenable. If this is to be done, we should do it in a documented Gentooish way. The problem with going down the FEATURES road are two-fold: 1) What should the behavior of the FEATURES flag be? I think it should act like an INSTALL_MASK=*.la and EXTRA_ECONF=--disable-static There should also be a function, let's call it exemptthis.la that would exempt a .la file from being punted, so the RESTRICT could be made on a per-la file basis. 2) Who implements in portage? [...I know nothing of portage internals...] 3) Grunt work? This should be rather easy. Just assign the bugs to me and I shall add RESTRICTs as-needed. But the problem is that we've known about this for aeons and nothing has been done about it. Diego tried to do something with popt and another package some time ago (bug 218286) but he was mostly shouted down and nobody touched it since. On .so bumps I've silently dropped .la files, which I think is the more gradualistic approach and it also has the advantage of causing only little or no (extra) breakage, but for the whole tree it could take decades, since some libs don't do .so bumps. Anyway, we really need to start punting .la files one way or the other. For desktop users of our distro, they do a lot more harm than good. For embedded, perhaps static linking serves some purpose, but really, if you can't afford dynamic linking, what are you going to run on your board? -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
On Sat, 15 Nov 2008 00:05:52 +0100 Peter Alfredsen [EMAIL PROTECTED] wrote: I just thought it sounded like a tall order, saying that fixing libtool .la files would take some weekends to do, when this problem has existed for so long, yet noone has been able to fix it in a way that causes less pain than removal of all .la files does. Sometimes, doing nothing is better than doing something. Anyway, we really need to start punting .la files one way or the other. For desktop users of our distro, they do a lot more harm than good. For embedded, perhaps static linking serves some purpose, but really, if you can't afford dynamic linking, what are you going to run on your board? No, for desktop users they're occasionally a minor inconvenience, which is more than offset by the large inconvenience of their removal. Unfortunately, enough fuss has been made about this that too many people will look bad if it's decided to do nothing, so things have reached the find the least bad something to do stage... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
On Sat, 2008-11-15 at 00:05 +0100, Peter Alfredsen wrote: Anyway, we really need to start punting .la files one way or the other. For desktop users of our distro, they do a lot more harm than good. For embedded, perhaps static linking serves some purpose, but really, if you can't afford dynamic linking, what are you going to run on your board? Just to quickly explain the purpose of static linking on embedded - it has nothing to do with avoiding dynamic linking (run-time?) cost, it has everything to do with size. If you have a library that only one or few applications use, you can end up with smaller size through static linking it, rather than using a shared library of it. This is because during static linking all functions that are not used can be discarded from the final binary, while with shared libraries all the code has to remain, because it isn't know what will be using that shared library, so the toolchain can not safely discard anything, even if you just have one application using some big library, but only using a small subset of its functionality. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
