jann...@gnu.org, le sam. 16 nov. 2024 10:05:40 +0100, a ecrit: > So, I took another approach. I minimized the tar archive, keeping only > gnulib and a simple main: bug.c that shows the same hanging behaviour > when called with one command line argument. See attached.
How do you compile it? I failed to get a hang after switching to #if 0 > It turns out that, although there is a gnulib gnu/error.c distributed, > it is not being compiled. Ah, that's possible. And gdb pointing to it can just be gdb getting confused. You can check the value of GL_COND_OBJ_ERROR* in config.log. > Interestingly, gnu/error.h has (#warning instrumentation mine): > > --8<---------------cut here---------------start------------->8--- > extern void error (int __status, int __errnum, const char *__format, ...) > #if GNULIB_VFPRINTF_POSIX > #warning POSIX > _GL_ATTRIBUTE_FORMAT ((_GL_ATTRIBUTE_SPEC_PRINTF_STANDARD, 3, 4)) > #else > #warning NOT-POSIX > _GL_ATTRIBUTE_FORMAT ((_GL_ATTRIBUTE_SPEC_PRINTF_SYSTEM, 3, 4)) > #endif > ; > --8<---------------cut here---------------end--------------->8--- And do things break if you remove this declaration? (you have #if 1 in front of #include_next <error.h>, right?) > Which variant to choose is not determined by configure, it has been > hardcoded in gnulib's m4/stdio.m4: > > GNULIB_VFPRINTF_POSIX=0; AC_SUBST([GNULIB_VFPRINTF_POSIX]) It seems so on Linux too, so this being 0 is not a concern by itself. > and now you can guess it: we are linking against these functions from > glibc and gnulib chose wrong (or possibly glibc was compiled using the > POSIX version and should not have been??). The specification here is only for warnings about formatting, so I don't see why it would entail a crash. Again, actual asm would be enlightening. > Anyway when using the POSIX variant: > > --8<---------------cut here---------------start------------->8--- > #if 1 > #define GNULIB_VFPRINTF_POSIX 1 // fixes the static hang > #else > #define GNULIB_VFPRINTF_POSIX 0 // the gnulib setting: hangs One thing, however, is that your bug.c is bogus, it ends with a % without anything behind. Do you compile with warnings? It would warn about it. > As an extra, when compiling gnu/error.c into libgnu_a by adding: > > --8<---------------cut here---------------start------------->8--- > libgnu_a_SOURCES += error.c > --8<---------------cut here---------------end--------------->8--- > > and using > > --8<---------------cut here---------------start------------->8--- > #define error bug_error > #define error_tail bug_error_tail > --8<---------------cut here---------------end--------------->8--- > > to be sure not to use the glibc variants, both the POSIX and NOT-POSIX > versions work. Ok so it'd be the behavior of glibc that poses problem. Again, asm would tell us exactly what kind of operation gets wrong. Samuel
