On Windows, default rust needs to be gnu, not msvc #19

clauswilke · 2021-01-11T22:54:06Z

Apparently, under some circumstances, the default Rust on Windows needs to be gnu, not msvc.

Is there any way to remove this requirement?

cc @Ilia-Kosenkov @CGMossa @yutannihilation

clauswilke · 2021-01-11T22:55:31Z

This is particularly frustrating since building an R package with extendr on Windows requires msvc to be the default toolchain. I would prefer to be able to tell people to always make msvc the default.

CGMossa · 2021-01-11T23:06:06Z

I can offer this workaround, that I think is fairly okay to use..

rustup run stable-gnu cargo build

Even if the default is nightly-msvc, it would run this under that toolchain and host.

Although, I'm not sure rustup is on linux/mac.

Loosely, the build commands would then be like

#...
  status <- system2(
    command = "rustup",
    args = c(
      "run",
      "stable-gnu",
      "cargo",
      "build",
...

yutannihilation · 2021-01-11T23:10:00Z

@CGMossa
Could you share the error message you got when you run it with msvc default? I'm curious about the cause, though I'm not sure if it's what we can fix or not.

CGMossa · 2021-01-11T23:12:50Z

I did share it, see the link that Claus posted, or here:

error[E0463]: can't find crate for `std`                       
  |
  = note: the `x86_64-pc-windows-gnu` target may not be installed

While I'm at it: Using cargo +stable-gnu build does not work, as I think you can only write few things in cargo +<here>.

yutannihilation · 2021-01-11T23:15:13Z

Oh, I see. Sorry. I thought you got some different error after you added the target. Hmm...

clauswilke · 2021-01-11T23:15:14Z

Before implementing some workaround I'd like to understand what the issue is. We're just calling cargo build on a regular Rust crate, I don't understand why this would be a problem. We're doing this exact same thing when building R packages or extendr standalone binaries and we don't have errors there.

CGMossa · 2021-01-11T23:46:35Z

Ok.

I added rustup target add x86_64-pc-windows-gnu and somehow that added it to stable-msvc. This made
a new error appear:

error: linker `x86_64-w64-mingw32-gcc` not found
  |
  = note: The system cannot find the file specified. (os error 2)

Then I added gcc that comes from rtools onto the path; Via

PS C:\Users\angus> $env:Path += ";C:\rtools40\usr\bin\;C:\rtools40\mingw64\bin\";

And then I get another error:

[omitted]
  = note: C:/rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgcc_eh
          collect2.exe: error: ld returned 1 exit status

And now I think this is just not possible to get past.

> Sys.which("ld")
                                  ld 
"C:\\rtools40\\mingw64\\bin\\ld.exe"

That's it from me; I don't know what else to do about this.

yutannihilation · 2021-01-12T00:50:04Z

Thanks. So, maybe we came back to this issue...?

rust-lang/cargo#8990 (comment)

(Sorry, I don't follow the discussion around this topic during the last year-end... It needs some time for me to catch up.)

clauswilke · 2021-01-12T01:02:33Z

cannot find -lgcc_eh is normally the problem when you're not making msvc the default toolchain. Weird. Maybe some problem with paths that get set when R is running. It should not be using the rtools linker but instead the msvc one, I believe.

clauswilke · 2021-01-12T01:17:27Z

In the extendr github action scripts, we're explicitly adding C:\msys64\mingw64\bin to the path:
https://github.com/extendr/extendr/blob/f714309fc6806f953cf82a6a30b0863a5d4eff1d/.github/workflows/test.yml#L231

We may need something similar here. You can set environment variables in .Renviron: https://rstats.wtf/r-startup.html

clauswilke · 2021-01-12T01:38:24Z

Ok, I think I'm starting to see how this all fits together. The problem is always the linker. For standalone Rust binaries, we need to use the msvc tool chain to get things linking correctly. For dynamic libraries (the use case here), we would also need the msvc tool chain. But when we're building an R package with extendr (as here: https://github.com/extendr/helloextendr/blob/main/src/Makevars.win) we're building a static library that we then let R link. This works fine with the msvc tool chain also, but the actual linking happens with the Rtools tool chain controlled by R.

What is breaking here is trying to build a dynamic library directly using a mixed tool chain. It makes sense that this wouldn't work. We need to make sure that the Rtools ld.exe doesn't get picked when linking the final dynamic library.

Alternatively, we could mimic the approach of building an R package, that is, use cargo only to build a static library and then use R to build a dynamic library. That's probably possible but a little more work on our end. (And I've never done this, so I don't know off the top of my head how to do it. But there's this: https://www.rdocumentation.org/packages/utils/versions/3.6.2/topics/SHLIB)

Ilia-Kosenkov · 2021-01-12T06:22:53Z

I am sorry I fail to understand what actually triggered the linker error? Was it some simple test code?
I have seen a lot of different error combinations on Windows, but what I learned is that everything works if we take msvc toolchain and provide the correct target(s).

Could you please try setting up default toolchain

rustup default stable-x86_64-pc-windows-msvc

and then adding two targets

rustup target add x86_64-pc-windows-gnu --toolchain stable-x86_64-pc-windows-msvc
rustup target add i686-pc-windows-gnu --toolchain stable-x86_64-pc-windows-msvc

If PATH is contaminated by Rtools binaries, all sorts of weird things happen. Remove all references to Rtools subfolder, but ensure that you have a separate env variable RTOOLS40_HOME, which is set by default by the installer.

Then it should work. And if it does not, please provide a minimal reproducible example and detailed output.

yutannihilation · 2021-01-12T06:44:33Z

Hmm..., I think I followed your instruction, but it failed.

> rust_function("fn add(a:f64, b:f64) -> f64 { a + b }")
build directory: C:\Users\HIROAK~1\AppData\Local\Temp\RtmpKOZj3U\file198858e28f7

    Updating crates.io index
   Compiling rextendr3 v0.0.1 (C:\Users\HIROAK~1\AppData\Local\Temp\RtmpKOZj3U\file198858e28f7)
error: linker `x86_64-w64-mingw32-gcc` not found
  |
  = note: 謖・ｮ壹＆繧後◆繝輔ぃ繧､繝ｫ縺瑚ｦ九▽縺九ｊ縺ｾ縺帙ｓ縲・(os error 2)

error: aborting due to previous error

error: could not compile `rextendr3`

To learn more, run the command again with --verbose.
Error: Rust code could not be compiled successfully. Aborting.

> p <- Sys.getenv("PATH")
> p <- strsplit(p, ";", fixed = TRUE)[[1]]
> idx <- grepl("rtools", p, ignore.case = TRUE)
> p[idx]
character(0)

> Sys.getenv("RTOOLS40_HOME")
[1] "C:\\rtools40"

> system("rustup toolchain list")
stable-i686-pc-windows-gnu
stable-x86_64-pc-windows-gnu
stable-x86_64-pc-windows-msvc (default)
[1] 0

Ilia-Kosenkov · 2021-01-12T06:48:03Z

@yutannihilation,
I see. The missing linker comes from MSYS2, which is added to my path. If you have it installed, could you temporarily add msys2\mingw64\bin to your PATH to see if it resolves the issue?

yutannihilation · 2021-01-12T07:21:39Z

Thanks, confirmed it works (In my environment, the path seems msys64\mingw64\bin). Then, do you mean we need to require Windows users to install MSYS2 to use rextendr?

> library(rextendr)
> p <- Sys.getenv("PATH")
> Sys.setenv(PATH = paste0("C:\\msys64\\mingw64\\bin", ";", p))
> rust_function("fn add(a:f64, b:f64) -> f64 { a + b }")
build directory: C:\Users\HIROAK~1\AppData\Local\Temp\RtmpoVe16y\file307874ec3870

    Updating git repository `https://github.com/extendr/extendr`
    Updating crates.io index
   Compiling winapi-build v0.1.1
   Compiling winapi v0.3.9
   Compiling winapi v0.2.8
   Compiling proc-macro2 v1.0.24
   Compiling unicode-xid v0.2.1
   Compiling syn v1.0.58
   Compiling extendr-engine v0.1.11 (https://github.com/extendr/extendr#f714309f)
   Compiling lazy_static v1.4.0
   Compiling kernel32-sys v0.2.2
   Compiling quote v1.0.8
   Compiling extendr-macros v0.1.11 (https://github.com/extendr/extendr#f714309f)
   Compiling libR-sys v0.2.1
   Compiling extendr-api v0.1.11 (https://github.com/extendr/extendr#f714309f)
   Compiling rextendr1 v0.0.1 (C:\Users\HIROAK~1\AppData\Local\Temp\RtmpoVe16y\file307874ec3870)
    Finished dev [unoptimized + debuginfo] target(s) in 52.52s
> add(2.5, 4.7)
[1] 7.2

Ilia-Kosenkov · 2021-01-12T07:31:36Z

@yutannihilation,
I reproduced your error by removing msys2 from my path.
My observation, we need either:

stable-msvc + MSYS2
stable-gnu

In both cases we need to provide --target as I did in #16, otherwise x86 R will not be able to load the library (which is rare, but important).

So, my suggestion is to allow for toolchain optional parameter to override what toolchain is used.
This can be passed to various rust_* functions. The default NULL value corresponds to the default toolchain (i.e. no extra parameter). I believe this will help people with complex environment setups to control how the library is built.
It can be also tested in CI.

clauswilke · 2021-01-12T07:51:33Z

@Ilia-Kosenkov Feel free to implement the toolchain parameter you suggest.

Also, it would be great if you could add brief instructions on how to get things going on Windows here:
https://github.com/extendr/rextendr/blob/main/vignettes/setting_up_rust.Rmd

Ilia-Kosenkov · 2021-01-12T07:52:27Z

@clauswilke,
About to open PR, finishing with the docs.

yutannihilation · 2021-01-12T10:27:14Z

So, my suggestion is to allow for toolchain optional parameter to override what toolchain is used.

Thanks! I now understand what you meant. Confirmed #20 works on my environment.

Without `toolchain`

> rust_function("fn add(a:f64, b:f64) -> f64 { a + b }")
build directory: C:\Users\HIROAK~1\AppData\Local\Temp\RtmpWIVDm3\file24205dfb5677

    Updating git repository `https://github.com/extendr/extendr`
    Updating crates.io index
   Compiling winapi-build v0.1.1
   Compiling winapi v0.3.9
   Compiling winapi v0.2.8
   Compiling proc-macro2 v1.0.24
   Compiling unicode-xid v0.2.1
   Compiling syn v1.0.58
   Compiling extendr-engine v0.1.11 (https://github.com/extendr/extendr#f714309f)
   Compiling lazy_static v1.4.0
   Compiling kernel32-sys v0.2.2
   Compiling quote v1.0.8
   Compiling extendr-macros v0.1.11 (https://github.com/extendr/extendr#f714309f)
   Compiling libR-sys v0.2.1
   Compiling extendr-api v0.1.11 (https://github.com/extendr/extendr#f714309f)
   Compiling rextendr1 v0.0.1 (C:\Users\HIROAK~1\AppData\Local\Temp\RtmpWIVDm3\file24205dfb5677)
error: linker `x86_64-w64-mingw32-gcc` not found
  |
  = note: 謖・ｮ壹＆繧後◆繝輔ぃ繧､繝ｫ縺瑚ｦ九▽縺九ｊ縺ｾ縺帙ｓ縲・(os error 2)

error: aborting due to previous error

error: could not compile `rextendr1`

To learn more, run the command again with --verbose.
Error: Rust code could not be compiled successfully. Aborting.

With `toolchain` specified

> rust_function("fn add(a:f64, b:f64) -> f64 { a + b }", toolchain = "stable-gnu")
build directory: C:\Users\HIROAK~1\AppData\Local\Temp\RtmpWIVDm3\file24205dfb5677

    Updating crates.io index
   Compiling winapi-x86_64-pc-windows-gnu v0.4.0
   Compiling winapi-build v0.1.1
   Compiling winapi v0.3.9
   Compiling winapi v0.2.8
   Compiling proc-macro2 v1.0.24
   Compiling unicode-xid v0.2.1
   Compiling syn v1.0.58
   Compiling extendr-engine v0.1.11 (https://github.com/extendr/extendr#f714309f)
   Compiling lazy_static v1.4.0
   Compiling kernel32-sys v0.2.2
   Compiling quote v1.0.8
   Compiling extendr-macros v0.1.11 (https://github.com/extendr/extendr#f714309f)
   Compiling libR-sys v0.2.1
   Compiling extendr-api v0.1.11 (https://github.com/extendr/extendr#f714309f)
   Compiling rextendr2 v0.0.1 (C:\Users\HIROAK~1\AppData\Local\Temp\RtmpWIVDm3\file24205dfb5677)
    Finished dev [unoptimized + debuginfo] target(s) in 57.77s

Ilia-Kosenkov · 2021-01-13T10:23:01Z

I am reopnening this issue because I am unable to setup simple Windows CI using stable-gnu toolchain.
The build fails with linker complaining about lgcc_eh, similar to what was reported here earlier.
I will try to investigate this further.

Ilia-Kosenkov · 2021-01-13T11:39:57Z

The root cause is that setup-r action incorrectly updates PATH when installing rtools.
By default, PATH should only contain C:\rtools40\usr\bin to get access to make.
setup-r adds C:\rtools40\mingw64\bin, similar to what @CGMossa did in #19 (comment). As a result, an incorrect linker is pulled from the PATH, which results in cannot find -lgcc_eh error when building rust library.
I have opened an issue r-lib/actions#228 to see if we can get help with this, as I believe setup-r is misconfigured.
The current solution is to rewrite paths, throwing away the ones matching rtools and mingw, like the following:

$temp = $env:Path -split [System.IO.Path]::PathSeparator | ? {$_ -notlike "*rtools*mingw*"} | join-string -Separator $([System.IO.Path]::PathSeparator)
echo $temp | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8

yutannihilation · 2021-01-13T13:53:43Z

How about overriding PATH variable on rextendr's side? Probably we only need Rtools' toolchain and cargo. Here's a quick example: yutannihilation@1100936

I mean, I'm wondering if it's a common case not only for setup-r action but also for ordinary Windows users to misconfigure PATH with another MinGW toolsets, which might be bundled with various tools.

Ilia-Kosenkov · 2021-01-13T15:16:43Z

@yutannihilation,
The PATH problem is unique to the Github Actions we use.
There is no need to fix it in code as regular users with correctly installed rtools will not experience it.

In fact, my issues has already been addressed and closed (r-lib/actions@1efbdeb), I will try this modified CI step in my script.

yutannihilation · 2021-01-13T16:36:28Z

regular users with correctly installed rtools will not experience it.

OK, sounds fair. I probably thought of those who "incorrectly" installed rtools, but they need to do it right to compile packages anyway.

my issues has already been addressed and closed

So quick!

Ilia-Kosenkov · 2021-01-13T16:44:26Z

@yutannihilation,
Unfortunately it appears to be bugged because the author of the fix put string value in the if condition. So basically trying to check if ("true") or if ("false") , which appears to be always true.
I am trying to fix it in my fork and reopen that issue.

Ilia-Kosenkov · 2021-01-13T18:48:48Z

People @ r-lib fixed rtools path issue in r-lib/actions@30e0be0, which I have tested in my CI.

Notice however that to get latest updates the correct action is r-lib/actions/setup-r@master, not r-lib/actions/setup-r@v1.

Ilia-Kosenkov · 2021-01-14T22:09:28Z

@clauswilke in discussion of #26 made a good point that we should have consistent tools throughout *extendr projects.
So far, because of problems with rust gnu toolchain, we use everywhere stable-msvc and rely on MSYS2.
This is acually a good and universal setup that allows building for both architectures, and it also supports binding generation of libR-sys.

With this in mind, rextendr will rely on default toolchain (which is expected to be *-msvc).
A user can override this behavior by specifying toolchain.
As @yutannihilation suggested, it will be up to the user to provide correct toolchain for each architecture.

Right now CI uses stable-msvc

rextendr/.github/workflows/R-CMD-check.yaml

Lines 19 to 26 in 718812d

    
           strategy: 
        
             fail-fast: false 
        
             matrix: 
        
               config: 
        
                 - {os: windows-latest, r: 'release', rust-version: 'stable-msvc'} 
        
                 - {os: macOS-latest, r: 'release', rust-version: 'stable'} 
        
                 - {os: ubuntu-20.04, r: 'release', rust-version: 'stable', rspm: "https://packagemanager.rstudio.com/cran/__linux__/focal/latest"} 
        
                 - {os: ubuntu-20.04, r: 'devel', rust-version: 'stable', rspm: "https://packagemanager.rstudio.com/cran/__linux__/focal/latest"}

And setts up MSYS2 paths

rextendr/.github/workflows/R-CMD-check.yaml

Lines 67 to 74 in 718812d

    
                 - name: Configure Windows 
        
                   if: startsWith(runner.os, 'Windows') 
        
                   run: | 
        
                     rustup target add x86_64-pc-windows-gnu 
        
                     rustup target add i686-pc-windows-gnu 
        
                     echo "C:\msys64\mingw64\bin" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append  
        
                     echo "C:\msys64\mingw32\bin" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append 
        
                   shell: pwsh

Which allows rextendr to pass rcmdcheck with --force-multiarch.

yutannihilation · 2021-01-16T05:46:43Z

@Ilia-Kosenkov
Thanks for investigation and wrapping up! At first, I slightly preferred gnu toolchains as it seemed a bit heavy to install MSYS2, but I now agree with you on this.

This is acually a good and universal setup that allows building for both architectures, and it also supports binding generation of libR-sys.

Probably we should require installing MSYS2 at the moment in case we ask them to try compilation w/ bindgen (and I expect the ordinary Windows users who just install the packages can use pre-compiled binaries c.f. extendr/extendr#51).

@clauswilke @CGMossa
IIUC, now we can simply

tell people to always make msvc the default.

Can we close this issue? Are there any points on this topic that we still need to discuss?

clauswilke · 2021-01-16T05:59:27Z

Sounds good. I think the issue can be closed. Are the installation instructions for Windows here correct or not?

yutannihilation · 2021-01-16T06:13:57Z

I think the instructions are mostly correct. One thing, users need to define MSYS_ROOT by themselves (c.f. https://github.com/extendr/libR-sys/#windows-specific-instructions, this is because MSYS2 can be installed by various ways thus the root varies).

clauswilke · 2021-01-16T08:12:52Z

Thanks. For simplicity, I just removed MSYS_ROOT entirely from the instructions. I don't think it's needed for rextendr. We're not using it in the GH Action scripts.

yutannihilation · 2021-01-16T11:55:00Z

Looks good, but I guess you probably meant msys2 instead of msys32...?

#27

clauswilke · 2021-01-16T17:26:38Z

I did mean msys32, but maybe msys64 is better.

The screenshot on the msys2 page uses msys32: https://www.msys2.org/#installation

But these days, we normally use 64-bit systems, which would go into msys64:
https://www.msys2.org/wiki/MSYS2-installation/

clauswilke · 2021-01-16T21:42:34Z

There's one thing I still don't understand: If we don't compile libR-sys with bindgen, why can't we use the toolchain that comes with Rtools even when using stable-msvc, if in the end we're using mingw linkers anyway? Is this a version incompatibility, or would we have to install other packages through Rtools?

Ilia-Kosenkov · 2021-01-16T22:31:59Z

@clauswilke,
There is a mismatch in gcc versions, at least. Rtools ships 8.3.0, msys2 has 10.2.0.
Your build will fail with linker error of missing gcc_eh library, which is not present in 8.3.0.
I was actually experimenting with this today.
Essentially, rtools is modified msys2, so a user needs two nearly identical subsystems installed simultaneously.
We cannot install newer gcc onto rtools because packages rely on 8.3.0.

Now I am not sure from where this gcc_eh library requirement comes from.
If we can find out, we can probably solve this problem with rtools only.

clauswilke · 2021-01-16T23:14:01Z

Is gcc_eh not present in gcc 8.3 or not present in Rtools? gcc 8.3 is only two years old, it's not that unreasonable to ship it in my opinion. gcc_eh is definitely older. Maybe it's a problem with how Rtools sets up their compiler? I know they're setting up everything to link statically, maybe that's what's causing the issue. (Though gcc_eh is needed for static builds, so that's confusing to me.)

Ilia-Kosenkov · 2021-01-16T23:24:38Z

@clauswilke,
I cannot say. msys2's package manager does not seem to support package versioning (or, rather, repositories have only current version of a package), so I tried building gcc 8.3.0 using PKGBUILD script from mingw repository, but it unfortunately errored while building gcc from source, and I am not sure why.

I think we should somehow install older version of mingw64 toolchain, or just older gcc. If it has gcc_eh, then it is rtools. If it does not, then it is older version of gcc or some rust configuration (perhaps rust requires newer gcc).

gcc_eh is passed as -lgcc_eh to rustc, so I doubt we have any power over it.

clauswilke · 2021-01-16T23:38:51Z

Here is the explanation, from this old, random bug report:

Note that if enabled_shared is set to yes, then libgcc-eh is built; otherwise, it is added to libgcc. And this confirms what I am seeing, which is that gcc built with --disable-shared does not produce a libgcc_eh.a (totally weird that if shared is enabled, libgcc_eh.a, which is not a shared library, does get built).

Rtools builds with --disabled-shared:
https://github.com/r-windows/rtools-packages/blob/df6b4363b0422db30abf7dd78378022666a24ab4/mingw-w64-gcc/PKGBUILD#L167

msys2 builds with --enable-shared:
https://github.com/msys2/MINGW-packages/blob/950bcf391e5b247ebc7f2b2f5f5d10a03c3fdd63/mingw-w64-gcc/PKGBUILD#L223

This is fundamentally a gcc bug, and in particular when cross-compiling. See e.g. this old message from some development mailing list:
https://sourceware.org/legacy-ml/libc-alpha/2003-09/msg00100.html

Rtools could fix it by building with --enable-shared, but I guess one of their main points is that they don't want to allow shared builds.

Ilia-Kosenkov · 2021-01-17T10:53:32Z

@clauswilke,
I tried building mingw-w64-gcc from rtools-packages after replacing --disabled-shared with --enabled-shared, but ultimately failed with the strangest error:

.../PKGBUILD: line 168: --enable-shared: command not found

It looks like it was removed/disabled on purpose.

Ilia-Kosenkov · 2021-01-17T11:20:48Z

@clauswilke,
OK, the weirdest thing happened.
I applied the single most straightforward solution to the problem: copied gcc-10.2.0 libgcc_eh.a into rtools gcc-8.3.0 folder, and it worked. Not sure how reliable it is, but I can run libR-sys tests (no bindgen), extendr tests (but not the bindgen ones), and it seems that rextendr works as well.
Perhaps if we can get libgcc_eh from gcc-8.3.0, we can "patch" rtools (or ship this library with our packages, as long as it is found on PATH it should be ok).

Ilia-Kosenkov · 2021-01-17T12:09:22Z

Another observation in rtools, ming32 version of gcc contains libgcc and libgcc_eh, both files are of exactly same (and large size).
I believe what happens is that for mingw 32 the include issue was solved by duplicating libgcc as libgcc_eh, but this procedure was not carried out for mingw64.

I think this is possible because from what @clauswilke wrote, gcc compiles everything into libgcc and libgcc_eh is not needed, so simple copying of the same file solves the problem by pleasing the linker.

I think we should ask rtools people to implement this bypass for mingw64 as well.

Here is proof that mingw32 files are identical:

("C:\rtools40\mingw32\lib\gcc\i686-w64-mingw32\8.3.0\libgcc.a", "C:\rtools40\mingw32\lib\gcc\i686-w64-mingw32\8.3.0\libgcc_eh.a") 
| Get-FileHash

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          621AEF2A5AD649F24D17081657F611F9DFB20E2E26B74B30F7D5756A00DD9217       C:\rtools40\mingw32\lib\gcc\i686-w64-mingw32\8.3.0\libgcc.a
SHA256          621AEF2A5AD649F24D17081657F611F9DFB20E2E26B74B30F7D5756A00DD9217       C:\rtools40\mingw32\lib\gcc\i686-w64-mingw32\8.3.0\libgcc_eh.a

Ilia-Kosenkov · 2021-01-17T13:39:28Z

And here is the commit that introduced that hack, apparently
r-windows/rtools-packages@7d084d6

https://github.com/r-windows/rtools-packages/blob/df6b4363b0422db30abf7dd78378022666a24ab4/mingw-w64-gcc/PKGBUILD#L305-L309

The comment says this hack is for rustc, so I guess this is what we want.

clauswilke · 2021-01-17T17:12:32Z

This is a great find! Could you open an issue about this with rtools-packages, and maybe also a PR? (I would always do an issue first if you're not a frequent contributor to a project, even if the PR is straightforward.)

Ilia-Kosenkov · 2021-01-18T10:49:24Z

I can confirm that after implementing this fix for mingw64

creating a new gcc package using makepkg-mingw --syncdeps,
installing it onto a fresh copy of rtools using pacman -U mingw-w64-x86_64-gcc-8.3.0-9500-any.pkg.tar.xz,
the issue with x86_64 build using stable-msvc and mingw64 from rtools is resolved.

EDIT01: Note that building package from source took more than an hour on a decent desktop.

clauswilke · 2021-06-08T00:21:35Z

Can we close this issue?

Ilia-Kosenkov · 2021-06-08T07:14:12Z

Can we close this issue?

Yes, we decided to go with msvc and cross-compile using Rtools.

Ilia-Kosenkov mentioned this issue Jan 12, 2021

Adding 'toolchain' parameter to control rust builds #20

Merged

clauswilke closed this as completed in #20 Jan 12, 2021

Ilia-Kosenkov reopened this Jan 13, 2021

Ilia-Kosenkov closed this as completed Jan 13, 2021

Ilia-Kosenkov mentioned this issue Jan 14, 2021

Default windows toolchain set to gnu #26

Closed

Ilia-Kosenkov mentioned this issue Jan 16, 2021

Update README, specifically Windows section extendr/libR-sys#31

Closed

This was referenced Jan 17, 2021

Using rtools to test precomputed bindings on Windows extendr/libR-sys#51

Merged

[Windows] Is it possible to include Rust toolchain in Rtools? extendr/libR-sys#21

Closed

Ilia-Kosenkov mentioned this issue Jan 17, 2021

Implement libgcc_eh "hack" for mingw64 r-windows/rtools-packages#185

Closed

Ilia-Kosenkov mentioned this issue Mar 22, 2021

msys2 is no longer needed on Windows? #91

Closed

clauswilke closed this as completed Jun 8, 2021

markusgumbel mentioned this issue Dec 27, 2021

rextendr::document(): linker fails with "undefined reference to `BCryptGenRandom'" #165

Closed

yutannihilation mentioned this issue Feb 15, 2022

Use Rtools42, stop cross-compiling extendr/extendr#376

Merged

suzuki-shunsuke mentioned this issue Jun 13, 2022

Support Windows aquaproj/aqua#850

Closed

On Windows, default rust needs to be gnu, not msvc #19

On Windows, default rust needs to be gnu, not msvc #19

Comments

clauswilke commented Jan 11, 2021

clauswilke commented Jan 11, 2021 • edited Loading

CGMossa commented Jan 11, 2021

yutannihilation commented Jan 11, 2021

CGMossa commented Jan 11, 2021

yutannihilation commented Jan 11, 2021

clauswilke commented Jan 11, 2021

CGMossa commented Jan 11, 2021

yutannihilation commented Jan 12, 2021

clauswilke commented Jan 12, 2021

clauswilke commented Jan 12, 2021

clauswilke commented Jan 12, 2021

Ilia-Kosenkov commented Jan 12, 2021

yutannihilation commented Jan 12, 2021

Ilia-Kosenkov commented Jan 12, 2021

yutannihilation commented Jan 12, 2021

Ilia-Kosenkov commented Jan 12, 2021

clauswilke commented Jan 12, 2021

Ilia-Kosenkov commented Jan 12, 2021

yutannihilation commented Jan 12, 2021

Without toolchain

With toolchain specified

Ilia-Kosenkov commented Jan 13, 2021

Ilia-Kosenkov commented Jan 13, 2021

yutannihilation commented Jan 13, 2021 • edited Loading

Ilia-Kosenkov commented Jan 13, 2021

yutannihilation commented Jan 13, 2021

Ilia-Kosenkov commented Jan 13, 2021

Ilia-Kosenkov commented Jan 13, 2021

Ilia-Kosenkov commented Jan 14, 2021

yutannihilation commented Jan 16, 2021

clauswilke commented Jan 16, 2021

yutannihilation commented Jan 16, 2021

clauswilke commented Jan 16, 2021

yutannihilation commented Jan 16, 2021

clauswilke commented Jan 16, 2021

clauswilke commented Jan 16, 2021

Ilia-Kosenkov commented Jan 16, 2021

clauswilke commented Jan 16, 2021

Ilia-Kosenkov commented Jan 16, 2021

clauswilke commented Jan 16, 2021

Ilia-Kosenkov commented Jan 17, 2021 • edited Loading

Ilia-Kosenkov commented Jan 17, 2021

Ilia-Kosenkov commented Jan 17, 2021

Ilia-Kosenkov commented Jan 17, 2021

clauswilke commented Jan 17, 2021

Ilia-Kosenkov commented Jan 18, 2021 • edited Loading

clauswilke commented Jun 8, 2021

Ilia-Kosenkov commented Jun 8, 2021

clauswilke commented Jan 11, 2021 •

edited

Loading

Without `toolchain`

With `toolchain` specified

yutannihilation commented Jan 13, 2021 •

edited

Loading

Ilia-Kosenkov commented Jan 17, 2021 •

edited

Loading

Ilia-Kosenkov commented Jan 18, 2021 •

edited

Loading