From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 91AC5385840E for ; Fri, 20 Jan 2023 14:23:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 91AC5385840E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674224605; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2wN8N4AUyw8VuQ68b8rGeQkVhhCwe+4k4ByhDvL57HY=; b=B9wSHDW4YSjja3hD4CCVeul87xjEOP9aoCNMylqfVyJqpC3rNqasxewCpzvL57CQhYRiKF LGsJLQv4qaBF2SdogvpPj6mN5EKT80FoCSTLkAZxKCpPOVQmM+OZ2y5as6PDAmc17LDe3y FMj8UPImHdZM7iSr9ifQg6FxRX13UhQ= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-397-DFbDbv7nOoe9CQ3GS_D1IA-1; Fri, 20 Jan 2023 09:23:24 -0500 X-MC-Unique: DFbDbv7nOoe9CQ3GS_D1IA-1 Received: by mail-lf1-f69.google.com with SMTP id o16-20020ac24950000000b004d5811430c3so2536877lfi.7 for ; Fri, 20 Jan 2023 06:23:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2wN8N4AUyw8VuQ68b8rGeQkVhhCwe+4k4ByhDvL57HY=; b=sFlkcdUJBpa50ktghJ3atfWoROj72+z2Ch2OdF3RAs+UFhh7kyDyElHozAFfm6fdEe oY0HuNYzIJujnn36Iith/7l0nOfZj0zHh0Ek6em7po2mq+MmC/DjYp9PLsjK1QM9hBAS ODY9yaSPxzch+2HcBbOANiWGx76QBvx8dsDxrQkI4suRrJxa7AP1zzuwIxQkmyU0sFIv fRsFWQ5LJ0JrdhwaIpSUygQJ7idgVjlOVrRShDUKV+CfwNoWtOpTqRt8MvOHpB0maOMX h/THedDaJYDbA6xOw4K5pj/Tq0XUCUTy7kgCs1S3lkQLAdI4ZbZ8PbG34TlF6s1EAsK8 0Frg== X-Gm-Message-State: AFqh2kpntZWHXdWJ9gduo21oAFGZkSUkamJprkv9isqF89bDciBGMZfh fP7D1bvzl5OW5s+KoL/b6Zj1eLAlsW1yJmGmCtvmuUsR5rOqG/F07KgNCJquy1AfXrD6fpMcKvx 7neDTqrnMizDJcadtvWqX5HlNLTeCD0I= X-Received: by 2002:a05:6512:3c8f:b0:4b0:65b0:7f30 with SMTP id h15-20020a0565123c8f00b004b065b07f30mr803638lfv.385.1674224602235; Fri, 20 Jan 2023 06:23:22 -0800 (PST) X-Google-Smtp-Source: AMrXdXvXQgB3EGDvG168nD3lrjBsQ5pJfpqF7Ap0a4cXMFgPTt+z1npLECDmyZ9qynT0vVkfkoLFCEpe2oHeg6j0vUQ= X-Received: by 2002:a05:6512:3c8f:b0:4b0:65b0:7f30 with SMTP id h15-20020a0565123c8f00b004b065b07f30mr803636lfv.385.1674224601890; Fri, 20 Jan 2023 06:23:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Fri, 20 Jan 2023 14:23:10 +0000 Message-ID: Subject: Re: Re: [committed] libstdc++: Allow Clang to use before C++23 To: Alexander Hans Cc: "libstdc++" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 4 Jan 2023 at 21:07, Alexander Hans wrote: > > Hi, > > Thanks for your prompt reply. Now things are much clearer! > > > > Then Bazel is broken. The assumption that "there are no name clashes > > between C++ and C header files" has never been true. > > > I suppose we could support that silliness like this: > > [...] > > But I don't really like having to patch libstdc++ to support broken tools. > > I agree that libstdc++ is not the right place to fix this. But thanks for the > patch in any case, that's better than my unconditional #else and I'll keep > it in mind. That would also allow me to work around the issue. I did post a slightly tweaked version of that patch for review: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609833.html (I forgot that this discussion had been on the mailing list, not a private email, sorry!) I didn't get any feedback, positive or negative. > Regarding your question why this happens in the first place: > > > Why does Bazel even need to know those directories? It should not be > > adding them for compiling C code nor for compiling C++ code, because > > GCC does that automatically (and gets it right). > > Bazel can detect a local toolchain and use it. Then everything works as > expected. But it can also support some other toolchain, contained in some > archive you tell it to download from somewhere. I'm trying to integrate > gcc 12 via this route and do this based on some existing Bazel rules that are > pretty close to what I need [1]. They call gcc passing -nostdinc and giving > the include directories via -isystem arguments. However, some preliminary > testing suggests you should actually use only --sysroot for that and avoid > -nostdinc and any extra -isystem arguments. If that's true, Yes, I do think that's true. The GCC you unpack from the archive is "relocatable" in that you can place the files anywhere, and gcc and g++ will determine where to find their own headers relative to the location of the gcc and g++ binaries. So as long as you maintain the directory structure, you can relocate the entire installation tree to another directory. GCC can't know where to find libc and other headers that are not part of the GCC installation, which is what --sysroot is used for (if you don't want it to use the default system headers in /usr/include etc.) But for GCC's own headers that are part of the GCC installation, it does the right thing automatically. You break that by using -nostdinc and then adding an incorrect set of directories back again using -isystem. > the fix should > happen in the gcc toolchain-specific Bazel rules. The section I quoted > about the cxx_builtin_include_directories parameter and the assumption > that there are no name clashes is probably not an issue: I believe this > is only about telling Bazel where those files live, so that it can make them > available (Bazel is all about hermetic builds and to that end it wants to > know exactly what is used for the build). Using --sysroot, they will be > made available for C compilations as well, but ignored as you explained. > The only unclean part about this is that we cannot tell Bazel which > toolchain-supplied files a C-only build depends on (it will always be both, > C and C++ files), but that is acceptable. OK, I'm glad you got it working. I'm not seeing much motivation to push the patched linked above, but on the other hand it doesn't do any harm either.