Python package fails to find buildInputs

Help
1

I’m packaging cgal-bindings for NixOS, which depends on a number of C and C++ libraries. When I attempt to call the package, it outputs the following:

Executing setuptoolsBuildPhase
You are missing boost-thread
You are missing the gmp library
You are missing the mpfr library
You are missing the CGAL library

This is my package definition:

{ lib, stdenv
, fetchPypi
, python
, buildPythonPackage
, buildPythonApplication
, setuptoolsBuildHook
, boost
, swig
, eigen
, tbb
, cgal_5
#cgal dependencies
, gmp
, mpfr
}:

buildPythonPackage rec {
  pname = "cgal-bindings";
  version = "1.2";

  src = fetchPypi {
    inherit pname version;
    sha256 = "1b5aj83b1fv5h8dc2qg2s0c959njnpr884i30hni370la0s30l0x";
  };

  nativeBuildInputs = [ setuptoolsBuildHook ];
  buildInputs = [ boost swig eigen tbb gmp mpfr cgal_5];

  meta = with lib; {
    description = "CGAL bindings using SWIG";
    homepage = "http://cgal.org";
    license = with licenses; [ gpl3Plus lgpl3Plus];
    platforms = platforms.all;
    #maintainers = [ maintainers.raskin ];
  };
}

And it’s called through the following nix-shell script

{ pkgs ? import <nixpkgs> {} }:

let
  my-python-package = ps: ps.callPackage ./cgal-python {};
  python-with-my-packages = pkgs.python3.withPackages(ps: with ps; [
    (my-python-package ps)
  ]);
in
(pkgs.buildFHSUserEnv {
  name = "test-fhs-env";
  targetPkgs = with pkgs; pkgs: [ 
    python-with-my-packages
  ];
}).env

The setup.py associated with the PyPI package finds libraries, with distutils.compiler.find_library_file which seems like the standard way of doing it. Furthermore, if I create an FHS env with the dependencies and attempt to install cgal-bindings through pip, like so:

nix-shell ./test-fhs.nix
python -m venv .vev
source .venv/bin/activate
pip install cgal-bindings

Then the errors about missing libraries are limited to just:

You are missing the CGAL library

(This likely has to do with the fact that CGAL is a header only library, which is a problem I’ll have to address later)
Installing the dependencies with targetPkgs in an FHS env allows them to be found by the package, but installing them via. buildInputs does not seem to have this effect, which is a little perplexing.
What do I have to do in order to get the package to find these libraries? Why isn’t that the default Behaviour?

2

for python, you’ll have to inspect the setup.py logic to see how they are searching for file paths. They likely have them hardcoded.

3

I suggested initially that the package was using the standard means of looking for libraries, after digging around a bit more it seems like it is actually hardcoding the paths. These paths are as follows:

    header_paths.append("/usr/local/include")
    header_paths.append("/opt/local/include")
    library_paths.append("/usr/local/lib")
    library_paths.append("/usr/local/lib64")
    library_paths.append("/opt/local/lib")
    header_paths.append("/usr/include")
    library_paths.append("/usr/lib")
    library_paths.append("/usr/lib64")

You can see this in context on github, there’s a little more going on here than the snippet suggests but for the most part these are the relevant paths.
In any case, the fact that it is able to find the libraries in an FHS environment suggests that wherever it is looking for them is somewhere that NixOS agrees libraries belong (/usr/lib in this specific case).

4

They should probably adopt CMake, it would simplify a lot of path searching for dependencies.

However, you could probably do something like this:

You could add cmake to your nativeBuildInputs. The shellhook for cmake should populate a $CMAKE_INCLUDE_PATH and $CMAKE_LIBRARY_PATH which would contain the paths specified in buildInputs.

5

It actually ended up being even easier than that; all I had to do was add the following into my package:

LD_LIBRARY_PATH="${gmp}/lib:${mpfr}/lib:${boost}/lib:${swig}/lib";

LD_LIBRARY_PATH was one of the environment variables that the setup.py looks at. I also had to move swig from buildInputs to nativeBuildInputs since swig is an executable, not a library.
I can’t quite confirm that this has solved my problem because I’m still dealing with issues getting cgal_5 imported. As I said before, this is likely something to do with the fact that cgal is a header-only library and, unlike the other libraries, its derivation contains no compiled objects, only headers and a bunch of cmake files. I’ll probably have to do some more research on what a header-only library even is (especially in the context of NixOS) before I seek more help here.

6

LD_LIBRARY_PATH is intended to be used at execution time to modify linking behavior. It is not meant to provide a way for passing libraries to a build.

This is likely a misuse by upstream.

https://man7.org/linux/man-pages/man8/ld.so.8.html