From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D19A91F670 for ; Mon, 18 Oct 2021 08:16:45 +0000 (UTC) Received: from localhost ([::1]:48430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mcNp6-000081-Vu for normalperson@yhbt.net; Mon, 18 Oct 2021 04:16:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58474) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mcNp4-00007g-2K for bug-gnulib@gnu.org; Mon, 18 Oct 2021 04:16:42 -0400 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:40871) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mcNp1-0002k0-Me for bug-gnulib@gnu.org; Mon, 18 Oct 2021 04:16:41 -0400 Received: by mail-wm1-x32c.google.com with SMTP id a140-20020a1c7f92000000b0030d8315b593so9494540wmd.5 for ; Mon, 18 Oct 2021 01:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=nI9dnIHFTFeqe6qUo9SK5aCwqM9t+TcsB/O78s68oMQ=; b=ot2fCnRLBkFHdn4nXlbHQLOwLxckR0khFC4fnmhOlfEWmy8B8thQpTvwDW3t0iYZrR T8nqcceJuWGOYLrzmzYsZLih1WzIDN8+nGy7me/39Q71cTGQzq4VDQ7o4z1TY1oZxSKX zBHjjS5w6n5oveO7VlZw9Ge6+yOaGKHv8yMtwMLpql27pz7KscY935oC9KcVqr2imgHZ NnFsPXF56XqL/xptVDOJ8eUyZkLR2Cv9okdtvWr5oNV6/4mt3VKJDbMOqhvkeXxoHWD5 KWxISriWEQz2DMgaXMODmnnhUJgi2H5JiheMILVoNtM6jt5jEy7CUxIQGY8D9rW8JuQm 51sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nI9dnIHFTFeqe6qUo9SK5aCwqM9t+TcsB/O78s68oMQ=; b=sCCQUMmSVgJqcBUCDDBQt7YwNGV2bkdbR5zSH5nGmIcqwc64+A6cjTDXes1f3Yx5m4 7BOiFIw6WZNy0He2O7M74dU+KBWUhemhaUxQG6hP8rHkAqwXqfeoJlb/uEU901NJ4BKn sRWPWjAe0cg/rRdrMrHx4WYnfU/YNU/VZJVKJEADvtMx6Sx+IsIXToShIZ5qM0DagGal mk7QBB1t1bEhHE7NNnOm7VBDHscXsOR+C7sxnnWF3cOd/+WQGJKxVF5atr6O9ehfbMJU N1HkyfNgU3HBfViDZkBiuBL++fooE270a2GNSjDAQnkJUiOmkjdVSH15bWZ10R9KYbSK jTpQ== X-Gm-Message-State: AOAM533+hkIfNLoR9BrndfxcEO1UN3FejnZI/Lb0mTI/VzV3OVNl506a 2MB0LPyGjX9/8XGm/KzshR0= X-Google-Smtp-Source: ABdhPJyBawh0Rn3CybfGc4wIk+e+lr2VHwN5/Ty7DiN/SA/JTHFwWeSMM3JE3jEwwr9Utv1ByXxd1A== X-Received: by 2002:a1c:1dcb:: with SMTP id d194mr28745800wmd.156.1634544998171; Mon, 18 Oct 2021 01:16:38 -0700 (PDT) Received: from nz.home (host81-129-83-159.range81-129.btcentralplus.com. [81.129.83.159]) by smtp.gmail.com with ESMTPSA id 196sm11859056wme.20.2021.10.18.01.16.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Oct 2021 01:16:37 -0700 (PDT) Received: by nz.home (Postfix, from userid 1000) id 00E4B8385542; Mon, 18 Oct 2021 09:16:36 +0100 (BST) Date: Mon, 18 Oct 2021 09:16:36 +0100 From: Sergei Trofimovich To: Bruno Haible Subject: Re: gnulib does not always detect need for iconv() hack on musl Message-ID: References: <7178054.Whz1cUOskA@omega> <11669625.0mgMEAqHVh@omega> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11669625.0mgMEAqHVh@omega> Received-SPF: pass client-ip=2a00:1450:4864:20::32c; envelope-from=slyich@gmail.com; helo=mail-wm1-x32c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" 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 (exactly what 'config.guess' probes). In a good case 'stdarg.h' from musl is used: $ echo '#include ' | gcc -E - | unnix # 1 "" # 1 "" # 1 "" # 1 "/<>/musl-1.2.2-dev/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "" # 1 "/<>/musl-1.2.2-dev/include/stdarg.h" 1 3 4 # 10 "/<>/musl-1.2.2-dev/include/stdarg.h" 3 4 # 1 "/<>/musl-1.2.2-dev/include/bits/alltypes.h" 1 3 4 # 326 "/<>/musl-1.2.2-dev/include/bits/alltypes.h" 3 4 # 326 "/<>/musl-1.2.2-dev/include/bits/alltypes.h" 3 4 typedef __builtin_va_list va_list; # 11 "/<>/musl-1.2.2-dev/include/stdarg.h" 2 3 4 # 2 "" 2 In a bad case we use gcc's wrapper of 'stdarg.h': $ echo '#include ' | gcc -E - | unnix # 1 "" # 1 "" # 1 "" # 1 "/<>/bootstrap-tools/include-libc/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "" # 1 "/<>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h" 1 3 # 40 "/<>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h" 3 # 40 "/<>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h" 3 typedef __builtin_va_list __gnuc_va_list; # 99 "/<>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h" 3 typedef __gnuc_va_list va_list; # 1 "" 2 I think it happens because NixOS's bootstrap toolchain uses slightly different include orders: Good case: /<>/gcc-10.3.0/include /<>/musl-1.2.2-dev/include # ^ <<<- picked 'stdarg.h' from here, musl version /<>/gcc-10.3.0/lib/gcc/x86_64-unknown-linux-musl/10.3.0/include /<>/gcc-10.3.0/lib/gcc/x86_64-unknown-linux-musl/10.3.0/include-fixed Bad case: /<>/bootstrap-tools/bin/../lib/gcc/x86_64-unknown-linux-musl/7.3.0/include # ^ <<<- picked stdarg from here, gcc version /<>/bootstrap-tools/bin/../lib/gcc/../../include /<>/bootstrap-stage0-musl-bootstrap/include /<>/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