cargo run causes linking problems (dynamic and static) on i686-pc-windows-gnu
#8990
Comments
|
Thanks for the report! I suspect though that that this may be an issue for the compiler itself rather than Cargo? Cargo seems like it may be unlikely to be too involved in what's going on here since it's just calling rustc perhaps? |
|
I don't know what happens under the hood when I enter |
|
If you could point us to the relevant code in Cargo that starts an executable we could dig a little deeper and see if we can narrow down the culprit further. |
|
Ah sorry I missed that! In that case it does indeed sound like a Cargo issue. Cargo will adjust I'm not entirely sure if we have a great location to point to since the adjustment for the target process command happens in a few locations, but for this sort of error it seems like the |
|
Maybe. I don't know anything about Windows, so I'm flying blind here, but @Ilia-Kosenkov has been very good at drilling down and trying to find what exactly goes wrong. Here is a WinDbg log from a case where the problem occurs (previously posted here): Not sure if the paths look correct or not. @Ilia-Kosenkov Could you regenerate this log for your simple example program, and could you also generate a comparable log for when the linking succeeds? Maybe we can pinpoint a path difference or a difference in the libraries that get loaded. |
It's quite likely. Maybe system libraries get mess-up when running 32-bit cargo on 64-bit OS due to SysWOW64 thing? Guess nobody has 32-bit OS to test these days? |
|
Here is part of the output of This looks like the problematic fragment, as it starts with loading For comparison, this is what happens if I just debug the produced executable: Again, I am not So far the only difference I see is that |
|
@Ilia-Kosenkov Could you check whether the same difference exists on the 64-bit system? It probably does but doesn't cause problems there. Maybe the two libraries that get pulled in from the toolchain have a conflict with zlib1.dll provided by msys2 on i686. In general it makes me uncomfortable to mix libraries from different sources (rust toolchain vs msys2), but maybe there have been other bugs in the past that required this sort of behavior? |
|
@clauswilke, It feels like However, if I debug just the executable, I see similar libraries referenced (notice that I have both |
|
Rust ships mingw-w64 GCC libs from version 7.X while MSYS2 is already at 10.2. Could you try on the CI to run this command after installing Rust? (posted from my mobile so there can a typo). |
|
@mati865, |
|
@Ilia-Kosenkov can you try replacing Rust shipped library with ones provided by MSYS2 (bash syntax): |
|
@mati865 Should we be able to avoid this problem by not using rustup at all and instead installing rustc and cargo via MSYS2? I'm also running into other linking problems that seem to be caused by interference between the two toolchains, and it seems to me not having two toolchains at all would be best. |
|
Yeah if it's toolchain differences than a Rust msys2 package, if one exists, likely solves this since it'll be guaranteed to use the same version of gcc you have on your system (and won't have the bundled copy like Rust releases). The only way I know of around this on Windows is to use an MSVC toolchain to cross-compile to the MinGW target. |
|
@mati865, |
|
@alexcrichton, @mati865, @clauswilke, |
|
@clauswilke MSYS2 Rust package is not always up to date and the main reason for it is packaging Rust crates into MSYS2 repo. Since rust-lang/rust#76167 there is no conflict between Rust shipped and system mingw-w64 toolchains. You can test it by removing toolchain shipped by Rust (
I think cross-compiling from When it comes to fixing: What Cargo (or maybe bindgen?) could do to fix this issue is copying (hard-linking if possible?) runtime dependencies next to created DLL. That would work since Windows first looks for the libraries next to your DLL/executable then searches PATH. |
|
@mati865 If I try to build an R package using Rust with See e.g. here: https://github.com/clauswilke/extendr/runs/1578651175?check_suite_focus=true#step:8:145 This goes away when I use |
|
For some unknown to me reason it tried to build |
This comment has been minimized.
This comment has been minimized.
|
@Ilia-Kosenkov sounds like you don't have i686 linker in |
This comment has been minimized.
This comment has been minimized.
|
@Ilia-Kosenkov that is right, I'd suggest moving this discussion somewhere else to avoid off-topic in this issue. |
|
I think there is nothing to do from Cargo perspective, if there are still issues they should be reported to main Rust repository. |
|
@mati865, while there can still be some issues with cross-compilation (or Thank you for the discussion, it helped us a lot. |
In the context of generating Rust bindings for R via
bindgen(libR-sys project, https://github.com/extendr/libR-sys), we have encountered a strange problem for the targeti686-pc-windows-gnuthat seems to trace back to somethingcargo rundoes when calling an executable it has just built.In brief, we noticed that when trying to run our
bindgenbuild script on 32-bit Windows, the program would abort with a linking error inlibclang. We first thought it was a packaging problem with the mingw package providinglibclang, and we reported it as such: msys2/MINGW-packages#7442. However, further investigation has shown that this is unlikely to be the case. Instead, we now suspect there's a problem withcargoitself.@Ilia-Kosenkov has created a minimal example of a Rust program calling
libclang, to mimic whatbindgendoes:https://github.com/Ilia-Kosenkov/rust_clang_run. This program compiles and runs just fine on 64-bit Windows, and it aborts with a linking error on 32-bit Windows, regardless of whether
libclangis linked statically or dynamically. But here's the kicker: This happens only when we run the program withcargo run. If we build the program withcargo buildand then run the executable by calling it directly, everything works fine. You can see this behavior in the GitHub Actions for the minimal example, e.g. here: https://github.com/Ilia-Kosenkov/rust_clang_run/runs/1565696019?check_suite_focus=trueIn the minimal example, we can of course work around the problem by not using
cargo run. But in the actual application,libclangis linked into the build script, and thus the compiled executable is always run bycargoand the linking error occurs.Related libR-sys issue with discussion and background: extendr/libR-sys#9
Note: We're using the
i686-pc-windows-gnutarget because that's a hard requirement set by the R project. We cannot usei686-pc-windows-msvcas a workaround, and we have not tested whether the problem exists oni686-pc-windows-msvc.The text was updated successfully, but these errors were encountered: