Re: [gentoo-dev] RFC: Installation of static libraries, USE=static-libs proposal
On Sun, 2008-07-20 at 15:40 +0400, Peter Volkov wrote: > В Втр, 01/07/2008 в 05:05 +0300, Mart Raudsepp пишет: > > Over a year or two ago, it was communicated that it supposedly a policy > > that USE=static > > Well, I don't have web-reference at hand now, but there was a thread in > gentoo-dev with the subject: "Say no to static libraries!". Summarizing > some ideas from there: > > 1. Some packages will break if you build their deps with USE=static. > This can be fixed when we start to use USE-deps in the tree. > > 2. We already have mechanism to make what you want. Just drop > EXTRA_ECONF="--disable-static" into your make.conf and to workaround > problem stated in point 1 use > > EXTRA_ECONF="${EXTRA_ECONF/--disable-static}" > > in /etc/portage/env/cat/pkg. (For those who interested list of packages > for which I have to filter --disable-static is in attachment). I'm going to simply drop the remaining USE=static's where appropriate, if upstreams choice is to disable static libraries, and we'll see even later what to do about those that don't default to not building static libraries. For now I stumbled on just gtk-engines. That is, some GNOME packages make it their own business to override the automake default of building both - they call AM_DISABLE_STATIC. So for those I'll just drop any --{enable,disable}-static (as I notice) and honor upstreams choice in not building static libraries. This also means nothing uses or needs the static libraries because all GNOME tinderboxes and jhbuild based development machines would scream in agony if it broke anything. > Well, I'm using EXTRA_ECONF for more then year now and I'd like to say > that it's not perfect solution. Not all packages are autotools based and > ignore --disable-static and now I have 103M of static libs on my > desktop. So now I'm all for having static-libs USE flag. But please, > don't do that on per-package base. Make an eclass for that. Think about > not-autotools packages, and don't put it in the tree until we start > using USE deps. I know of absolutely no GNOME package that needs its static libraries installed. Only exception is glib, but that is a lower level library, not a GNOME one - there we explicitly enable it for syslog-ng possible use primarily. And for glib I'm quite cool in enabling it always, as my take on glib is that it's a standard C library that makes C actually usable and powerful, just as libstdc++ makes C++ more powerful, and should be universally available to all. Though an alternative would be to install it in /lib, so that boot tools can use it and not need to link statically - having syslog-ng in mind primarily. > Thanks for reiterating this discussion. I wanted to return to it soon as > seems that USE deps are really about to enter our life. And now I'm reiterating it again the first time since 3 months. > And BTW, seems that all gnome packages obey EXTRA_ECONF ;) And probably G2CONF too, but we like to use that for ebuild use only - we aren't sure we have G2CONF="${G2CONF} foo" everywhere, etc. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Installation of static libraries, USE=static-libs proposal
В Втр, 01/07/2008 в 05:05 +0300, Mart Raudsepp пишет: > Over a year or two ago, it was communicated that it supposedly a policy > that USE=static Well, I don't have web-reference at hand now, but there was a thread in gentoo-dev with the subject: "Say no to static libraries!". Summarizing some ideas from there: 1. Some packages will break if you build their deps with USE=static. This can be fixed when we start to use USE-deps in the tree. 2. We already have mechanism to make what you want. Just drop EXTRA_ECONF="--disable-static" into your make.conf and to workaround problem stated in point 1 use EXTRA_ECONF="${EXTRA_ECONF/--disable-static}" in /etc/portage/env/cat/pkg. (For those who interested list of packages for which I have to filter --disable-static is in attachment). Well, I'm using EXTRA_ECONF for more then year now and I'd like to say that it's not perfect solution. Not all packages are autotools based and ignore --disable-static and now I have 103M of static libs on my desktop. So now I'm all for having static-libs USE flag. But please, don't do that on per-package base. Make an eclass for that. Think about not-autotools packages, and don't put it in the tree until we start using USE deps. Thanks for reiterating this discussion. I wanted to return to it soon as seems that USE deps are really about to enter our life. And BTW, seems that all gnome packages obey EXTRA_ECONF ;) -- Peter. dev-libs/popt dev-libs/lzo dev-libs/libpcre dev-libs/xmlrpc-c dev-libs/libol media-libs/pdflib media-sound/audacity sys-devel/gdb sys-devel/libtool sys-apps/ed sys-apps/ed sys-fs/fuse dev-ruby/rcairo dev-ruby/rcairo
[gentoo-dev] RFC: Installation of static libraries, USE=static-libs proposal
Hello again, Over a year or two ago, it was communicated that it supposedly a policy that USE=static should only control if a package installs static libraries INSTEAD of shared libraries, and never to be used to control if static libraries are installed in _addition_ to shared ones or not. Packages were coerced to stop using USE=static for controlling that, and most of them ended up unconditionally installing both static and shared libraries. What's worse - they were told that if a package can provide both shared libraries and static libraries at once, it just MUST (or SHOULD) install them both instead of choosing to not ship the static libraries. End result that affects me: GNOME does not fit on LiveCD installation media anymore. So I'm proposing a USE=static-libs or similar to get out of this problem, and a lifting of the supposed (I wasn't around as a dev that long ago to know for sure) policy of having to install both instead of choosing to never install static libraries. I am quite sure that absolutely nothing whatsoever uses about 97% of the static GNOME libraries we are now installing as an end result. How can I be sure? Because everything worked just fine when static libraries weren't installed in the past thanks to that not happening from USE=static missing on most systems for years, and you'd have to be quite crazy if you required static version of desktop libraries with well established and followed ABI guarantees. Those that aren't absolutely sure that there is no use case for static libraries, could then use a USE=static-libs or similar to not unnecessarily install static libraries that are not going to ever be used. And LiveCD media could avoid all these static libraries, that it currently has to ship just because the packages by default install that cruft for no real technical reason (and it has to follow that due to GRPs). I would use USE=static-libs on packages like gtkmm, that have good reasons to provide a static version - it allows Gentoo users that would like to do commercial or universal C++ based development against Gentoo system packages, as it avoids feared libstdc++ ABI breaks (there's even a request for it in bugzilla). There are packages in the tree that are required to install static libraries, or something else in the system breaks. So INSTALL_MASK=*.a is not a solution in my eyes. Useful comments, thoughts, agreements? I have had some additional ideas for handling static libraries better at a package manager level, but those still need to be fleshed out and put into writing. Things like possibility to rebuild all packages that link to a static library that was now upgraded, so the higher level package could use a relinking to benefit from the bug fixes from the new library; optional ability to install only the type of library currently needed - shared or static, etc. Much of it goes to blue-sky ideas though with minimal benefit for normal desktop/server systems and potentially high maintenance effort, so I haven't put much effort into putting it into writing. But maybe someone interested wants to chat on IRC on the topic. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part