| Summary: | some libraries (glib, gtk, glibmm, gtkmm, ...) don't install static libraries by default | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tiago de Paula Peixoto <tiago> |
| Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | gnome-mm+disabled, jakub, slava |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://www.gentoo.org/proj/en/desktop/gnome/meetings/2009/06-15.summary.txt | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 165629 | ||
|
Description
Tiago de Paula Peixoto
2004-12-17 18:16:12 UTC
well ive added static USE flag to the gtk/glib/pango ebuilds. I see no point in having them build static libs by default. Personally I think this should be handled in a different way than adding it as a USE flag to every ebuild under the sun. I thought the static useflag is mainly used for boot critical packages as fsch, ssh, etc... Only then it would make sense to add static to make.conf to enhance stability. I do not get the point why packages as evolution or cinelerra use the static flag. Perhaps there should be two flags (e.g. static and critical) to clearify. See also: http://forums.gentoo.org/viewtopic-t-358304.html Reopening this wrt Bug 201569 Comment #0. We should *explicitely* enable both static and shared since now we apparently get arch-specific results for some weird reason I didn't investigate (yet), clearly undesired result. This bug was about glib, pango and gtk+. None of these have a static USE flag (i.e, everything done originally on this bug has been reverted long ago) and all of them default to what upstream seems fitting, except glib which stuff in portage actually needs a static version of (syslog-ng-2.*). So I feel inclined to mark this reopened bug as OBSOLETE (if such a resolution existed) and handle specific cases in specific new bugs. As for building a static version of everything - there is no real reason to do that (not for everything...) and it contributes to us not fitting on LiveCD anymore. That's my take on it, and apparently I need to find time to open up a discussion on mailing list about this topic afterall, while forgetting about it half a year ago when this stuff came up. (In reply to comment #4) > This bug was about glib, pango and gtk+. I haven't changed the summary at all, so I'd respectfully disagree. ;) http://bugs.gentoo.org/show_activity.cgi?id=74801 (And yeah the original solution w/ USE=static was just wrong.) > None of these have a static USE flag > (i.e, everything done originally on this bug has been reverted long ago) and > all of them default to what upstream seems fitting Well, 'whatever upstream seems fitting' is an unwanted result if that means that you get static libs on x86 and don't on amd64 or other arches. > As for building a static version of everything - there is no real reason to do > that (not for everything...) and it contributes to us not fitting on LiveCD > anymore. Uhm... there'd be plenty of space on livecd for more useful things if we stopped sticking nonsensical stuff like full-blown evolution w/ Exchange connectivity on release media. :) YMMV. (In reply to comment #5) > (In reply to comment #4) > > This bug was about glib, pango and gtk+. > > I haven't changed the summary at all, so I'd respectfully disagree. ;) > http://bugs.gentoo.org/show_activity.cgi?id=74801 (And yeah the original > solution w/ USE=static was just wrong.) Fair enough. I'll have to draft up my points to the mailing list when I get some time, and investigate the specific case closer. Other team members welcome to do that too, of course > > As for building a static version of everything - there is no real reason to do > > that (not for everything...) and it contributes to us not fitting on LiveCD > > anymore. > > Uhm... there'd be plenty of space on livecd for more useful things if we > stopped sticking nonsensical stuff like full-blown evolution w/ Exchange > connectivity on release media. :) YMMV. As opposed to the static libraries that absolutely nothing in the tree or CD uses, Evolution Exchange is a very useful thing for those that need to be capable of reading their e-mail in any shape or form under some environments. Besides, that's release teams decision to include it and on top of the rest of Gnome just maybe 500KB of extra when squashed. I can understand the desire to have static libs for C++ stuff though, yes. leio: So.....what's going on with this? If you disagree with the behaviour of USE=static, please get a discussion going on g-dev@ about it. (In reply to comment #7) > leio: So.....what's going on with this? If you disagree with the behaviour of > USE=static, please get a discussion going on g-dev@ about it. I don't disagreed with the behaviour of USE=static. I disagree with the policy that if shared and static libraries are available at the same time that they must be both installed. I haven't had much free non-sleepy time lately, hopefully next week I can write the mail.. There is a temporary solution (at least for glibmm and gtkmm): add the following line to the make.conf: G2CONF="--enable-static" With this option, gtkmm and glibmm are built with static libraries. Meanwhile I have made a thread about it on the mailing list with no objections on USE=static-libs and not installing them when not useful (not C++ stuff): http://archives.gentoo.org/gentoo-dev/msg_1f8c66a51e033250a7aaf416a09da3f3.xml I'll push forward once I am back home from Istanbul (conference and a few vacation days :) after 15th July Can we get moving on this bug again? I don't recall what happened exactly with the static-libs proposal, but can we get the council to approve/disapprove this if that's what you want to go with? And if not, have the static libraries built unconditionally. Shouldn't we reassign this bug to the council? /me votes for USE="static-libs" which would be turned off in the base profile. Cheers From gnome herd meeting summary:
* Static libraries
- Consensus was to only have static libs for glib and C++ bindings. And to add
it to the eclass as --disable-static for the rest (to be overriden on a
per-package basis).
- Anything that uses gtk+ will not work with static libs because gtk+ uses
dynamic loading
If you find an infringment to this basic rule or feel that you need static-lib in a specific case, you can fill a report for us to fix the issue. Closing invalid since the actual enumaration in summary looks totaly wrong.
|
