use libc++ libc++abi, not libstdc++, when stdenv.cc.libcxx is non null
MACOSX_DEPLOYMENT_TARGET is defined by the environment, comment out the
definition in the Makefile as it breaks the c++ build.
Eliminate uses of `config.cudaSupport or false` and alike, since the
option is now declared in config.nix with a default value
fd .nix -t f -x sed 's/config\.cudaSupport or false, cudaPackages [?] [{][}]/config.cudaSupport, cudaPackages ? { }/' '{}' -i
fd .nix -t f -x sed 's/config\.cudaSupport or false/config.cudaSupport/' '{}' -i
fd .nix -t f -x sed 's/cudaSupport = pkgs.config.cudaSupport/inherit (pkgs.config) cudaSupport/' '{}' -i
fd .nix -t f -x sed 's/cudaSupport = config.cudaSupport/inherit (config) cudaSupport/' '{}' -i
Previously, hashcat was unable to use CUDA at runtime, and would warn:
> Failed to initialize the NVIDIA main driver CUDA runtime library.
> Failed to initialize NVIDIA RTC library.
> * Device #1: CUDA SDK Toolkit not installed or incorrectly installed.
> CUDA SDK Toolkit required for proper device support and utilization.
> Falling back to OpenCL runtime.
This remedies that, at least on NixOS.
This fixes the following compilation error:
```
clBuildProgram(): CL_BUILD_PROGRAM_FAILURE
/run/user/1000/comgr-64ff7f/input/CompileSource:2252:18: fatal error:
cannot open file
'/run/user/1000/comgr-64ff7f/input/inc_comp_multi_bs.cl': No such file
or directory
#include COMPARE_M
^
/run/user/1000/comgr-64ff7f/input/CompileSource:16:19: note: expanded
from macro 'COMPARE_M'
^
1 error generated.
Error: Failed to compile opencl source (from CL or HIP source to LLVM
IR).
```
Signed-off-by: Arthur Gautier <baloo@superbaloo.net>
This introduces a dependency on xxHash. Unfortunately, hashcat's
build system wants to rebuild xxHash from the source code located
in `<hashcat source root>/deps/git/xxHash`, a Git submodule whose
contents are not included in the source tarball we currently
download.
This could be fixed by either using a recursive git clone instead
a tarball download, or patching the build files to use an existing
installation of xxHash (i.e. the one already provided by Nix). I
believe the latter is preferable since it avoids the situation in
which the xxHash version used by hashcat is different to the xxHash
version used by all other Nix packages.
Fortunately, this situation has been greatly improved [1] since
release 5.0.0; the next release of hashcat should drop usage of
git submodules and provide better support for using existing
installations of dependencies.
[1] 4177e1ee28
It's necessary to do this in order to fix ckb's compilation, now that
fixupPhase rejects derivation results containing references to the temporary
build directory. It seems like good practice so I've added it to the
other packages that I maintain.
The current URL is broken, upstream has moved the download from .../files/ to
.../files_legacy/. But after fixing that, starting hashcat results in:
$ ./result/bin/hashcat
ERROR: this copy of hashcat is outdated. Get a more recent version.
So just update to latest.
New releases are on github, the license is now MIT and there are build
system changes.
