| 24 Apr 2026 |
 matthewcroughan | and that this is one example of a trivial fix, but I didn't understand what build-system mapped to until you commented | 14:17:56 |
| matthewcroughan | There's another package I can test this on actually | 14:19:36 |
| matthewcroughan | laszip | 14:20:00 |
| matthewcroughan | In that case, pybind11 is in build-system but cross works | 14:20:12 |
| matthewcroughan | Oh, that doesn't seem to contain pybind, is my grep fscked up | 14:21:40 |
| matthewcroughan | Uh no there is pkgs/by-name/la/laszip and pkgs/development/python-modules/laszip | 14:22:28 |
| matthewcroughan | is it considered an issue when there is a by-name package that name clashes with something in a package set? | 14:22:42 |
| matthewcroughan | So ignore what I said.. let me try that again.. | 14:23:01 |
| matthewcroughan | Yes! My assumptions are correct :) | 14:23:40 |
| matthewcroughan | nix-build -A pkgsCross.raspberryPi.python3Packages.laszip fails like:
CMake Error at /nix/store/y4ippakbr3qyk3kv6iskdwix6jha5hbb-python3.13-pybind11-3.0.1/share/cmake/pybind11/FindPythonLibsNew.cmake:224 (message):
Python config failure: Python is 64-bit, chosen compiler is 32-bit
| 14:23:56 |
| matthewcroughan | Or not, seems this has nothing to do with pybind, although it was a good candidate | 14:24:32 |
| matthewcroughan | Oh wait yes it does, pybind is containing the cmake file that is producing that error | 14:25:58 |
| matthewcroughan | if(NOT _PYBIND11_CROSSCOMPILING
AND CMAKE_SIZEOF_VOID_P
AND (NOT "${PYTHON_SIZEOF_VOID_P}" STREQUAL "${CMAKE_SIZEOF_VOID_P}"))
if(PythonLibsNew_FIND_REQUIRED)
math(EXPR _PYTHON_BITS "${PYTHON_SIZEOF_VOID_P} * 8")
math(EXPR _CMAKE_BITS "${CMAKE_SIZEOF_VOID_P} * 8")
message(FATAL_ERROR "Python config failure: Python is ${_PYTHON_BITS}-bit, "
"chosen compiler is ${_CMAKE_BITS}-bit")
endif()
set(PYTHONLIBS_FOUND FALSE)
set(PythonLibsNew_FOUND FALSE)
return()
endif()
| 14:28:54 |
| matthewcroughan | It's checking the bits of the cmake binary | 14:29:16 |
| matthewcroughan | and then saying that this represents the bits of the python interpreter | 14:29:29 |
| matthewcroughan | which is not even remotely true :( | 14:29:32 |
| matthewcroughan | so putting cmake into buildInputs instead of nativeBuildInputs fixed this case | 14:29:49 |
| matthewcroughan | * It's checking the bits of the cmake binary and the python interpreter | 14:31:24 |
| matthewcroughan | * Maybe somehow it gets the path to the wrong python | 14:31:35 |
| matthewcroughan | * whoops | 14:31:41 |
| matthewcroughan | how do you pass the path to all the right things without removing cmake from the nativeBuildInputs though | 14:32:11 |
| matthewcroughan | this one is a weird one, because it passes dontUseCmakeConfigure = true, so what does it even need cmake for? Just to check the bits? | 14:33:57 |
| matthewcroughan | A similar issue exists here https://github.com/NixOS/nixpkgs/pull/511498/changes | 14:34:42 |
| matthewcroughan | If you provide curl to the nativeBuildInputs, it provides some files that causes the build system to link to shared objects for the host arch, rather than the cross arch | 14:35:17 |
| matthewcroughan | so the solution is to read the build system code and see that you can pass an absolute path to the utility from ${curl.dev}/bin that it actually wanted | 14:35:47 |
| matthewcroughan | Yeah, okay, I still don't know why the matplotlib case is fixed by simply moving pybind11 to the buildInputs. | 14:38:41 |
| matthewcroughan | Because it doesn't break native or cross. And I can't fix other derivations by doing the same. | 14:39:02 |
| matthewcroughan | Doing a lot more testing now but will take a while since rebuilding on staging | 15:17:49 |
| matthewcroughan | Bah.. too much else is broken on staging.. I will wait and apply my fix as an overlay until better able to review | 15:46:00 |
 hexa | vcunat since you are gobbling up staging-25.11 changes, can we try the new queue runner for that cycle? | 20:10:40 |
