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? Unfortunately, no. 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.
