Apparently gwrap will not compile with guile-2.2 [1], even though the
news for version 1.9.15 says it "allows" Guile 2.2 [2]:
> it will _not_ compile using 2.2
Furthermore, it seems like it isn't being developed anymore either [1]:
> Also note that g-wrap itself is not being further developed anymore,
> it is recommended for new projects to use Guile's dynamic FFI.
Also, guile-gnome-2.16.5 is apparently compatible with guile-2.2 [3],
but I'm not sure how they built it with guile-2.2 because gwrap 1.9.15
(latest release) apparently doesn't build with guile-2.2. (And certainly
when I try to build gwrap 1.9.15 with guile-2.2 it doesn't work. Maybe
it can be made to work with certain compile flags, but I haven't pursued
that further due to [1] anyway.) This is why guile-gnome is still on
2.16.4 here. Because, although 2.16.5 can still (apparently) build with
guile-2.0.14, guile_2_0 is only at guile-2.0.13.
So to update guile-gnome to 2.16.5, guile_2_0 would first have to be
updated to 2.0.14.
[1]: http://lists.nongnu.org/archive/html/g-wrap-dev/2016-08/msg00001.html
[2]: http://www.nongnu.org/g-wrap/news.html
[3]: https://www.gnu.org/software/guile-gnome/news.html
building
Extracting Bazel installation...
Loading:
Analyzing: target //source/exe:envoy-static
ERROR: java.io.IOException: Could not read the crosstool configuration file 'CROSSTOOL file /tmp/nix-build-envoy-1.3.0.drv-0/envoy-v1.3.0-src/.home/.cache/bazel/_bazel_nixbld1/cbe181aaebf3d7253cbcf6057028e514/external/local_config_cc/CROSSTOOL', because of a parser error (945:1: Expected identifier. Found '%')
INFO: Elapsed time: 3.065s
FAILED: Build did NOT complete successfully
builder for ‘/nix/store/09wh9hd81529pgr3ddwfw68higfzkfgr-envoy-1.3.0.drv’ failed with exit code 2
error: build of ‘/nix/store/09wh9hd81529pgr3ddwfw68higfzkfgr-envoy-1.3.0.drv’ failed
The build provides as text a summary of the build, including the
absolute path of the compiler used for compilation. Unfortunately, this
pulls in stdenv.cc as a transitive closure.
So this change just calls remove-references-to as a postInstall step for
the one stdenv.cc dependency.
See #29889 for details.
The current `remotes` option is a string option containing nullmailer remote
definitions. However, those definitions may contain secret credentials and
should therefore not be put world-readable in the nix store.
I added a `remotesFile` option, which allows to specify a path to the remotes
definition file instead. This way, the definitions can be kept outside of the
nix store with more secure file permissions.
