build=host=x86 target=arm python

[eburimu]

Issue description

Hello,

I am looking for a way to get build=host=x86 target=arm python. Any ideas?

Tried pkgsCross.armv7l-hf-multiplatform.buildPackages.targetPackages.python but this gives build=x86 host=target=arm which I believe is the same as pkgsCross.armv7l-hf-multiplatform.python.

best.

[matthewbauer]

Python is target independent right now. The Python compiler should? be machine independent. So it doesn't really make sense to ask for build=host=x86 target=arm. Instead, I think you just want build=host=target=x86. buildPackages will give you one more "stage" each time, so this is possible to see for something that is target-specific like gcc. This can let you better understand how the sliding window works:

$ nix show-derivation nixpkgs.pkgsCross.armv7l-hf-multiplatform.buildPackages.buildPackages.gcc.cc | jq -r '.. .configureFlags?' | sed 's/ \?--/\n/g' | grep '\(build\|host\|target\)' 
build=x86_64-apple-darwin
host=x86_64-apple-darwin
target=x86_64-apple-darwin

$ nix show-derivation nixpkgs.pkgsCross.armv7l-hf-multiplatform.buildPackages.gcc.cc | jq -r '.. .configureFlags?' | sed 's/ \?--/\n/g' | grep '\(build\|host\|target\)'
build=x86_64-apple-darwin
host=x86_64-apple-darwin
target=armv7l-unknown-linux-gnueabihf

$ nix show-derivation nixpkgs.pkgsCross.armv7l-hf-multiplatform.gcc.cc | jq -r '.. .configureFlags?' | sed 's/ \?--/\n/g' | grep '\(build\|host\|target\)'
build=x86_64-apple-darwin
host=armv7l-unknown-linux-gnueabihf
target=armv7l-unknown-linux-gnueabihf

targetPackages is only useful in a very small number of cases.

[eburimu]

Hello @matthewbauer,

Thnx for the notes, much appreciated.

This might be lacking the details nevertheless, summarizes the problem. I was working on libnl and come accross the following problem.

  9985 building 'netlink/_capi' extension
  9986 swigging ./netlink/capi.i to ./netlink/capi_wrap.c
  9987 swig -python -O -nodefaultctor -o ./netlink/capi_wrap.c ./netlink/capi.i
  9988 creating build/temp.linux-x86_64-2.7
  9989 creating build/temp.linux-x86_64-2.7/netlink
  9990 armv7l-unknown-linux-gnueabihf-gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I../include -I../include -I/nix/store/h8i5qadlm6vfxayiizyk37k7f2m1a4h1-python-2.7.15/include/python2.7 -c ./net\
       link/capi_wrap.c -o build/temp.linux-x86_64-2.7/./netlink/capi_wrap.o
  9991 In file included from /nix/store/h8i5qadlm6vfxayiizyk37k7f2m1a4h1-python-2.7.15/include/python2.7/Python.h:61:0,
  9992                  from ./netlink/capi_wrap.c:150:
  9993 /nix/store/h8i5qadlm6vfxayiizyk37k7f2m1a4h1-python-2.7.15/include/python2.7/pyport.h:895:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
  9994  #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
  9995   ^~~~~
  9996 error: command 'armv7l-unknown-linux-gnueabihf-gcc' failed with exit status 1
  9997 builder for '/nix/store/hhnz2ymk3c6cvb2993b7if939l90bsc1-libnl-3.4.0-armv7l-unknown-linux-gnueabihf.drv' failed with exit code 1
  9998 error: build of '/nix/store/hhnz2ymk3c6cvb2993b7if939l90bsc1-libnl-3.4.0-armv7l-unknown-linux-gnueabihf.drv' failed

I thought I might need such a python yet you now say I might get away without it. In this build process, swig spits a c file that arm gcc tries to compile but the includes are wrong. They are from the x86.

Let me know if this belongs to the set of corner cases that you've ran into. Maybe fixd via depsBuildBuild?

ps. This is similar to https://github.com/NixOS/nixpkgs/issues/50925 so two outstanding specific to this.

best.

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.