Re: gnulib does not always detect need for iconv() hack on musl

[Sergei Trofimovich]

On Mon, Oct 18, 2021 at 02:27:38AM +0200, Bruno Haible wrote:
> > The current code in config.guess is a heuristic (that has been working
> > on Alpine Linux up to 3.13)
> 
> It works also in Alpine Linux 3.14.2. Which distro are you using?

I'm trying to use it on NixOS. I think I tracked it down to infelicity
of bootstrap environment.

For most packages config.guess returns correct value:

    $ nix develop -f. pkgsMusl.bison
    $ unpackPhase
    $ cd bison-3.7.6
    $ ./build-aux/config.guess
    x86_64-pc-linux-musl

But for packages that use bootstrap toolchain the detection fails:

   # don't know how to get better environment against bootstrap toolchain
   $ nix develop /nix/store/iwlhpwbfmr6v5mh0g6iabl3161am5gdd-bison-3.8.2.drv
   $ unpackPhase
   $ cd bison-3.8.2
   $ ./build-aux/config.guess
   x86_64-pc-linux-gnu

When I compare the two the difference is in expansion of
    #include <stdarg.h>
(exactly what 'config.guess' probes).

In a good case 'stdarg.h' from musl is used:

    $ echo '#include <stdarg.h>' | gcc -E - | unnix
    # 1 "<stdin>"
    # 1 "<built-in>"
    # 1 "<command-line>"
    # 1 "/<<NIX>>/musl-1.2.2-dev/include/stdc-predef.h" 1 3 4
    # 1 "<command-line>" 2
    # 1 "<stdin>"
    # 1 "/<<NIX>>/musl-1.2.2-dev/include/stdarg.h" 1 3 4
    # 10 "/<<NIX>>/musl-1.2.2-dev/include/stdarg.h" 3 4
    # 1 "/<<NIX>>/musl-1.2.2-dev/include/bits/alltypes.h" 1 3 4
    # 326 "/<<NIX>>/musl-1.2.2-dev/include/bits/alltypes.h" 3 4
    
    # 326 "/<<NIX>>/musl-1.2.2-dev/include/bits/alltypes.h" 3 4
    typedef __builtin_va_list va_list;
    # 11 "/<<NIX>>/musl-1.2.2-dev/include/stdarg.h" 2 3 4
    # 2 "<stdin>" 2

In a bad case we use gcc's wrapper of 'stdarg.h':

    $ echo '#include <stdarg.h>' | gcc -E - | unnix
    # 1 "<stdin>"
    # 1 "<built-in>"
    # 1 "<command-line>"
    # 1 "/<<NIX>>/bootstrap-tools/include-libc/stdc-predef.h" 1 3 4
    # 1 "<command-line>" 2
    # 1 "<stdin>"
    # 1 
"/<<NIX>>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h"
 1 3
    # 40 
"/<<NIX>>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h"
 3
    
    # 40 
"/<<NIX>>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h"
 3
    typedef __builtin_va_list __gnuc_va_list;
    # 99 
"/<<NIX>>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h"
 3
    typedef __gnuc_va_list va_list;
    # 1 "<stdin>" 2

I think it happens because NixOS's bootstrap toolchain uses slightly
different include orders:

Good case:

  /<<NIX>>/gcc-10.3.0/include
  /<<NIX>>/musl-1.2.2-dev/include
    # ^ <<<- picked 'stdarg.h' from here, musl version
  /<<NIX>>/gcc-10.3.0/lib/gcc/x86_64-unknown-linux-musl/10.3.0/include
  /<<NIX>>/gcc-10.3.0/lib/gcc/x86_64-unknown-linux-musl/10.3.0/include-fixed

Bad case:

  
/<<NIX>>/bootstrap-tools/bin/../lib/gcc/x86_64-unknown-linux-musl/7.3.0/include
    # ^ <<<- picked stdarg from here, gcc version
  /<<NIX>>/bootstrap-tools/bin/../lib/gcc/../../include
  /<<NIX>>/bootstrap-stage0-musl-bootstrap/include
  /<<NIX>>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include-fixed

Perhaps "Bad case" is more natural include order as 'gcc' tries hard
nowadays to isolate standard headers from accidental namespace
pollution (like '__DEFINED_va_list' define config.guess searches for).

I'll bring it to NixOS first to find out what is intended order here first.

-- 

  Sergei