The error was reported at HaxeFoundation/haxelib#152 and was fixed by
HaxeFoundation/neko#41 in HaxeFoundation/neko@ccc78c2, the latter being
fetchpatch'ed by us now.
This has caused the hxcpp build to fail on i686-linux with an "Invalid
array access" error.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced in 7ffb1f3bde.
Also added a small notice so that this hopefully won't happen with
future updates.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I also switched the build to depend on openjdk instead of Oracle's proprietary
one. I'm open to suggestions on how to determine the proper value of $JAVA_HOME
in a jdk-agnostic fashion. Right now, I just hard-coded the proper choice for
openjdk.
* pkgs/development/tools/database/sqldeveloper/default.nix:
Fixing interpreter paths was done by exporting PLAN9_TARGET, which
INSTALL looks at. Giving $PLAN9 to INSTALL does not achieve this, as
INSTALL only looks at its first argument so I removed the other
arguments to avoid confusion.
Perl is an optional dependency for a script that adds URLs to man pages,
I have added it to get fewer errors during install.
This effectively reverts 86c283824f
("If cuda headers are presented to nix [...]") and all the following
workarounds that was added due to that commit.
As far as I can tell[1] this hack isn't needed anymore. And moving
includes to $out/usr_include causes pain for cudatoolkit users, so
better get rid of it.
In patches that did more than the $out/usr_include workaround, I only
changed the line back to $out/include instead of re-generating the
patches and fully removing the changed line.
[1]: I build tested blender and caffe, and temporarily added
recurseIntoAttrs to rPackages and haskellPackages so that nox-review
could get proper coverage. However, many of the packages do not build
even before this patch. I also built CUDA samples with cudatoolkit7
that ran fine.
