Message ID | 20240722220922.590401-1-fontaine.fabrice@gmail.com |
---|---|
State | Accepted |
Headers | show |
Series | [1/1] package/coreutils: fix glibc build with gcc >= 14 | expand |
On Tue, 23 Jul 2024 00:09:22 +0200 Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote: > ac_cv_func_strerror_r_char_p is hardcoded to no since commit > 74b9bf9945921a7b0504b4b546a4bc26f2adcc45 back in 2005 however strerror_r > only returns an int with musl. With glibc or uclibc, strerror_r returns > a char* or an int depending on _GNU_SOURCE value resulting in the > following build failure with gcc >= 14: > > strerror_r.c: In function 'rpl_strerror_r': > strerror_r.c:207:9: error: assignment to 'int' from 'char *' makes integer from pointer without a cast [-Wint-conversion] > 207 | ret = strerror_r (errnum, buf, buflen); > | ^ > > To fix this build failure, don't hardcode ac_cv_func_strerror_r_char_p > to let coreutils pick the correct value > > Fixes: > - http://autobuild.buildroot.org/results/8bc649ca5490b0c29c90383edfa2e693f154ebc4 > > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> > --- > package/coreutils/coreutils.mk | 1 - > 1 file changed, 1 deletion(-) Applied to master, thanks. But then it means that indeed your commit 6f34e68217264fb62c48ce28c48bf759b30fef0e fixing the same issue in package/apr could be improved to avoid using an AC_TRY_RUN(), and therefore not need an autoconf cache variable value passed by apr.mk. Thanks! Thomas
>>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes: > ac_cv_func_strerror_r_char_p is hardcoded to no since commit > 74b9bf9945921a7b0504b4b546a4bc26f2adcc45 back in 2005 however strerror_r > only returns an int with musl. With glibc or uclibc, strerror_r returns > a char* or an int depending on _GNU_SOURCE value resulting in the > following build failure with gcc >= 14: > strerror_r.c: In function 'rpl_strerror_r': > strerror_r.c:207:9: error: assignment to 'int' from 'char *' makes integer from pointer without a cast [-Wint-conversion] > 207 | ret = strerror_r (errnum, buf, buflen); > | ^ > To fix this build failure, don't hardcode ac_cv_func_strerror_r_char_p > to let coreutils pick the correct value > Fixes: > - http://autobuild.buildroot.org/results/8bc649ca5490b0c29c90383edfa2e693f154ebc4 > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Committed to 2024.05.x, thanks.
diff --git a/package/coreutils/coreutils.mk b/package/coreutils/coreutils.mk index 846d4fa567..89f494310e 100644 --- a/package/coreutils/coreutils.mk +++ b/package/coreutils/coreutils.mk @@ -27,7 +27,6 @@ COREUTILS_CONF_ENV = ac_cv_c_restrict=no \ ac_cv_func_getgroups=yes \ ac_cv_func_getgroups_works=yes \ ac_cv_func_getloadavg=no \ - ac_cv_func_strerror_r_char_p=no \ ac_cv_func_strnlen_working=yes \ ac_cv_have_decl_strerror_r=yes \ ac_cv_have_decl_strnlen=yes \
ac_cv_func_strerror_r_char_p is hardcoded to no since commit 74b9bf9945921a7b0504b4b546a4bc26f2adcc45 back in 2005 however strerror_r only returns an int with musl. With glibc or uclibc, strerror_r returns a char* or an int depending on _GNU_SOURCE value resulting in the following build failure with gcc >= 14: strerror_r.c: In function 'rpl_strerror_r': strerror_r.c:207:9: error: assignment to 'int' from 'char *' makes integer from pointer without a cast [-Wint-conversion] 207 | ret = strerror_r (errnum, buf, buflen); | ^ To fix this build failure, don't hardcode ac_cv_func_strerror_r_char_p to let coreutils pick the correct value Fixes: - http://autobuild.buildroot.org/results/8bc649ca5490b0c29c90383edfa2e693f154ebc4 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> --- package/coreutils/coreutils.mk | 1 - 1 file changed, 1 deletion(-)