Bug#1040472: p11-kit FTCBFS: AC_RUN_IFELSE
Control: tags -1 fixed-upstream On 2023-07-09 Helmut Grohne wrote: > On Sun, Jul 09, 2023 at 04:04:20PM +0200, Andreas Metzler wrote: [...] > > 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? Hello, Yes, afaiu the two different strerrors can be distinguished by their return type (according to strerror_r(3)) and that is exactly what AC_FUNC_STRERROR_R provides without needing AC_RUN_IFELSE. The AC_RUN_IFELSE check also tests whether strerror_r() returns 0 (XSI) or a pointer (i.e. <>0). Nevermind ... this has been fixed upstream. (With AC_COMPILE_IFELSE). https://github.com/p11-glue/p11-kit/commit/3ba2c55dfdc8ff20de369f07f6c57d08718d3add cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1040472: p11-kit FTCBFS: AC_RUN_IFELSE
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
Bug#1040472: p11-kit FTCBFS: AC_RUN_IFELSE
On 2023-07-06 Helmut Grohne wrote: > Source: p11-kit [...] > - [AC_RUN_IFELSE( > + [AC_CACHE_CHECK([strerror_r return > value],[ac_cv_strerror_r_ret],[ > + AC_RUN_IFELSE( > [AC_LANG_SOURCE([[ > #include > #include > @@ -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], ? 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) TIA, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1040472: p11-kit FTCBFS: AC_RUN_IFELSE
Source: p11-kit Version: 0.25.0-2 Severity: important Justification: breaks architecture bootstrap User: debian-cr...@lists.debian.org Usertags: ftcbfs User: helm...@debian.org Usertags: rebootstrap Tags: patch upstream Hi, p11-kit gained a new AC_RUN_IFELSE check and that happens to break cross building and therefore also architecture bootstrap. I propose adding a default result for this check (assuming that it usually will be cross built for glibc) while making it modifiable using a cache variable. I'm attaching a patch for your convenience. Helmut --- p11-kit-0.25.0.orig/configure.ac +++ p11-kit-0.25.0/configure.ac @@ -167,7 +167,8 @@ AC_CHECK_FUNC( [strerror_r], - [AC_RUN_IFELSE( + [AC_CACHE_CHECK([strerror_r return value],[ac_cv_strerror_r_ret],[ + AC_RUN_IFELSE( [AC_LANG_SOURCE([[ #include #include @@ -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],
