You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you set cudaSupport = True, although it sets the CMAKE flag correctly the resulting package isn't actually built correctly as cmake can't find cuda so it unsets the flag. This is due to the incorrect usage of pkgs.stdenv.mkDerivation instead of pkgs.cudaPackages.backendStdenv.mkDerivation when building the cuda related packages. The correct usage can be seen in the OpenCV package. It also tries to build with CUDA by default which is wrong.
dlib takes fftw as a build input
Dlib hasn't supported fftw since 2015 however there are leftover references to it in cmake which might lead people to think it does support fftw. fftw should be removed.
Taking in openblas rather than blas and adding lapack
As mentioned in this pr it makes more sense to have blas as an input into dlib rather that openblas so that people can override it with other BLAS implementations e.g mkl more easily if they want to. The package was also missing lapack which should be added.
Steps To Reproduce
Steps to reproduce the behavior:
Build the package, it tries to build with CUDA by default.
I made an example repo with a fairly simple nix flake that let's you switch between my patch and the original package.
#include<iostream>#include<opencv2/core.hpp>#include<dlib/dnn.h>intmain()
{
#ifdefDLIB_USE_CUDA
std::cout << "Dlib is compiled with CUDA support." << std::endl;
#else
std::cout << "Dlib is not compiled with CUDA support." << std::endl;
#endif#ifdefDLIB_USE_BLAS
std::cout << "Dlib is compiled with BLAS support." << std::endl;
#else
std::cout << "Dlib is not compiled with BLAS support." << std::endl;
#endif#ifdefDLIB_USE_LAPACK
std::cout << "Dlib is compiled with LAPACK support." << std::endl;
#else
std::cout << "Dlib is not compiled with LAPACK support." << std::endl;
#endifreturn0;
}
switching from my fix to the original bugged package on 23.11 before openblas was added.
Describe the bug
Not building with CUDA
When you set
cudaSupport = True
, although it sets the CMAKE flag correctly the resulting package isn't actually built correctly as cmake can't find cuda so it unsets the flag. This is due to the incorrect usage ofpkgs.stdenv.mkDerivation
instead ofpkgs.cudaPackages.backendStdenv.mkDerivation
when building the cuda related packages. The correct usage can be seen in the OpenCV package. It also tries to build with CUDA by default which is wrong.dlib takes fftw as a build input
Dlib hasn't supported fftw since 2015 however there are leftover references to it in cmake which might lead people to think it does support fftw. fftw should be removed.
Taking in openblas rather than blas and adding lapack
As mentioned in this pr it makes more sense to have
blas
as an input intodlib
rather thatopenblas
so that people can override it with other BLAS implementations e.gmkl
more easily if they want to. The package was also missing lapack which should be added.Steps To Reproduce
Steps to reproduce the behavior:
Build the package, it tries to build with CUDA by default.
I made an example repo with a fairly simple nix flake that let's you switch between my patch and the original package.
Fix
I have created a PR which fixes these issues.
Expected behavior
For it to build with CUDA.
Screenshots
How CMAKE fails
For this simple c code
switching from my fix to the original bugged package on 23.11 before openblas was added.
Notify maintainers
@christopherpoole
Metadata
Please run
nix-shell -p nix-info --run "nix-info -m"
and paste the result.Add a 👍 reaction to issues you find important.
Thanks!
The text was updated successfully, but these errors were encountered: