On Sat, Dec 10, 2022 at 01:48:23AM +, Gavin Smith wrote:
> Making the symbols provided by install-info.c weak might work,
> so one idea is that when a program uses Gnulib, all of the global
> symbols from the program (excluding Gnulib) should be marked as weak
> in produced object files, so
On Thu, Dec 08, 2022 at 09:25:01AM +0100, Arsen Arsenović wrote:
> > Shouldn't we report this to the GCC folks? It could be a bug in lto,
> > no? I mean, 'error' is not a symbol that applications cannot use, and
> > if an application defines a function by that name, it should not be
> > imported
This fixes things in what I hope is a better way than the
fd-only approach proposed by Kamil Dudka here:
https://lists.gnu.org/archive/html/bug-gnulib/2018-03/msg00079.html
https://lists.gnu.org/archive/html/bug-gnulib/2018-03/msg00080.html
* lib/fts.c (GNULIB_FTS_DEBUG): Rename from FTS_DEBUG,
to
Florian Weimer wrote:
> lib/xmalloc.c contains this function definition, unconditionally:
>
> static void * _GL_ATTRIBUTE_PURE
> nonnull (void *p)
> {
> if (!p)
> xalloc_die ();
> return p;
> }
>
> But the declaration of xalloc_die in lib/xalloc.h is conditional:
>
> #if
* Bruno Haible:
> Gavin Smith wrote:
>> I expect it is not a gnulib problem. install-info/install-info.c declares
>> a function called "error" which appears to clash with a function from glibc.
>> ... The "error" module is brought in by "xalloc" (which we
>> ask for explicitly).
>
> Yes, I think
lib/xmalloc.c contains this function definition, unconditionally:
static void * _GL_ATTRIBUTE_PURE
nonnull (void *p)
{
if (!p)
xalloc_die ();
return p;
}
But the declaration of xalloc_die in lib/xalloc.h is conditional:
#if GNULIB_XALLOC_DIE
/* This function is
