Skip to content
Prev 61628 / 63421 Next

R-4.2.3 build from source on Windows (w Rtools42) - lto1.exe error

Thanks to everybody for the reples.

tl;dr: it was a config problem with my environment being polluted by
other apps (also via $USERPROFILE/.bashrc).
R-4-2-branch builds with LTO "march=native" (Rtools42, also managed to
build with "mtune=native", which afaik is inherently included when
doing march, but still).

Details: I will try to aggregate answers to comments/hints here and
document a sequentially processed train of action here including
results as some form of documentation for current status and hickups
from my setup described in this email chain.

@Avraham, et al
Since I wasn't sure if and how maybe lib updates I had done before
starting to build had played a role I downloaded a fresh copy of the
Rtools42 installer from here
[https://cran.r-project.org/bin/windows/Rtools/rtools42/files/]
current version via `cat /x86_64-w6cat
/x86_64-w64-mingw32.static.posix/.version` gave "5355"
Did some more "tests":
`cd R-4-2-branch/src/gnuwin32`
Ran build with"mtune=native" gave same error
Ran `make clean`
Then using no EOPTS options in MkRules.local with version "5355" -> same error
Ran `make clean`
---
Then ran an update via `pacman -Syuu`
Which updates the following:
Packages (55) brotli-1.0.9-8  bsdtar-3.6.2-3
ca-certificates-20230311-1  coreutils-8.32-5  curl-8.0.1-1
              dash-0.5.12-1  db-5.3.28-4  diffutils-3.9-1  file-5.44-5
 gawk-5.2.1-2  gcc-libs-11.3.0-3
              gnupg-2.2.41-1  grep-1~3.0-6  heimdal-libs-7.8.0-3
info-7.0.3-1  less-633-1  libcrypt-2.1-4
              libcurl-8.0.1-1  libdb-5.3.28-4  libedit-20221030_3.1-1
libexpat-2.5.0-1  libffi-3.4.4-1
              libgcrypt-1.10.2-1  libgnutls-3.8.0-1
libgpg-error-1.47-1  libidn2-2.3.4-2  libksba-1.6.3-1
              liblzma-5.4.3-1  libnghttp2-1.52.0-1  libopenssl-3.1.0-2
 libpcre-8.45-3  libpsl-0.21.2-1
              libreadline-8.2.001-3  libsqlite-3.41.2-3
libssh2-1.10.0-3  libunistring-1.1-2  libxml2-2.10.4-1
              libzstd-1.5.5-1  make-4.4.1-1  mpfr-4.2.0.p4-1
msys2-keyring-1~20230316-1  ncurses-6.4-1
              openssl-3.1.0-2  patch-2.7.6-2  perl-5.36.0-1
pinentry-1.2.1-1  rebase-4.5.0-4  rsync-3.2.7-2
              sed-4.9-1  tcl-8.6.12-3  texinfo-7.0.3-1
texinfo-tex-7.0.3-1  xz-5.4.3-1  zlib-1.2.13-1  zstd-1.5.5-1

But what confuses me a bit is that after that ` cat /x86_64-w6cat
/x86_64-w64-mingw32.static.posix/.version` still only gives me "5355"?
As will be shown later (below) this was not a breaking issue.

Important change to my environment for the next attempt!
I decided to check my ENV Variables (one more time) after thoroughly
reading Tomas comment "maybe there is some config problem on the
system" as well as Prof. Ripley's "first build without LTO to
isolate the issue" and noticed that the old Rtools40/.../bin folder
was also in my WINdows %PATH% ENV Variable.
So I started a cleanup initiative from there.
Also noticed that the .bashrc file in my %USERPROFILE% folder
cluttered up my PATH especially there were `/mingw-64/bin` and
`.../Library/bin` and similar entries from a miniconda3 installation
amongst others ghosting around in there!
Despite gcc --version or make commands not returning anything other
than `command not found` I cleaned that .bashrc file up quite a bit.
After cleanup I restarted MSYS2 Bash and ran  `make distcelan` in the
/src/gnuwin32 folder one more time then added miktex,
/x86_64-w64-mingw32.static.posix/bin, tar, etc to $PATH or environment
again.
`echo $PATH` now (ater the extension of PATH var as dscibed in
https://cran.r-project.org/bin/windows/base/howto-R-4.2.html)
finally looked like this
```
/c/Users/gwd/AppData/Local/Programs/MiKTeX/miktex/bin/x64:/x86_64-w64-mingw32.static.posix/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/progra~1/git/cmd:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
```
with all other Library, bin or similar (mainly miniconda3) folders gone now.
and
`which make gcc pdflatex tar` looks like this now (not much different
to before, but ...)
```
make is /usr/bin/make
make is /bin/make
gcc is /x86_64-w64-mingw32.static.posix/bin/gcc
pdflatex is /c/Users/gwd/AppData/Local/Programs/MiKTeX/miktex/bin/x64/pdflatex
tar is /usr/bin/tar
tar is /bin/tar
tar is /c/Windows/System32/tar
```
seems to look "better"!

Then I started to build again ... which took me some time - that's why
there's this delay in my answer here. ..
First w/o any EOPTS -> succeeded!
Then `make distclean`
And then with march=native` [as well as mtune] -> succeeded!

I will give the R-devel version with Rtools43 a shot as well (next)
week - if you don't hear back from me -> you can assume that (also)
worked correctly with LTO.

So ... as is so often the case: "the problem was sitting in front of the PC".
Thanks for the assistance and informative hints and sorry for
bothering you all basically b/c of my (.bashrc) setup conundrum!

Greetings,
Walter
On Thu, 11 May 2023 at 09:06, Tomas Kalibera <tomas.kalibera at gmail.com> wrote: