Attached there is an ebuild patch that adds the USE 'static-libs' to the package net-libs/rb_libtorrent, so the ebuild can correctly compile/install .la/.a[1] files only if the end-users want them. I have tested this ebuild with qBitTorrent and it's working fine, but more testing around the packages that use rb_libtorrent is however necessary. Hope to be useful. Toffanin [1] rb_libtorrent doesn't use dlopen() so the compilation/installation of the .la/.a files is useless, see http://blog.flameeyes.eu/2009/04/18/some-details-about-our-old-friends-the-la-files
Created attachment 227467 [details, diff] rb_libtorrent-0.14.10-r1.ebuild.patch
Is there even a use case for static libs in the case of rb_libtorrent? That said, in order to proceed with this we need bug 271129 or a similar solution to be implemented. I refuse to break users' systems for such minimal gain. Reopen once that has been taken care of.
(In reply to comment #2) > Is there even a use case for static libs in the case of rb_libtorrent? I'm not following you, what are you asking for, exactly? > That said, in order to proceed with this we need bug 271129 or a similar > solution to be implemented. I'm aware of that proposal (#271129), but Gentoo QA Team have a different view of the problem which can be summarized as: "don't use a silver bullet solution for the problem but instead fix .la/.a file for every single package", which is the opposite of the proposal for #271129 and the reason of the existence of the USE 'static-libs' (actually used by ~60 packages and the number is increasing). If you don't trust me, just ask to Mark Loeser (halcy0n) or Diego Elio Pettenò (flameeyes) for confirmations, the latter is preferable as he is more involved in these problems; this isn't the first time that I submit similar patch sets, so it's better that you clarify with QA Team because the proposal (#271129) to inject lafilefixer's code inside portage isn't a solution to the problem (it's a dangerous workaround) and it isn't applicable blindly in all situations (there are scenario where .a/.la files are required and must be installed, see app-arch/libarchive for an example). Sincerely, I don't like the solution proposed in #271129 as it's a non-sense to compile static archives (sometime they are build twice, with and without Position-Independent Code) and then manually erase them through ebuild/portage when there are proper autotools/libtools options that disable/enable static archives and lafiles on-demand. I agree that for packages that lack autotools/libtool options can be a good solution to have FEATURE 'fixlafiles' to fix broken lafiles, but forcing globally that FEATURE it's a non-sense, it doesn't solve at all the problem of the wasted compilation and it is limiting Gentoo's user choice/freedom: 1- I don't want to compile the same objects twice or more time[1], especially on embedded targets; 2- I want to build a static version of the package X, so I need the static libs too, but the FEATURE 'fixlafiles' wiped all of them, leaving me with a broken static package despite the fact that its autotools options allow me to do a static compilation; > I refuse to break users' systems for such minimal > gain. Reopen once that has been taken care of. there isn't library breakage at all, rb_libtorrent just compiles/installs static archives but don't uses them; it's a waste of time, space and a useless pollution of the LD_PATH for not good reasons. You tell that there is a minimal gain, but I see only major gains; however my opinion is not so important, but before to close more of bug reports like this, please, go to the QA Team and ask for better explanations about all these problems and more important, ask for clear and official policies about the USE 'static-libs' vs FEATURE 'fixlafiles'. [1] http://blog.flameeyes.eu/2010/01/03/more-pointless-la-files
I have seen way too many problems with lafile removal (see for example bug #218286 and bug #275597 and notice all the confused users). We need a clear, well-documented QA policy and a global solution that prevents the problems that so many users have run into. Until that happens, I want a moratorium on all lafile removal.
(In reply to comment #4) > I have seen way too many problems with lafile removal (see for example bug > #218286 and bug #275597 and notice all the confused users). [CUT] I want a moratorium on all lafile removal. whatever you want, but you're confusing the problem revolved by USE 'static-libs' with the problem resolved by #271129; they're two different things: 1- a problem of static archive (.a files) compiled and installed but never used (they are useful only for compilation of static libraries and completely useless for shared libraries); 2- a problem of lafiles with wrong reference inside them; #271129 solves the latter, my patch set (and in general the USE 'static-libs') solves the former; whatever you face these problems, the latter can't be used to solve the former, so closing my bug because #271129 will fix also this report it'is a lie. Just to make myself more clear, rb_libtorrent doesn't install broken lafiles, they are valid and my patch set simply remove them and the static archives (which are a different things to lafiles, in case you didn't know it) for the shared compilation because they are useless: they aren't used to load plugins, they aren't used by nothing in portage so there aren't libraries breakage by deleting them and just leaving them around the system is only a waste of space and a useless slowdown for the linker. #271129 will never do nothing of my proposed patch set. However, I have just warned the QA Team about this report and asked for better explanations about this topic (handling of static archives vs lafiles) as I see a lot of confusion from you (and other Gentoo Developers too) and the topic can become more dangerous in the future if it will be underestimated.
