You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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 targetsx86_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 findlibrclone.a
even though it's been produced - presumably compiled for the host architecture, according to an insertedgo 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?
The text was updated successfully, but these errors were encountered: