@matthewbauer https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L960-L965 and any other uses of dontDisableStatic would be better controlling this than messing with stdenv itself.

@orivej Yeah it shouldn't disable shared libraries but I could see how some packages would think that.

@Ericson2314 shouldn't we have a "static" output anyway though? We don't want static libraries winding up in our closures.

The advantage of something like this is to avoid some of the package-specific hacks we are now using for static flags:

https://github.com/NixOS/nixpkgs/search?p=1&q=outputs+static&unscoped_q=outputs+static
https://github.com/NixOS/nixpkgs/search?q=--enable-static&unscoped_q=--enable-static

@matthewbauer sorry I meant your thing is better than those old things :). Let's go all in!

--enable-static will also undermine the effect of #41819 (once enabled for all Nixpkgs) because it adds e.g. old_library='libxml2.a' to libxml2.la. This can be mitigated by clearing old_library in the original libtool file before moveToOutput static, or by teaching pruneLibtoolFiles to clear it when the static library is not present near the libtool file.

Another problem is that the static outputs aren't included by default, so anything wanting to build statically needs to add their entire dependency closure manually (see e.g. git grep '\<glibc.static\>' for the gore).

On a side note, in this age where executables are PIE anyway for hardening reasons, what is actually different (with regards to code generation) in shared objects compared to static objects? There's a project (https://github.com/endrazine/wcc) which claims to be able to "[...] to 'unlink' (undo the work of a linker) ELF binaries, either executables or shared libraries, back into relocatable shared objects.". I wonder if that would work as a modern day replacement of getting each and every build system of every single package build both static and dynamic libs correctly?

I had thought about this years ago, but I concluded that it will be better to do these as separate derivations and e.g. standardize something like myLibrary.override { static = true; } (though we'd probably need some kind of "deep" or half-automatic override).

There are a few reasons. One is that IIRC often you need to compile the objects twice anyway, due to using different flags, e.g. if you want static I gather you often don't want position-independent code (to prefer performance over some security advantages) – so you don't really save much CPU time by building them at once. And there are some technical problems, like you need to propagate a different set of dependencies, and also this horrible trouble: #12085

Yeah I am split on whether this is a good idea as well. I like the standardized ".static" output over the usually not standard "enableStatic" vs "useStatic" vs "static", etc. I want to enforce something like this & have it built by Hydra through something like #39580 with some Hydra release magic but that has stalled. I am closing this for now though because @vcunat raises some good points on the usefulness of this.

Well, standardizing some name like useStatic is the easiest part, I think. Other technical details will be much more important to the decision which way to go – I've posted some I've remembered, but I haven't really dug deep into this due to not being motivated enough for static linking.

Yes. Which do you prefer? I think enableStatic is the ideal one because it maps well to the very common --enable-static configure flag. The thing is we probably need a corresponding "enableShared" flag so that we can avoid having both in the closure.

I would expect that by default enabling one would disable the other. enableStatic sounds fine to me, but I don't have a strong preference.

Is that how the configure flag is supposed to work? I guess when I see --enable-static I had always assumed they weren't mutually exclusive - otherwise it would be something like --link-target=static or --link-target=shared but maybe that is the convention.

The configure flags probably aren't exclusive (in standard autotools packaging), but for our flags it seems to make more sense, at least if we go this way of preferring to separate the static and shared builds...