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