Closed ericonr closed 2 years ago
Can you please provide more info - what is the build env, what is the exact error (from config.log) for the mis-detection?
Oopsie, I didn't read the subject.
I believe that the proper fix should go in autotools
by e.g. adding a -Wno-error to the tests that are yielding warnings by design.
It is another story if the compiler in use supports -Werror/-Wno-error and that would break the tests in case it doesn't...
My opinion is that this should not be "fixed" out of autotools
- it is a common problem for all projects using it.
In case you do not have something to add, please close the issue.
I believe that the proper fix should go in autotools by e.g. adding a -Wno-error to the tests that are yielding warnings by design.
That is definitely the wrong fix.
mempcpy
generates a warning because it isn't exposed by headers, since _GNU_SOURCE
isn't defined. Other functions in the same block work, because they are exposed without the need for feature test macros. This autoconf macro should work with -Werror
. Testing for functions should verify availability in headers and for linking; the header test currently fails, but because GCC doesn't consider implicit definitions to be an error by default, it isn't noticed without -Werror
.
configure:20221: gcc -o conftest -Werror -D_GNU_SOURCE conftest.c >&5
conftest.c:103:6: error: conflicting types for built-in function 'mempcpy'; expected 'void (void , const void *, long unsigned int)' [-Werror=builtin-declaration-m
ismatch]
103 | char mempcpy ();
| ^~~
The issue here is that autoconf generates these test programs itself, and autoconf sucks :)
Detection of
mempcpy
andstpcpy
fails, at least, because autoconf sucks and the macros defined inAC_USE_SYSTEM_EXTENSIONS
aren't propagated to the rest of the build system - so the functions aren't declared due to a lack of_GNU_SOURCE
. I'm not sure what a pretty fix here would be, besides appending toCFLAGS
ourselves around the tests for these functions.