[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "GNULIB_STRERROR" redefined in single-configure package
From: |
Bruno Haible |
Subject: |
Re: "GNULIB_STRERROR" redefined in single-configure package |
Date: |
Sun, 25 Oct 2020 17:20:58 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-189-generic; KDE/5.18.0; x86_64; ; ) |
Hi Daiki,
> In GnuTLS, we import Gnulib sources in two phases, first LGPL sources to
> be linked with the library, and then GPL sources for the tools and
> tests, something like following:
>
> In bootstrap:
>
> gnulib-tool --extract-recursive-dependencies "$gnulib_modules"
> gnulib-tool --import --local-dir=src/gl/override --lib=libgnu_gpl
> --source-base=src/gl --m4-base=src/gl/m4 --doc-base=doc --aux-dir=build-aux
> --no-conditional-dependencies --libtool --macro-prefix=ggl --without-tests
> --no-vc-files "$src_modules"
>
> In configure.ac:
>
> gl_INIT
> ggl_INIT
>
> It had worked until we added 'xalloc' to $src_modules, but now,
> confdefs.h generated during the configure phase contains two definitions
> of GNULIB_STRERROR and it prevents compilation with -Werror:
>
> configure:53786: gcc -o conftest -O0 -Wall -Werror -g3 conftest.c -lev
> >&5
> conftest.c:412: error: "GNULIB_STRERROR" redefined [-Werror]
> 412 | #define GNULIB_STRERROR 1
> |
> conftest.c:305: note: this is the location of the previous definition
> 305 | #define GNULIB_STRERROR IN_GNUTLS_GNULIB_TESTS
> |
> cc1: all warnings being treated as errors
>
> Could anyone shed some light on this?
gnulib-tool was designed for a set of main modules and a set of tests
modules, to be compiled in different directories. Adding support for
arbitrary sets of directories with different sets of modules and with/without
-I options would be a major undertaking. This has not been done. So you
are left with various possible adjustments of the sets of directories.
Currently your situation is:
same configure ---- module set (A) + tests of (A)
---- module set (A∪B)
I can see two reasonable ways to modify the situation:
(a) 1/configure ---- module set (A)
---- module set (A∪B)
2/configure ---- module set (A) + tests of (A)
In other words, use a second directory purely for testing (A).
Two two directories 1/configure and 2/configure will be completely
separate, in particular no -I options that point from 2/Makefile to 1/.
(b) same configure ---- module set (A)
---- module set (A∪B) + tests of (A∪B)
In other words, test more modules, not only those of the subset (A).
This should work, because gnulib-tool has been tested numerous times
with module sets (U) ⊂ (V) ⊂ (W), whereas the situation that causes
the problem is when it's not well-ordered.
Bruno