gap-system
Build system: configure checks for supported compiler warning flags should be run independently for C and C++ compiler
Please use the following template to submit an issue (you may delete lines which are not used). Thank You!
Observed behaviour
CXX ../../src/trans.cc => obj/src/trans.lo
warning: unknown warning option '-Wno-cast-function-type'; did you mean '-Wno-bad-function-cast'?
[-Wunknown-warning-option]
warning: unknown warning option '-Wduplicated-branches' [-Wunknown-warning-option]
warning: unknown warning option '-Wduplicated-cond'; did you mean '-Wduplicate-enum'?
[-Wunknown-warning-option]
warning: unknown warning option '-Wlogical-op'; did you mean '-Wlong-long'?
[-Wunknown-warning-option]
warning: unknown warning option '-Wrestrict' [-Wunknown-warning-option]
warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'?
[-Wunknown-warning-option]
6 warnings generated.
Expected behaviour
No warnings
Copy and paste GAP banner (to tell us about your setup)
This is a debugging build of master using gcc-8.
That's odd, I cannot reproduce this with GCC 9.2 on macOS 10.14. Normally, our configure script should detect options not supported by the compiler, and not use them. I'll reinstall GCC 8 now to test with that, but I am pretty sure I never had the issue with it before either.
Could you perhaps attach your config.log file, so that we can see what those warning flag checks did?
Also, could you please specify the precise GCC version, as well as your OS?
It’s possible I managed to configure with one compiler and build with another. I’ll check.
Steve
On 29 May 2019, at 12:20, Max Horn [email protected] wrote:
That's odd, I cannot reproduce this with GCC 9.2 on macOS 10.14. Normally, our configure script should detect options not supported by the compiler, and not use them. I'll reinstall GCC 8 now to test with that, but I am pretty sure I never had the issue with it before either.
Could you perhaps attach your config.log file, so that we can see what those warning flag checks did?
Also, could you please specify the precise GCC version, as well as your OS?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/gap-system/gap/issues/3475?email_source=notifications\u0026email_token=ABQQIRSS5Y6F2LB2QPFFUTDPXZRIHA5CNFSM4HPUNL3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWPAH3I#issuecomment-496894957", "url": "https://github.com/gap-system/gap/issues/3475?email_source=notifications\u0026email_token=ABQQIRSS5Y6F2LB2QPFFUTDPXZRIHA5CNFSM4HPUNL3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWPAH3I#issuecomment-496894957", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]
OK. The problem arose when I configured
../../configure --enable-debug CC=gcc-8
It goes away if I configure
../../configure --enable-debug CC=gcc-8 CXX=g++-8
In the first setup the C++ compiler is just g++
I'm not sure whether that counts as just user error, whether the configure script should identify the supported warning flags separately for CC and CXX or whether CXX should default to CC.
We already track warning flags separately, in WARN_CFLAGS and WARN_CXXFLAGS. Alas, we do so lazily, and only do the full work twice for those flags where we know they are specific to C / C++ compilers. So ideally, that code should check both CC and CXX completely independently. But that makes configure even slower (which isn't an issue on Linux, where it is very fast anyway; is somewhat of an issue on macOS, where it slower; and is quite an issue on Windows, where it is very slow).
That said, all kind of other issues might result from mixing compilers. But I am not sure whether we can easily detect this...
Anyway, all in all, this is a very minor issue. Not sure whether it is worth the hassle of resolving it.
With current gcc-13 (default) and clang-17 (also installed), you can trigger a build failure with CC=clang. That will eventually cause g++ to spit out g++: error: unrecognized command-line option '-Wmissing-variable-declarations'; did you mean '-Wmissing-declarations'?
I don't know how easy this is to do, but my preference here would be to forbid this kind of inconsistent compiler combination -- while we could fix the compiler warning, I have no interest in supporting someone building with half-clang, half-g++, then linking the results together :)
I don't know how easy this is to do, but my preference here would be to forbid this kind of inconsistent compiler combination -- while we could fix the compiler warning, I have no interest in supporting someone building with half-clang, half-g++, then linking the results together :)
It's just an easy way to reproduce the problem in this report. I'll worry about supporting it if the build ever gets that far.