Rtools fails compiling shared objects (R software - CRAN)

[aldoclemente]

CRAN is asking to handles some NOTEs.
In particular, they are asking to avoid specifying the c++ standard in the Makevars file according to the "CRAN incoming feseability" . Hence, I should drop the CXX_STD= CXX11 in the Makevars.

A priori, it should not be a problem for the C++ backward compatibilty.

I made the opportune changes and checked the package on linux and as one might expect, the new version of the package passes the usual checks through R CMD check MyPackage.tar.gz.
Relying on rhub functionalities, the new version of the package passes the checks also on macOs.

For what concerns windows, I get an error during the building of the shared object, in the last step of the compilation process.
In particular, dropping CXX_STD= CXX11, using R 4.3.0 (R under development) and relying on rtools43, the last step of the compilation reads as follows:

gcc -shared -s -static-libgcc -o fdaPDE.dll tmp.def  ObjectFile1.o .... ObjectFileN.o -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib/x64 -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib -LC:/PROGRA~1/R/R-devel/bin/x64 -lR
C:\rtools43\x86_64-w64-mingw32.static.posix\bin/ld.exe: ObjectFile1.o:ObjectFile.cpp:(.text+0x33f4): undefined reference to `operator new(unsigned long long)'
C:\rtools43\x86_64-w64-mingw32.static.posix\bin/ld.exe: ObjectFile1.o:ObjectFile1.cpp:(.text+0x340b): undefined reference to `std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)'
C:\rtools43\x86_64-w64-mingw32.static.posix\bin/ld.exe: ObjectFile1.o:ObjectFile1.cpp:(.text+0x3432): undefined reference to `std::_Rb_tree_decrement(std::_Rb_tree_node_base*)'
C:\rtools43\x86_64-w64-mingw32.static.posix\bin/ld.exe: 
.....
and so on
.....

It seems that gcc does not link properly the standard library. Is Rtools broken?
On the other hand, If I specify c++11 as c++ standard then the compilation process ends without any errors and in particular the last steps of the compilation process reads as follows:

g++ -shared -s -static-libgcc -o fdaPDE.dll tmp.def  ObjectFile1.o .... ObjectFileN.o -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib/x64 -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib -LC:/PROGRA~1/R/R-devel/bin/x64 -lR
installing via 'install.libs.R' to ... 

Same results using R release and R oldrelease compiling the package with rtools42 and rtools40, respectively.

In my knowledge, there is not a trick to force the call of g++ during the linking phase due to the fact that adding CXX=g++ in the Makevars.win file would have no effect on the compilation.

I would be pleased to read any advice or suggestions on this problem,
Thanks

[Gabor]

Check if this is not an R-hub issue. E.g. try win-builder of GitHub Actions if you don't have other access to Windows.

[aldoclemente]

For what concerns windows, I checked the package on my machine and also exploiting win-builder (either with R 4.3.0 or R 4.2.2).
The results on the compilation process are the same: gcc cannot link properly the standard library.

[Gabor]

In that case there is a real problem with your package. Can you share it publicly?

[aldoclemente]

I do not think the problem depends on the package. Indeed, specifying CXX_STD = CXX11 ( or CXX14 or CXX17) in the Makevars file solve the problem. In these cases the compilation ends correctly and it is performed relying on g++ instead of gcc. Hence, I think the problem is gcc contained in rtools.

[Gabor]

Many packages have been updated on CRAN recently for the same reason. They removed CXX_STD= CXX11 from Makevars* and compile fine with the current and recent R versions.

Anyway, if you think the problem is in rtools, then we cannot really help with that. You can potentially report a bug for Rtools in the R bug tracker.