"GNULIB_STRERROR" redefined in single-configure package

"GNULIB_STRERROR" redefined in single-configure package

[Daiki Ueno]

Hello,

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?

Regards,
-- 
Daiki Ueno

Re: "GNULIB_STRERROR" redefined in single-configure package

[Bruno Haible]

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

Re: "GNULIB_STRERROR" redefined in single-configure package

[Daiki Ueno]

Hello Bruno,

Bruno Haible <bruno@clisp.org> writes:

> 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.

Thank you so much for the explanation and the suggestions.  I've tried
(b) as it seems to be slighly more lightweight, and it worked:

https://gitlab.com/gnutls/gnutls/-/merge_requests/1345/diffs?commit_id=1fc78a5a3e6646e4082be7ec1c4d60b9d40213d0

Regards,
-- 
Daiki Ueno