[Rd] R-4.2.3 build from source on Windows (w Rtools42) - lto1.exe error
Windows 11 PRO Version 10.0.22621 Build 22621 Processor: Intel(R) Core(TM) i7-1065G7 "Icelake-client" ``` svn info Path: . Working Copy Root Path: /d/R_DEV/R-4/R42/R-4-2-branch URL: https://svn.r-project.org/R/branches/R-4-2-branch Relative URL: ^/branches/R-4-2-branch Repository Root: https://svn.r-project.org/R Repository UUID: 00db46b3-68df-0310-9c12-caf00c1e9a41 Revision: 84417 Node Kind: directory Schedule: normal Last Changed Author: kalibera Last Changed Rev: 84249 Last Changed Date: 2023-04-13 07:12:24 + (Thu, 13 Apr 2023) ``` Only adaptation done in MkRules.local was adding: `EOPTS = -march=native` - that's why I included the cpu-type info above; running make all recommended fails at/with: ``` gcc -shared -s -static-libgcc -o utils.dll tmp.def init.o io.o size.o sock.o stubs.o utils.o hashtab.o windows/dataentry.o windows/dialogs.o windows/registry.o windows/util.o windows/widgets.o ../../../gnuwin32/dllversion.o -lRgraphapp -lversion -L/x86_64-w64-mingw32.static.posix/lib/x64 -llzma -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib/x64 -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib -L../../../../bin/x64 -lR lto1.exe: fatal error: bytecode stream in file 'windows/dataentry.o' generated with LTO version 9.3 instead of the expected 9.4 compilation terminated. lto-wrapper.exe: fatal error: C:\rtools42\x86_64-w64-mingw32.static.posix\bin\gcc.exe returned 1 exit status compilation terminated. C:\rtools42\x86_64-w64-mingw32.static.posix\bin/ld.exe: error: lto-wrapper failed collect2.exe: error: ld returned 1 exit status cp: cannot stat 'utils.dll': No such file or directory make[4]: *** [Makefile.win:36: shlib] Error 1 make[3]: *** [../../../share/make/basepkg.mk:145: mksrc-win2] Error 1 make[2]: *** [Makefile.win:24: all] Error 2 make[1]: *** [Makefile.win:34: R] Error 1 make: *** [Makefile:18: all] Error 2 ``` Any hints/ideas on how to fix this? I guess I could gcc -c -flto ... windows/dataentry.c -o windows/dataentry.o with the exact path of that fiile ... and it hopefully will fix that but I guess it would make sense to add a Revision to update that LTO version mismatch there, and I don't know yet if this is the only one? Greetings, W __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-4.2.3 build from source on Windows (w Rtools42) - lto1.exe error
Hi. Are you sure you have the most up-to-date version of the libraries? It should be version 5550. Tomas updates the entire toolchain semi-regularly. If you call “ cat /x86_64-w64-mingw32.static.posix/.version” and it’s not 5550, try updating the libraries as per https://cran.r-project.org/bin/windows/base/howto-R-devel.html. Hope that helps, Avi Sent from my iPhone > On May 10, 2023, at 9:07 PM, Gmail wrote: > > Windows 11 PRO Version 10.0.22621 Build 22621 > Processor: Intel(R) Core(TM) i7-1065G7 "Icelake-client" > ``` > svn info > Path: . > Working Copy Root Path: /d/R_DEV/R-4/R42/R-4-2-branch > URL: https://svn.r-project.org/R/branches/R-4-2-branch > Relative URL: ^/branches/R-4-2-branch > Repository Root: https://svn.r-project.org/R > Repository UUID: 00db46b3-68df-0310-9c12-caf00c1e9a41 > Revision: 84417 > Node Kind: directory > Schedule: normal > Last Changed Author: kalibera > Last Changed Rev: 84249 > Last Changed Date: 2023-04-13 07:12:24 + (Thu, 13 Apr 2023) > ``` > > Only adaptation done in MkRules.local was adding: `EOPTS = -march=native` - > that's why I included the cpu-type info above; > running make all recommended fails at/with: > ``` > gcc -shared -s -static-libgcc -o utils.dll tmp.def init.o io.o size.o sock.o > stubs.o utils.o hashtab.o windows/dataentry.o windows/dialogs.o > windows/registry.o windows/util.o windows/widgets.o > ../../../gnuwin32/dllversion.o -lRgraphapp -lversion > -L/x86_64-w64-mingw32.static.posix/lib/x64 -llzma > -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib/x64 > -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib -L../../../../bin/x64 -lR > > lto1.exe: fatal error: bytecode stream in file 'windows/dataentry.o' > generated with LTO version 9.3 instead of the expected 9.4 > compilation terminated. > > lto-wrapper.exe: fatal error: > C:\rtools42\x86_64-w64-mingw32.static.posix\bin\gcc.exe returned 1 exit status > compilation terminated. > C:\rtools42\x86_64-w64-mingw32.static.posix\bin/ld.exe: error: lto-wrapper > failed > collect2.exe: error: ld returned 1 exit status > cp: cannot stat 'utils.dll': No such file or directory > make[4]: *** [Makefile.win:36: shlib] Error 1 > make[3]: *** [../../../share/make/basepkg.mk:145: mksrc-win2] Error 1 > make[2]: *** [Makefile.win:24: all] Error 2 > make[1]: *** [Makefile.win:34: R] Error 1 > make: *** [Makefile:18: all] Error 2 > ``` > Any hints/ideas on how to fix this? I guess I could > gcc -c -flto ... windows/dataentry.c -o windows/dataentry.o > with the exact path of that fiile ... > and it hopefully will fix that but I guess it would make sense to add a > Revision to update that LTO version mismatch there, and I don't know yet if > this is the only one? > > Greetings, > W > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-4.2.3 build from source on Windows (w Rtools42) - lto1.exe error
Initial comments - R 4.2.3 is not current - -flto does not seem to be the default in src/gnuwin32/MkRules. - LTO versions in GCC are tied to the compiler version, and in recent GCC are the same as the compiler version. The recommended toolchain for R 4.2.x is Rtools42 which according to NEWS is based on GCC 10 not 9. - LTO mismatches in my experience are most often seen in incremental builds, so first do an ab initio build. (Not so long ago they were not detected during linking but gave segfaults.) Assuming it is important to use LTO, I would first build without LTO to isolate the issue. And be aware of the following in the NEWS for R 4.3.0: • The Rcomplex definition (in header R_ext/Complex.h) has been extended to prevent possible mis-compilation when interfacing with Fortran (PR#18430). AFAIR that "possible mis-compilation" is most likely using LTO. On 11/05/2023 02:07, Gmail wrote: Windows 11 PRO Version 10.0.22621 Build 22621 Processor: Intel(R) Core(TM) i7-1065G7 "Icelake-client" ``` svn info Path: . Working Copy Root Path: /d/R_DEV/R-4/R42/R-4-2-branch URL: https://svn.r-project.org/R/branches/R-4-2-branch Relative URL: ^/branches/R-4-2-branch Repository Root: https://svn.r-project.org/R Repository UUID: 00db46b3-68df-0310-9c12-caf00c1e9a41 Revision: 84417 Node Kind: directory Schedule: normal Last Changed Author: kalibera Last Changed Rev: 84249 Last Changed Date: 2023-04-13 07:12:24 + (Thu, 13 Apr 2023) ``` Only adaptation done in MkRules.local was adding: `EOPTS = -march=native` - that's why I included the cpu-type info above; running make all recommended fails at/with: ``` gcc -shared -s -static-libgcc -o utils.dll tmp.def init.o io.o size.o sock.o stubs.o utils.o hashtab.o windows/dataentry.o windows/dialogs.o windows/registry.o windows/util.o windows/widgets.o ../../../gnuwin32/dllversion.o -lRgraphapp -lversion -L/x86_64-w64-mingw32.static.posix/lib/x64 -llzma -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib/x64 -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib -L../../../../bin/x64 -lR lto1.exe: fatal error: bytecode stream in file 'windows/dataentry.o' generated with LTO version 9.3 instead of the expected 9.4 compilation terminated. lto-wrapper.exe: fatal error: C:\rtools42\x86_64-w64-mingw32.static.posix\bin\gcc.exe returned 1 exit status compilation terminated. C:\rtools42\x86_64-w64-mingw32.static.posix\bin/ld.exe: error: lto-wrapper failed collect2.exe: error: ld returned 1 exit status cp: cannot stat 'utils.dll': No such file or directory make[4]: *** [Makefile.win:36: shlib] Error 1 make[3]: *** [../../../share/make/basepkg.mk:145: mksrc-win2] Error 1 make[2]: *** [Makefile.win:24: all] Error 2 make[1]: *** [Makefile.win:34: R] Error 1 make: *** [Makefile:18: all] Error 2 ``` Any hints/ideas on how to fix this? I guess I could gcc -c -flto ... windows/dataentry.c -o windows/dataentry.o with the exact path of that fiile ... and it hopefully will fix that but I guess it would make sense to add a Revision to update that LTO version mismatch there, and I don't know yet if this is the only one? Greetings, W __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
