[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnulib does not always detect need for iconv() hack on musl
From: |
Sergei Trofimovich |
Subject: |
Re: gnulib does not always detect need for iconv() hack on musl |
Date: |
Mon, 18 Oct 2021 09:16:36 +0100 |
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