Bugzilla Bug 74801

Shouldn't there be an use flag to enable compilation and installation of static
versions of these libraries? Am I missing something?

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

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.