GCC support on Windows

[rwmcintosh]

@Yuri05 @PavelBal @georgeDaskalakis @msevestre

Until recently, the rClr package could be compiled using GCC on Windows. We were not using that, and some of the build scripting that supported that is gone.

However, we will always need to support GCC builds for Linux.

There is at least one case we know of where we've had to make an accommodation due to MSVC lack of support for a C++ extension that GCC does support (we are compiling on Windows with R_LEGACY_RCOMPLEX defined).

From the include file supplied by R (Rinternals.h). In the end, we use the simpler typedef struct instead of typedef union with an anonymous struct.

# ifdef R_LEGACY_RCOMPLEX

/* This definition does not work with optimizing compilers which take
advantage of strict aliasing rules.  It is not safe to use with Fortran
COMPLEX*16 (PR#18430) or in arguments to library calls expecting C99
_Complex double.  This definition should not be used, but if it were still
necessary, one should at least disable LTO.
*/

typedef struct {
 	double r;
 	double i;
 } Rcomplex;

# else

/* This definition uses an anonymous structure, which is defined in C11 (but
not C99).  It is, however, supported at least by GCC, clang and icc.  The
private_data_c member should never be used in code, but tells the compiler
about type punning when accessing the .r and .i elements, so is safer to use
when interfacing with Fortran COMPLEX*16 or directly C99 _Complex double
(PR#18430).

This form of static initialization works with both definitions:
Rcomplex z = { .r = 1, .i = 2 };

Anonymous structures and C99 _Complex have not been incorporated into C++
standard.  While they are usually supported as compiler extensions, warnings
are typically issued (-pedantic) by a C++ compiler.
*/

#ifdef __cplusplus
// Look for clang first as it defines __GNUC__ and reacts to #praema GCC
# if defined(__clang__)
#  pragma clang diagnostic push
#  pragma clang diagnostic ignored "-Wgnu-anonymous-struct"
#  pragma clang diagnostic ignored "-Wc99-extensions"
# elif defined(__GNUC__)
#  pragma GCC diagnostic push
#  pragma GCC diagnostic ignored "-Wpedantic"
# endif
#endif

typedef union {
    struct {
	double r;
	double i;
    };
    double _Complex private_data_c;
} Rcomplex;

#ifdef __cplusplus
# if defined(__clang__)
#  pragma clang diagnostic pop
# elif defined(__GNUC__)
#  pragma GCC diagnostic pop
# endif
#endif

# endif 

I'm not sure of the impact, but in any case, it took some work for us to find this fix when we upgraded the R version and R headers we are compiling against.

Second question is - if we decide to support GCC on Windows, should we also support MSVC? It sure is handy for debugging. I've never used VS to cross-compile, but maybe that would work just using GCC instead of MSVC?

[Yuri05]

@rwmcintosh We should try the GCC on Windows. If it works - I don't see a reason, why we really would need MSVC.
It's just that in the past I often had problem when mixing C++ libs compiled with different compilers (e.g. MSVC version X vs. MSVC version Y etc.).
One of the reasons was that STL implementations were not compatible. But it is not used by rClr - so we might be lucky.

https://learn.microsoft.com/en-us/answers/questions/1305292/how-to-configure-and-use-gcc-compiler-to-generate

[PavelBal]

@georgeDaskalakis FYI

[Yuri05]

and of course I also asked chatGPT 😄

[Yuri05]

so maybe we should keep MSVC on Windows :)

[rwmcintosh]

They are all compiled with extern "C" and no STL.

I'm pretty sure that's all that's needed for the interfaces to be compatible. But I'm not sure about the dependencies.

Until recently, GCC was a build option for rClr on Windows, so I think it should still work.