Building on i686-pc-windows-gnu #9
Comments
|
Hi @CGMossa, Another thing I have no explanation for - my path contains both However, with Below is the result of dump.txt |
|
Using the R executable to find It's possible that we need the build script to detect whether it's trying to build a 32bit or a 64bit target and modify the paths accordingly. Could you post the typical path layout on Windows when both 32bit and 64bit versions are installed? Do they use two different |
|
@clauswilke, Within \include
and platform-specific Here, So, to build a There is yet another way. Default and So, for instance (using powershell for the sake of example), a query of the form and |
|
So we have the same |
|
I have amended my PR #12 to set different library paths depending on the target architecture. But I can't test it since I don't have windows. Could you guys test it? Note that you'll have to set the |
I still see the same error on my MSYS2. The error @Ilia-Kosenkov described in #9 (comment) is solved, but the original one stays the same. This error comes from clang-sys crate's validation: I really don't understand why |
|
Try to print out the target thats used in the clang call for creating the
bindings in the build.rs file. Also, unrelated, the current settings makes
all terminal calls msys calls, and none are cmd or Powe shell. See the
default part of the msys setup.
…On Sat, Dec 12, 2020, 14:29 Hiroaki Yutani ***@***.***> wrote:
I have merged #12 <#12>. Does
this close this issue?
I still see the same error on my MSYS2. The error @Ilia-Kosenkov
<https://github.com/Ilia-Kosenkov> described in #9 (comment)
<#9 (comment)> is
not solved, but the original one stays the same.
This error
thread 'main' panicked at 'Unable to find libclang: "couldn\'t find any valid shared libraries matching:
[\'clang.dll\', \'libclang.dll\'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found
(invalid: [(C:\\...\\msys2\\current\\mingw32\\bin\\libclang.dll: invalid DLL (32-bit)),
(C:\\...\\msys2\\current\\mingw32\\bin\\libclang.dll: invalid DLL (32-bit))])"',
comes from clang-sys crate's validation:
if cfg!(target_pointer_width = "64") && magic != 523 {
return Err("invalid DLL (32-bit)".into());
}
I really don't understand why target_pointer_width is 64 when we specify
the target of 32bit...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIDVSHTNC3WAFK6KDOKS3TSUNV47ANCNFSM4T3IANRQ>
.
|
Here's printed-out
|
|
This looks good.
I have never succeeded in building the 32 bit binaries myself.
…On Sat, Dec 12, 2020, 15:19 Hiroaki Yutani ***@***.***> wrote:
Try to print out the target
Here's printed-out bindgen_builder.command_line_flags(). Is this the same
on your environment?
["wrapper.h", "--rust-target", "1.40", "--blacklist-item", "FP_NAN",
"--blacklist-item", "FP_INFINITE", "--blacklist-item", "FP_ZERO",
"--blacklist-item", "FP_SUBNORMAL", "--blacklist-item", "FP_NORMAL",
"--no-derive-default", "--generate",
"functions,types,vars,methods,constructors,destructors", "--",
"-IC:\\Program Files\\R\\R-4.0.2\\include", "--target=i686-pc-windows-gnu"]
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIDVSHWU3N4VIYMJYWFP43SUN3Y5ANCNFSM4T3IANRQ>
.
|
|
Yeah, I think we are stuck in front of the same problem... This seems because rustup default stable-i686-pc-windows-gnuI can pass the validation, but I still get this error (the message says "The specified procedure could not be found." Sorry I don't know how to show English messages...):
|
|
I think what is happening is that If you switch the default toolchain, you also need a 32-bit clang. Did you install that? The github action does not. |
Yes, I just followed https://github.com/extendr/libR-sys#windows-specific-instructions Btw,
it seems GitHub Actions runner already has it installed. I tried to install (from my test branch: https://github.com/yutannihilation/libR-sys/runs/1542066028?check_suite_focus=true#step:3:33) |
|
Side note: I find it so confusing to figure out what is and isn't already installed in the GitHub Actions runner. And if you once install something and then remove the install line it still remains in the cache. I wish there was an easy way to just clear the cache. |
|
@yutannihilation , |
|
I think the next step is to figure out where exactly the 127 error is generated (Windows or mingw) and what it means. It may also be helpful to file an issue with the bindgen repo. I can reproduce this error in the GH actions, see my latest PR (#25). |
|
have you done |
|
@clauswilke, For some reason, the build script does not retrieve error description from the error code (which is a standard practice), so we are left with code 127. If you try googling enum value |
|
@lebensterben, |
|
Some thoughts: 1. You should be able to inspect the build script that cargo has built. In the GHA runs, it's in If you don't get this type of output, run 2. I think the most likely reason why the linking doesn't work is that there's another clang version that rustc somehow finds as it builds the build script. This could be due to 3. Related to the previous point, instead of setting |
|
I just tried point 3 from my previous comment and it didn't help. One other thing somebody could try: Set up a minimal bindgen project, without R, just for a trivial C hello-world library, and see if that compiles on Windows. If it does we know there's some interference with R, and if it doesn't we may have a sufficiently minimal example that it would make sense to file an issue with clang-sys. |
Agreed, I was thinking I need to get familiar with bindgen itself a bit deeper... |
|
@Ilia-Kosenkov There's a lot of good advice with tips for debugging this kind of problem here: |
|
@clauswilke, This is what happens between two breakpoints. A bunch of modules are loaded, starting with So, what goes wrong is |
|
It's starting to look like msys2 is shipping a broken 32-bit version of clang. Maybe it's so rarely used that nobody has noticed. Do you want to file a bug report? I assume it's either here: https://github.com/msys2/MSYS2-packages or here: https://github.com/msys2/MINGW-packages |
|
@clauswilke, |
|
@Ilia-Kosenkov Thanks for filing the issue. I just noticed on the msys2 website for the clang package that there's a link to bug reports, and it goes to the MINGW-packages repo: https://github.com/msys2/MINGW-packages/issues?q=is%3Aissue+is%3Aopen+clang Maybe would be good to report there also. And the website also lists a specific user who signed the package and who could be tagged in the bug report: https://github.com/elieux |
|
Hi @clauswilke, |
|
Done that: msys2/MINGW-packages#7442 Btw., I liked your installation instructions in the bug report you filed. Would you be interested in creating a PR to update the Windows installation instructions in the README, here: https://github.com/extendr/libR-sys/blob/master/README.md#windows-specific-instructions I would make two changes to what you posted in the issue:
|
|
If anybody with access to a Windows machine wants to try something else, maybe it's possible to use the binaries provided by llvm: https://releases.llvm.org/download.html They're not built with mingw, so this may or may not work. With the code in PR #27, it would be easy to distribute precomputed bindings with libR-sys, so we'd have to get this to run only once (for each R version). So even if the install/build process is super complex and tricky to pull off, that's fine because our endusers wouldn't have to jump through those hoops. |
|
If I am not mistaken, binaries lack llvm-config. One needs to build llvm from source, which I think I can attempt to do. |
|
I've posted this on discord, but this is the place that this should reside in: Given #include <stdio.h>
#include <clang-c/Index.h> // This is libclang.
int main() {
printf("Hello world\n");
printf("With clang header..\n");
}And using
As in: |
|
You can use the WinDbg process discussed above to see if libclang is actually loaded dynamically and whether it then loads the same downstream libraries. |
|
If anyone has access to Windows machine, please take this code sample that I prepared and try building both versions for Windows. UPD: This is the result of GitHub Actions, it seems to confirm the hypothesis. |
|
Thanks for the code sample, I confirmed it also fails on my Windows. |
|
So we're potentially looking at a problem with Rust itself, or how it builds build scripts. It's interesting that the exact same code runs fine inside the Rust library itself. Could you set up a repo that demonstrates that also, so we can point to the two side-by-side? Btw., |
|
Long story short, I messed something up last night and arrived to an incorrect conclusion -- it is not UPD: Here is GH Actions report to summarise the issue |
|
Honestly, I find that more plausible. Something is wrong with libclang on i686 and so you can't link it, ever. That makes sense. If you google clang mingw 32-bit you encounter old problems such as this one where people also ran into trouble: There are two obvious next steps to try:
|
|
@clauswilke, Building from source is another step, I think there still maybe some |
|
This is getting weirder and weirder with every step. If anyone is testing my |
|
Interesting! Can you reproduce this in the GH action? Run |
|
Did not try running it with |
|
I have removed this issue from the milestone for the next libR-sys release. It isn't immediately show-stopping, as I've now a set of manually fixed-up bindings that work for now. We should still try to get the i686 libclang issue resolved, though. |
|
It feels like we have enough to go and ask 'rust' people about this issue. Clearly it is neither 'msys'/'mingw' nor 'clang' (I called the latter from x86 C++ app with no problem). |
|
Agreed. We can file an issue with cargo: https://github.com/rust-lang/cargo Do you want to do this or do you prefer if I do so? |
|
@clauswilke, |
|
Issue filed with cargo: rust-lang/cargo#8990 |
|
Following suggestions from * because of also works. |
|
I think cross-compiling from any Windows toolchain, even |
|
With the answers we got from other teams & the successful deployment of our own GitHub CI, should this issue be closed? |
|
Yes, agreed. If new problems crop up we can open a new issue. |
It is important that we can build on 32-bit targets, I've tried to follow the instructions in the
README.md,but substituting with the 32-bit variants.
This doesn't work for some reason. And here's the latest error-message/hurdle:
I've searched for
clang.dllin the mingw folders, and there is nothing named that.It is the
libclang.dllthat is problem.Here's a few more diagnostic things that I see mentioned when trying to troubleshoot this:
The text was updated successfully, but these errors were encountered: