[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: namespacing issues with Gnulib
From: |
Bruno Haible |
Subject: |
Re: namespacing issues with Gnulib |
Date: |
Thu, 08 Dec 2022 20:00:31 +0100 |
Eli Zaretskii wrote:
> > Attempting to --whole-archive link on that platform grants us:
> >
> > $ x86_64-linux-musl-gcc -o ginstall-info install-info.o \
> > -Wl,--whole-archive ../gnulib/lib/libgnu.a -Wl,--no-whole-archive
> > /usr/libexec/gcc/x86_64-linux-musl/ld:
> > ../gnulib/lib/libgnu.a(libgnu_a-error.o): in function `error':
> > error.c:(.text+0xe0): multiple definition of `error';
> > install-info.o:install-info.c:(.text+0x4a0): first defined here
> > collect2: error: ld returned 1 exit status
>
> Now _that_ IMO is a problem with Gnulib's use in this case: Gnulib
> evidently assumes that no application will define its own 'error'
> function, something that applications are free to do.
> ...
> In general, I believe certain names used by a Standard C Library are
> "reserved", and applications must not redefine them. But 'error' is
> not one of those reserved names, AFAIK. So an application is in its
> full rights when it defines its own 'error' that is not compatible
> with that from libc.
The standards make namespacing statements only w.r.t. the libc vs. the
application. From the point of view of the standards, install-info.c and
the Gnulib code are both on the application side; therefore the standards
cannot help resolving a conflict between install-info.c and Gnulib code.
What are the possible ways to resolve the conflict?
(A) Could Gnulib define the symbol 'error' as weak?
The concept of "weak" symbols exists only in ELF; therefore this
approach would be non-portable (not working with Windows DLLs or
COFF or MachO binary formats).
(B) An ad-hoc solution: Near the top of install-info.c, add
#define error glibc_compatible_error
and later, after all #includes:
#undef error
This is ugly, but it is cheap. And it does not cause problems if
install-info.c is split into several .c files in the future.
(C) gnulib-tool could infer from the command-line arguments that the
module 'error' is only indirectly used, i.e. not explicitly requested,
and then arrange for the gnulib-lib subdirectory to have a config.h
that does
#include "../config.h" /* include definitions from autoconf */
/* put indirectly used symbols into a namespace */
#define error libgnu_error
This approach is more generic, but
- It is not (yet) implemented in gnulib-tool.
- "make" will compile most Gnulib-derived object files twice, once
to detect which symbols to redefine in config.h, and once for real.
So, with this approach, the build times of your package are increased.
Any other ideas?
Bruno
- -Wlto-type-mismatch warning in error(), Sam James, 2022/12/07
- Re: -Wlto-type-mismatch warning in error(), Arsen Arsenović, 2022/12/07
- Re: -Wlto-type-mismatch warning in error(), Gavin Smith, 2022/12/07
- Re: -Wlto-type-mismatch warning in error(), Bruno Haible, 2022/12/07
- Re: -Wlto-type-mismatch warning in error(), Eli Zaretskii, 2022/12/08
- Re: -Wlto-type-mismatch warning in error(), Arsen Arsenović, 2022/12/08
- Re: -Wlto-type-mismatch warning in error(), Eli Zaretskii, 2022/12/08
- Re: namespacing issues with Gnulib,
Bruno Haible <=
- Re: namespacing issues with Gnulib, Eli Zaretskii, 2022/12/08
- Re: namespacing issues with Gnulib, Arsen Arsenović, 2022/12/08
- Re: namespacing issues with Gnulib, Paul Eggert, 2022/12/08
- Re: -Wlto-type-mismatch warning in error(), Arsen Arsenović, 2022/12/08
- Re: -Wlto-type-mismatch warning in error(), Gavin Smith, 2022/12/09
- Re: -Wlto-type-mismatch warning in error(), Gavin Smith, 2022/12/09
- Re: -Wlto-type-mismatch warning in error(), Paul Eggert, 2022/12/10
- Re: -Wlto-type-mismatch warning in error(), Jeffrey Walton, 2022/12/10
- Re: -Wlto-type-mismatch warning in error(), Florian Weimer, 2022/12/09