setuptools-rust fails to cross-compile cryptography using crossenv #294
Comments
|
It's hard to investigate without a working environment, do you have a list of steps to reproduce your build issue locally using docker? |
|
@messense Yes indeed I do, and let me know if you need anything else: Clone my copy of our spksrc framework repository: Create the updated docker image: Access the docker image: Build a Options of interest for building are:
To build for every archs and every support Synology DSM Linux version (e.g. 6.1 & 7.0): Note that build logs are being output on the console but are also available in |
|
Follow to this, my issue seems to be somewhat due to Here's my finding using docker image above (always using a It works! Now let's try that using Still working! So the theory is that I have a working More on this first testing can be found SynoCommunity/spksrc#5435 (comment) Then I've resumed at trying to build Then build Interestingly enough it gets a little farther using A call using crossenv My conclusion is that |
th0ma7
changed the title
Does it still work if you also add all the |
|
Looks like this circles back to an issue I posted before? benfogle/crossenv#65 |
|
In our CI we cleared the setuptools-rust/.github/workflows/ci.yml Line 221 in 96684af |
|
I confirm, editing the I got a few SSL deprecation warnings, mays have to find a way to pass |
|
@messense is there an intent to include the |
No, we don't want to add too much assumption in Closing as resolved. |
|
@messense having a global option similar to |
I'm looking at getting guidance in order to get to building any rust python wheel properly under our framework under the SynoCommunity spksrc project, starting with
cryptography.We're using
crossenvwith all the necessary dependency bits AFAICT and we're building all wheels usingpipeither as cross-compiled or pure-python as needed.Note that while learning on the topic I ended-up figuring that
--targetwasn't the way to go as it ends-up building rustc host plugins (crates?) using the cross-compiling environment making things worst as they end-up being built for the target and impossible to run on the host.As such I'm now using env variables such as
CARGO_BUILD_TARGET="armv7-unknown-linux-gnueabihf"(platform dependent) which seems to bring me closer to my goal.The issue I believe I've been hitting is that, using
pipthe build environment, does not seems to find the proper linker. By default the cross-compiling environment sets all theCC,CXX,CFLAGS, etc. pointing to the cross-compiler toolchain. After quite a bit of reading it became obvious that neitherCCorLDenvironment variables wheren't being used to define the linker for the rustc compiler.As such I've tried passing it through the environment such as
CARGO_TARGET_ARMV7_UNKNOWN_LINUX_GNUEABIHF_LINKER="/home/spksrc/rustc/spksrc/toolchain/syno-armv7-7.0/work/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc"but it ends-up failing at linking time where the host default linker is being used:My thought is, can/shall I use options such as
--global-option=--target="armv7-unknown-linux-gnueabihf"or similar where I can enforce the default target and, most importantly, enforce the default linker?My current work at integrating rust python wheel cross-compiling is in PR SynoCommunity/spksrc#5435. Although note that github action logs won't provide much as it currently doesn't update the build Docker image until pushed to master.
As mentionned above, guidance would be much appreciated. Thnx in advance.
The text was updated successfully, but these errors were encountered: