Nixpkgs: gengetopt is broken

[gnidorah]

Issue description

gengetopt doesn't build anymore https://hydra.nixos.org/build/55897696
As a consequence it's impossible to build OpenWRT on NixOS.

make[4]: Entering directory '/build/gengetopt-2.22.6/src'
/nix/store/4yvcxwldmcyszgnf3v10v1zkw186vcal-bash-4.4-p12/bin/bash ../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I..  -I../gl -I../gl   -g -O2 -c -o parser.lo parser.cc
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I../gl -I../gl -g -O2 -c parser.cc  -fPIC -DPIC -o .libs/parser.o
In file included from /nix/store/ac52m7xpqggnf368sc9friqwgcjczwis-gcc-5.4.0/include/c++/5.4.0/bits/stl_algobase.h:61:0,
                 from /nix/store/ac52m7xpqggnf368sc9friqwgcjczwis-gcc-5.4.0/include/c++/5.4.0/bits/char_traits.h:39,
                 from /nix/store/ac52m7xpqggnf368sc9friqwgcjczwis-gcc-5.4.0/include/c++/5.4.0/string:40,
                 from ./parser.yy:31:
/nix/store/ac52m7xpqggnf368sc9friqwgcjczwis-gcc-5.4.0/include/c++/5.4.0/bits/cpp_type_traits.h:214:12: error: redefinition of 'struct std::__is_integer<int>'
     struct __is_integer<int>
            ^
/nix/store/ac52m7xpqggnf368sc9friqwgcjczwis-gcc-5.4.0/include/c++/5.4.0/bits/cpp_type_traits.h:176:12: error: previous definition of 'struct std::__is_integer<int>'
     struct __is_integer<wchar_t>
            ^
make[4]: *** [Makefile:751: parser.lo] Error 1
make[4]: Leaving directory '/build/gengetopt-2.22.6/src'
make[3]: *** [Makefile:808: all-recursive] Error 1
make[3]: Leaving directory '/build/gengetopt-2.22.6/src'
make[2]: *** [Makefile:597: all] Error 2
make[2]: Leaving directory '/build/gengetopt-2.22.6/src'
make[1]: *** [Makefile:609: all-recursive] Error 1
make[1]: Leaving directory '/build/gengetopt-2.22.6'
make: *** [Makefile:519: all] Error 2

Steps to reproduce

Technical details

• System: (NixOS: nixos-version, Ubuntu/Fedora: lsb_release -a, ...)
• Nix version: (run nix-env --version)
• Nixpkgs version: (run nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion)
• Sandboxing enabled: (run grep build-use-sandbox /etc/nix/nix.conf)

[primeos]

Seems like it's broken since 2bc7b4e134079cf72307538e57b8968cfb27d70c (git bisected it).
@orivej any idea how we could fix this?

[orivej]

This is the second known case when the configure script forces Bash into POSIX mode and breaks our wrappers; the first was here: https://github.com/NixOS/nixpkgs/issues/27475#issuecomment-317201058

In this case the fix is:

  postPatch = ''
    sed -e 's/set -o posix/set +o posix/' -i configure
  '';

[primeos]

@orivej That worked perfectly, thank you very much :smile: (I would've never expected that this is Bash related...).

[orivej]

To debug this issue I used:

• nix-debug-shell '<nixpkgs>' -A gengetopt (https://github.com/dezgeg/nix-debug-shell) to step through nix-build phases
• used its nd-step a couple of times and got a compilation failure
• confirmed that make reproduces it too
• recorded what make does with fptrace -rm -s /tmp/fp make (https://github.com/orivej/fptrace)
• confirmed that /tmp/fp/25-30-g++ (the last *-g++ there) fails just the same
• ran /tmp/fp/25-30-g++ -E -dD to look at the preprocessed file and see why wchar_t turned into an int (since the error was about these types being the same when a header expected them to be different)
• saw

# 82 "../gl/stddef.h" 3
#define wchar_t int

• looked at ../gl/stddef.h:

/* Some platforms lack wchar_t.  */
#if !0
# define wchar_t int
#endif

• it was generated by configure from stddef.in.h:

/* Some platforms lack wchar_t.  */
#if !@HAVE_WCHAR_T@
# define wchar_t int
#endif

• then I looked in config.log for wchar_t:

configure:17023: checking for wchar_t
configure:17047: result: no
/nix/store/mi9fgrz94516vyyp2fg7wan4q7qrv4k9-gcc-wrapper-6.4.0/nix-support/utils.sh: line 36: syntax error near unexpected token `<'

I already knew from the previous case that this happens when Bash is forced into the POSIX mode. If I didn't, I would have:

• modified configure to exit right after the check for wchar_t
• ran fptrace -rm -s /tmp/fp -u -e ./configure
• found a failing gcc with for f in /tmp/fp/*-gcc; do ( $f; true ) |& grep 'syntax error' && echo $f; done
• bisected environment variables in the script I found until I saw that the one that triggers the failure is POSIXLY_CORRECT=1

(This is exactly what I actually did the first time, except it wasn't about wchar_t.)