Hi Andreas, On Sun, Jul 09, 2023 at 04:04:20PM +0200, Andreas Metzler wrote: > > @@ -178,10 +179,13 @@ > > return strerror_r (EINVAL, buf, 32); > > } > > ]])], > > + [ac_cv_strerror_r_ret=xsi], > > + [ac_cv_strerror_r_ret=gnu], > > + [ac_cv_strerror_r_ret=cross])]) > > + dnl Guess that we cross build on glibc > > + AS_IF([test "$ac_cv_strerror_r_ret" = xsi], > > [AC_DEFINE([HAVE_XSI_STRERROR_R], 1, [Whether > > XSI-compliant strerror_r() is available])], > > - [AC_DEFINE([HAVE_GNU_STRERROR_R], 1, [Whether > > GNU-specific strerror_r() is available])], > > - [])], > > - []) > > + [AC_DEFINE([HAVE_GNU_STRERROR_R], 1, [Whether > > GNU-specific strerror_r() is available])])]) > > > AC_CACHE_CHECK([for thread-local storage class], > > [ac_cv_tls_keyword], > > Hello Helmut, > > thanks. > > I guess this should read > AS_IF([test "$ac_cv_strerror_r_ret" = cross], > > instead of > > AS_IF([test "$ac_cv_strerror_r_ret" = xsi], > > ?
Thanks for asking rather than just changing my patch. I think my patch is correct as is. If the strerror_r returns 0, ac_cv_strerror_r_ret will be set to xsi. In that case, we want to define HAVE_XSI_STRERROR_R. In other cases, ac_cv_strerror_r_ret will be set to gnu or cross. Since I guess cross compilation to target glibc, I set HAVE_GNU_STRERROR_R in both cases. Do you now see why it needs to be the way I've written it? > Also wouldn't using AC_FUNC_STRERROR_R be a better fix? (I do not expect > you to provide this, I asking for your opinion) After having read the documentation of that macro, I am unsure whether it resolves what is being checked here. AC_FUNC_STRERROR_R checks for the function and also for how it is being declared, but makes no statement about its return value. If there is a connection between return type and return value that I don't see, then yes, this may be better. Otherwise, this probably still is better than using AC_CHECK_FUNC outside. Maybe that connection is XSI <=> int return, GNU <=> pointer return? Helmut
