Re: namespacing issues with Gnulib

[Bruno Haible]

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