This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
Intercal needs gcc to build any executable, and in Nix/NixOS it needs to
be explicitly set in PATH environment variable. So, now ick is
conveniently wrapped.
Package changes from 3.6:
- CMake exports patch no longer necessary
- Cosmetic purity patch fix
- Build libc++ with private libc++abi headers visible from sources
- Work around bugs in lldb's configure scripts
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>
This effectively reverts 86c283824f76d849acbe6
("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.
Fixes#9044, close#9667. Thanks to @taku0 for suggesting this solution.
Now we have no modes starting with `/` or `+`.
Rewrite the `-perm` parameters of find:
- completely safe: rewrite `/0100` and `+100` to `-0100`,
- slightly semantics-changing: rewrite `+111` to `-0100`.
I cross-verified the `find` manual pages for Linux, Darwin, FreeBSD.