Poor behavior for CXX=gcc (or other C compiler)

[Paul Hargrove]

If (as I did today) one accidentally passes the name of a C compiler to UPC++ configure as CXX, the results are not very "nice".

The configure script doesn't notice at all.
The GASNet-level configure fails with:

configure error: "I can\'t figure out how to build and run a program that uses C++ exceptions"

That doesn't (IMO) say "CXX is not a C++ compiler".

The fact that it gets that far (not failing GASNet's configure earlier) is solely due to gcc automatically switching language based on file suffix. We see this failure mode, only because that behavior does NOT include linking libstdc++.

Given that this really is "pilot error", and the fact that compiler drivers may accept C++ inputs to C compilers, I am not sure this is important to address, or even possible to do so easily.

My real purpose in entering this is to get the error message into our issue tracker for others to find.

[Dan Bonachea]

GASNet's C++ code does not rely explicitly on STL headers, which is why the C++ configure checks are relatively weak and only test what we actually rely upon. In the past it has supported subset C++98 compilers. And of course GASNet does not have a hard requirement on a C++ compiler at all: unless udp-conduit is explicitly force enabled (via --enable-udp), GASNet configure can complete successfully with a completely broken C++ compiler (eg CXX=false), it merely prints a warning and then disables udp-conduit.

Bottom line, GEX configure should not serve as the "gate keeper" of what constitutes a suitable C++ compiler for UPC++.

UPC++ obviously has far stronger C++ requirements. It seems suitable to add a test somewhere at the UPC++ configure level that $CXX is capable of linking a test that uses a few mandatory C++11 features and #includes and instantiates a handful of common STL templates.

[Paul Hargrove]

I don't believe that UPC++ or GASNet-EX should necessarily be responsible for diagnosing this particular problem.

I do agree that checking for C++ features (if we do so at all) would belong in UPC++.
If/when such feature probes are written to meet some other need, I can see this failure mode being addressed as a side-effect.

[Paul Hargrove]

I previously wrote:

I do agree that checking for C++ features (if we do so at all) would belong in UPC++.
If/when such feature probes are written to meet some other need, I can see this failure mode being addressed as a side-effect.

Exactly that has occurred. PR 360 addressed both issue 474 and this one.
Below is the relevant portion of develop's current output for configure CXX=gcc on Dirac. Note the last line of this excerpt in particular.

ERROR: CXX=/usr/local/pkg/gcc/11.1.0/bin/gcc failed to link object files produced by CC=/usr/local/pkg/gcc/11.1.0/bin/gcc and CXX=/usr/local/pkg/gcc/11.1.0/bin/gcc
ERROR: See config-detail.log for details. Last four lines are as follows:
conftest-cxx.cpp:(.text._ZN9__gnu_cxx13new_allocatorIdE8allocateEmPKv[_ZN9__gnu_cxx13new_allocatorIdE8allocateEmPKv]+0x4a): undefined reference to `std::__throw_bad_alloc()'
conftest-cxx.cpp:(.text._ZN9__gnu_cxx13new_allocatorIdE8allocateEmPKv[_ZN9__gnu_cxx13new_allocatorIdE8allocateEmPKv]+0x5a): undefined reference to `operator new(unsigned long)'
conftest-cxx.o:(.eh_frame+0x2bb): undefined reference to `__gxx_personality_v0'
collect2: error: ld returned 1 exit status
ERROR: It looks like CXX=/usr/local/pkg/gcc/11.1.0/bin/gcc may be a C compiler. Please use a C++ compiler instead.