Created attachment 858501 [details]
New ebuild with static-libs support
Upstream lzlib is capable of building a static library (liblz.a), but the =app-arch/lzlib-1.13-r1 ebuild unconditionally disables this.
I'd like to have the static version of liblz for my own development. I also don't see why the ebuild should disallow other people from having it too.
I'm attaching a new version of the ebuild which builds and installs the static archive, depending on the "static-libs" USE flag.
Created attachment 858503 [details, diff]
Same thing in patch form
https://projects.gentoo.org/qa/policy-guide/installed-files.html#pg0302 is why things tend not to include it, but there's kind of a reasonable case for archivers to have it, so..
For homebrew configure scripts, we should probably establish some variable like EXTRA_ECONF for people to use.
Doesn't it accept --enable-static?
(In reply to Sam James from comment #2)
> https://projects.gentoo.org/qa/policy-guide/installed-files.html#pg0302 is
> why things tend not to include it, but there's kind of a reasonable case for
> archivers to have it, so..
For me, the use case is in development and packaging. I.e. where one would use a lzlib-dev package in other distributions.
I have a custom tool which will use lzlib, and I want to be able to deploy it unto other machines in a static binary that Just Works.
Part of this involves writing Go bindings for lzlib; I'd like to give future users of these bindings the possibility of building statically as well. Which means I need an existing static version myself, to develop and test.
(In reply to Michał Górny from comment #4)
> Doesn't it accept --enable-static?
The configure script is mostly a big case switch. It defaults to static=true and shared=false, then accepts (among other unrelated things) --disable-static and --enable-shared.