The setup.py of `python-package` contains some path resolution magic to
find `libxgboost.so` which is needed for the python API.
Unfortunately the code is incompatible with Nix as it isn't compatible
with the store-based structure for each package and tries to express the
location of the shared object with relative paths.
The detection in `setup.py` and `xgboost/libpath.py` has been either
removed entirely or patched to link to the proper store path of the
`libxgboost` build input.
See https://hydra.nixos.org/build/77702715 for further reference.
Latest bugfix release with the following notable changes:
* Memory leak resolve for dispatcher
(06d4865445)
* Fix include path on status.h
(5bd4984f2a)
Additionally the patch had to be rebased onto the 3.2.9 branch as it
added XCode support including some CLang flags (namely `-fno-limit-debug-info`)
which are unsupported on GCC.
(see bccc28dd98)
ntl hasn't been updated in a while. So I'm doing that and adding myself
as the maintainer. I'm also adding some options and pinning the sage
dependency, since it is unfortunately not compatible with the latest ntl
yet.
I've also enabled the tests, since they don't take terribly long and are
worth the time in my opinion.
If empty directory isn't deleted, referer depenedencies will
fail with:
cp: missing destination file operand after '/tmp/nix-build-cabal-helper-0.8.0.2.drv-0/setup-package.conf.d/'
This is currently only the case for cabal-install, as cabal2nix
doesn't handle well buildable=False flags due to long-standing bugs
in Cabal itself.
With the recent update of BusyBox to version 1.29.0 in
d6aa506e3b there is now a new dependency
on libresolv.
This now throws a runtime error when executing ash, eg. whenever we do
something like this:
nix-build -E 'with import ./. {}; vmTools.runInLinuxVM hello'
The resulting error will be:
.../ash: error while loading shared libraries: libresolv.so.2: cannot
open shared object file: No such file or directory
I tried to override BusyBox with enableStatic, but that still requires
parts of glibc:
Static linking against glibc, can't use --gc-sections
Trying libraries: crypt m resolv
Library crypt is not needed, excluding it
Library m is needed, can't exclude it (yet)
Library resolv is needed, can't exclude it (yet)
Library m is needed, can't exclude it (yet)
Library resolv is needed, can't exclude it (yet)
Final link with: m resolv
In the long term maybe switching to a more minimal C library such as
musl would make more sense, but for now I just added libresolv.so to the
initrd which fixes the runtime error.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra, @rbvermaa
Signed-off-by: aszlig <aszlig@nix.build>
