Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross-compilation linux -> windows #7

Open
stuvet opened this issue Dec 23, 2022 · 1 comment
Open

Cross-compilation linux -> windows #7

stuvet opened this issue Dec 23, 2022 · 1 comment

Comments

@stuvet
Copy link

stuvet commented Dec 23, 2022

Hi,

Thanks for the work you've put into this. Very helpful.

So I've been having 'fun' with Linux -> Windows cross-compilation over the last few days. I'd initially seen the x86_64-pc-windows-msvc & i686-pc-windows-msvc on docs.rs and thought life would be good. After having some problems with compilation as a dependency I noticed the call for Windows PRs, so maybe I was accidentally misinformed by docs.rs? I certainly had some issues with my toolchain, so perhaps all the problems were at my end.

But for what it's worth:

Problem

In isolation librclone compiles on linux without error for targets x86_64-pc-windows-msvc & x86_64-pc-windows-gnu. Once try to reference any of its functions things start going very wrong, as it can't find librclone.a even though it's been produced - presumably compiled for the host architecture, according to an inserted go env at the same place of the librclone-sys/build.rs.

Solution

I think I've worked around all my issues, and now seem to be able to reference its functions as a dependency in cross-compiled x86_64-pc-windows-gnu & i686-pc-windows-gnu targets (though not -msvc so far).

I can do this with fb680cc by passing suitable GOOS, GOARCH, CC, CGO_ENABLED, CGO_CFLAGS & CGO_LDFLAGS to cargo build, but changing (particularly) CC may have other unwanted effects for other users.

I still need to do some testing though...

Proposal

Would you be interested in a PR which tries to autodetect some of these & inserts them as environment variables in the go build call? To warn you, there would likely need to be some good documentation on setting up the required environment too, & perhaps the inevitable mountain of 'issues' means this isn't something you'd like to support on here!

I guess a simpler alternative would be to leave the code as-is and offer some documentation for cross-compilation to windows.

Thoughts?

@trevyn
Copy link
Owner

trevyn commented Apr 6, 2023

There's currently no intentional support for Windows, cross-compilation or otherwise.

My primary concern regarding Windows is to have something that's testable in CI with a GitHub Actions Windows runner.

I'm hesitant to add too much that's specific to cross-compilation unless upstreaming it would be useful to you and it's fairly straightforward.

Anything that you could add for building on Windows, for Windows, would be appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants