bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]