Issue description
The PR #275947 introduced a new attribute in stdenvAdapters, the experimental adapter useLibsFrom = stdenvForLibs: stdenvForCC: ... that constructs a stdenv with the former argument's "standard libraries" (chiefly libstdc++) and the latter's compilers and tools. The intended use case is using older toolchains (gcc12Stdenv) to build shared libraries to be loaded in processes that may require a newer libstdc++ (one from the "default" stdenv, e.g. gcc13). The particular form of the adapter is a result of a brief exchange on Matrix, not a product of thoughtful consideration or any reasonable review process.
Impossible promises
As explicated in #282356, for this to actually work in non-trivial settings we'd need to be able to compose multiple cc-wrappers (in particular, through their cc and gccForLibs arguments). This may not actually be trivial to implement, in which case the new adapter is dangerous (it's promising something we couldn't provide).
Leaky interfaces
Additionally, the "adapter" interface is expressed in terms of wrapped values: it doesn't accept e.g. ccForLibs or a (made up name, meaning to refer either to libcxx or gcc.cc.lib) cxxStdlib as is, but only boxed inside a stdenv. The same applies to the cc-wrapper itself: it takes two different inputs, libcxx and gccForLibs, that impact the same aspect of the wrapper and may be specified individually or simultaneously. In the latter case, inferring the priorities requires consulting with the documentation.
It may be a revealing symptom that downstream expressions are sometimes tempted to inspect the cc-wrapper for their needs, e.g. to infer which implementation of the c++ standard library is being used, or whether the shared libraries' location is expected to be prefixed with the platform's "triple". A more frequent and innocuous need is to infer whether the wrapper contains a gcc or a clang. We should perhaps set (document) explicit boundaries so that cc-wrapper may be treated as a black box, and one with the minimal surface. It's likely OK to ask cc.isClang. On the other hand, a downstream package trying to directly access the c++ standard library might signal that we need to expose a more constraint tool (possibly useLibsFrom is one).
Some possibly motivating examples:
Rigid interfaces
The current interface might be too rigid. Example: the current form of useLibsFrom allows one to specify which library to use both and build- and run-times. We couldn't express e.g. a requirement like "use the oldest available libc/libstdc++ with a slightly less old gcc, but then put the newest possible libstdc++ in the runpaths". I don't know if this is a valid use-case (why not also use the oldest possible gcc?), but if it were we'd fail to accommodate it.
Notify the maintainers
I've no experience with the wrapper or with stdenv, so I'm hoping for some advice here. @RaitoBezarius had dropped some comments on the matter before, even though this probably isn't his main area of interest. I understand @Ericson2314, @trofi, @aszlig, and @a-n-n-a-l-e-e have been deeply involved with these subsystems, if any of you have the time? Naturally, ideas from @amjoseph-nixpkgs would be very welcome
Issue description
The PR #275947 introduced a new attribute in
stdenvAdapters, the experimental adapteruseLibsFrom = stdenvForLibs: stdenvForCC: ...that constructs a stdenv with the former argument's "standard libraries" (chiefly libstdc++) and the latter's compilers and tools. The intended use case is using older toolchains (gcc12Stdenv) to build shared libraries to be loaded in processes that may require a newer libstdc++ (one from the "default"stdenv, e.g. gcc13). The particular form of the adapter is a result of a brief exchange on Matrix, not a product of thoughtful consideration or any reasonable review process.Impossible promises
As explicated in #282356, for this to actually work in non-trivial settings we'd need to be able to compose multiple cc-wrappers (in particular, through their
ccandgccForLibsarguments). This may not actually be trivial to implement, in which case the new adapter is dangerous (it's promising something we couldn't provide).Leaky interfaces
Additionally, the "adapter" interface is expressed in terms of wrapped values: it doesn't accept e.g.
ccForLibsor a (made up name, meaning to refer either tolibcxxorgcc.cc.lib)cxxStdlibas is, but only boxed inside a stdenv. The same applies to thecc-wrapperitself: it takes two different inputs,libcxxandgccForLibs, that impact the same aspect of the wrapper and may be specified individually or simultaneously. In the latter case, inferring the priorities requires consulting with the documentation.It may be a revealing symptom that downstream expressions are sometimes tempted to inspect the
cc-wrapperfor their needs, e.g. to infer which implementation of the c++ standard library is being used, or whether the shared libraries' location is expected to be prefixed with the platform's "triple". A more frequent and innocuous need is to infer whether the wrapper contains a gcc or a clang. We should perhaps set (document) explicit boundaries so thatcc-wrappermay be treated as a black box, and one with the minimal surface. It's likely OK to askcc.isClang. On the other hand, a downstream package trying to directly access the c++ standard library might signal that we need to expose a more constraint tool (possiblyuseLibsFromis one).Some possibly motivating examples:
Rigid interfaces
The current interface might be too rigid. Example: the current form of
useLibsFromallows one to specify which library to use both and build- and run-times. We couldn't express e.g. a requirement like "use the oldest available libc/libstdc++ with a slightly less old gcc, but then put the newest possible libstdc++ in the runpaths". I don't know if this is a valid use-case (why not also use the oldest possible gcc?), but if it were we'd fail to accommodate it.Notify the maintainers
I've no experience with the wrapper or with stdenv, so I'm hoping for some advice here. @RaitoBezarius had dropped some comments on the matter before, even though this probably isn't his main area of interest. I understand @Ericson2314, @trofi, @aszlig, and @a-n-n-a-l-e-e have been deeply involved with these subsystems, if any of you have the time? Naturally, ideas from @amjoseph-nixpkgs would be very welcome