bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] buildi


From: Samuel Thibault
Subject: Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]
Date: Sat, 16 Nov 2024 10:41:59 +0100

janneke@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]