Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 705330 - dev-libs/double-conversion USE=static-libs should be reinstated
Summary: dev-libs/double-conversion USE=static-libs should be reinstated
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Science Related Packages
Depends on:
Blocks: static-libs
  Show dependency tree
Reported: 2020-01-13 04:40 UTC by Konstantin (Qrator Labs)
Modified: 2020-10-23 21:07 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin (Qrator Labs) 2020-01-13 04:40:33 UTC
I understand the intentions behind getting rid of static linking, but removing support for it from existing ebuilds is much more harmful than static linking itself.
But I'm a developer and I use Gentoo like a Swiss knife because it gives me a control and freedom in what I do. I believe it is a very legit property of Gentoo that should be respected.
I'm not saying that every package have to support static linking and of course it shouldn't be enabled by default but unless bugs emerge caused by presence of `static-libs` USE flag (and no one handles that bug in other way), please, don't get rid of it from existing packages, even if there are no corresponding dependencies in the tree.

Please, revert commit 762ae8c32889f933907bfbacbafd201cb33c9304 and alike (09bf573ba60af609d172744fe89185ef58f76f0b, a217ed25f690d9d4ed7b492df1d0d4205830fa3f, 1cd1f503a17cda076d1bc160d41210b15bfa8741 (!!)). These commits are just deletions of code without any legit reason - no bugs are fixed, no possible future problems are solved.

Reproducible: Always

Steps to Reproduce:
1. Have `dev-libs/double-conversion static-libs` in /etc/portage/package.use
2. `emerge double-conversion`
3. Being a software developer, try to link some example program with double-conversion.a
Actual Results:  
Depending on compiler flags - either dynamic linking is forced or an linking error will occur

Expected Results:  
Successful linking against double-conversion.a
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2020-01-13 05:15:42 UTC
commit 762ae8c32889f933907bfbacbafd201cb33c9304
Author: David Seifert <>
Date:   Wed Jan 1 11:14:15 2020 +0100

    dev-libs/double-conversion: Remove USE="static-libs"

    Package-Manager: Portage-2.3.84, Repoman-2.3.20
    Signed-off-by: David Seifert <>
Comment 2 Agostino Sarubbo gentoo-dev 2020-05-28 14:56:16 UTC
See also:
Comment 3 David Seifert gentoo-dev 2020-10-23 09:29:57 UTC
Sorry, the complexity for CMake-based ebuilds just isn't worth our effort getting multibuild right.
Comment 4 Konstantin (Qrator Labs) 2020-10-23 14:14:20 UTC
The ebuild was using multibuild eclass, it was OK. Commit mentioned in previous comment was made without any good reason, so please, just revert it.
Comment 5 David Seifert gentoo-dev 2020-10-23 15:58:17 UTC
It is Gentoo policy to not install static libraries ( Reopening this bug will not make it happen.
Comment 6 Konstantin (Qrator Labs) 2020-10-23 21:07:28 UTC

The rule you mentioned doesn't force anyone to delete working code. We have this discussion in few different places before, I'll repeat the arguments, that wasn't beaten by you or mr. Gorny.

1. The rule says, that you shouldn't install static libraries
> unless ... they are explicitly required[... by themselves...]

So, if package is used by software developer (and there is no way other type of users should install this package directly), they might need static libraries. Also, when a person uses USE=static-libs, they explicitly require this behavior.

> USE=static-libs may be added for static libraries if they are necessary

witch was and should be the case here.

>  If both shared [and static] libraries are supported... [only shared should be installed by default]

Please, note, that shared linking is not really supported by upstream. E.g. they don't have it enabled by default and, at least when I checked last time, they didn't have shared configuration enabled in CI.

2. Your interpretation of policies violates the _goals_ of the policies:

p.3 says
> The policies try to help developers in providing a consistent end-user experience

Removing expected behavior of the package, getting rid of USE flag, creates very unpleasant and inconsistent behavior. See description of this bug.

>  The same concepts applied across different packages make it easier for user to achieve his goals

My goals was to use the package for the goals of software development. After that commit I wasn't able to.

> ...and reduce the likeliness of surprising behavior

dynamically linked non-portable resulting executable was definitely a surprise. Especially given the fact that *everything was working before your commit*.