From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 1F2253858D28 for ; Sun, 5 Dec 2021 11:43:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F2253858D28 Received: by mail-wr1-x42c.google.com with SMTP id o13so16094202wrs.12 for ; Sun, 05 Dec 2021 03:43:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=qQAxZlnkaV9NsJ159c2bnhQS0EzUuZtsq00ujUqQVlE=; b=T2GtSP4IGHOjGUFCwWQVAzxc3MSgPFmyQR/dTCeejoZ29GuXt+6mSHEu1NPtafngqt YRLqd9x5fLSln6HW2i+hFpjZJi4YZ7qM1y82LDYA9gCq0vJ5DxwICMkF1OB1JFqjX6ZV TuzrTN+1oACSWLv8lDhem5LOEpsOtk7thYdmlD2G4zR5hXlPxIhiDe9kZSFsXe2NSEyW Xlow8q7sFcpBcMDWBORxIKEkuiHnHF+ybx1HzsWN/1PxfNwiWvUJeNgJDmW9NA1f2xIt xaBMaIeGihgmtXHpTlddoHo4Y8HxnE0MfbvZnPKlRc+1E566GS6jJMiJ6RhjYvL35dh8 aTIw== X-Gm-Message-State: AOAM531xwDvE2gx+d6vTl1OGlfmccVhdJCGotDdgXkn6DqEW3qU4K1mp 3eYt03zHkQLl8TsNfJfSbezZWw== X-Google-Smtp-Source: ABdhPJwT3+8JChYGAe3KfmcFodEA5ZZQSIQ64PI3ax8R7u4NzXuDNoizCAsTMROLFvB8/D8nvvYCSw== X-Received: by 2002:a05:6000:1141:: with SMTP id d1mr34969218wrx.342.1638704596121; Sun, 05 Dec 2021 03:43:16 -0800 (PST) Received: from ?IPv6:2001:8b0:aba:5f3c:685e:e95e:8e62:a31c? ([2001:8b0:aba:5f3c:685e:e95e:8e62:a31c]) by smtp.gmail.com with ESMTPSA id s24sm7584043wmj.26.2021.12.05.03.43.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Dec 2021 03:43:15 -0800 (PST) Message-ID: <1ade3c35a1d8c354cc00a81f8c95b1ecf1e3d37d.camel@linuxfoundation.org> Subject: Re: [PATCH 3/5] gcc: Add --nostdlib++ option From: Richard Purdie To: Jeff Law , gcc-patches@gcc.gnu.org Date: Sun, 05 Dec 2021 11:43:13 +0000 In-Reply-To: References: <20211027200505.3340725-1-richard.purdie@linuxfoundation.org> <20211027200505.3340725-4-richard.purdie@linuxfoundation.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2021 11:43:19 -0000 On Thu, 2021-12-02 at 20:04 -0700, Jeff Law wrote: > > On 10/28/2021 10:39 AM, Richard Purdie wrote: > > On Thu, 2021-10-28 at 08:51 -0600, Jeff Law wrote: > > > On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote: > > > > OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries > > > > separately from the compiler and slightly differently to the standard gcc build. > > > > > > > > In general this works well but in trying to build them separately we run into > > > > an issue since we're using our gcc, not xgcc and there is no way to tell configure > > > > to use libgcc but not look for libstdc++. > > > > > > > > This adds such an option allowing such configurations to work. > > > > > > > > 2021-10-26 Richard Purdie > > > > > > > > gcc/c-family/ChangeLog: > > > > > > > > * c.opt: Add --nostdlib++ option > > > > > > > > gcc/cp/ChangeLog: > > > > > > > > * g++spec.c (lang_specific_driver): Add --nostdlib++ option > > > > > > > > gcc/ChangeLog: > > > > > > > > * doc/invoke.texi: Document --nostdlib++ option > > > > * gcc.c: Add --nostdlib++ option > > > Couldn't you use -nostdlib then explicitly add -lgcc? > > > > > > If that works, that would seem better to me compared to adding an option > > > to specs processing that is really only useful to one build > > > system/procedure. > > It sounds great in principle but I've never been able to get it to work. With > > "-nostdinc++ -nostdlib" I miss the startup files so I also tried "-nostdinc++ - > > nodefaultlibs -lgcc". The latter gets further and I can build libstdc++ but the > > resulting library doesn't link into applications correctly. > Can you be more specific about "doesn't link into applications > correctly".  I'm still hesitant to add another option if we can > reasonably avoid it. I took a step back and had another look at what our build is doing and why we need this. Our build builds the different components separately in many cases so libstdc++ is built separately since that allows us to tune it to specific targets whilst the core gcc is architecture specific. When we run configure for libstdc++, we have to configure CXX. We can configure it as: CXX="${HOST_PREFIX}g++ -nostdinc++" however that gives errors about a missing libstdc++ during configure tests (e.g. the atomic ones) since the library isn't present yet and we're trying to build it. When I last ran into this I added the nostdlib++ option to mirror the stdinc++ one and this solved the problem. Adding -lgcc doesn't seem to work, binaries using libstdc++ segfault on some architectures (mips64 and ppc). I suspect this is a link ordering issue which we have little control of from the CXX variable but I haven't got deeply into it as I got the feeling it would be a pain to try and correct, we need the compiler's automatic linking behaviour which you can't emulate from one commandline. I did also try -nostdlib and -nodefaultlibs with various libraries added in but it never seems to work well giving segfaults, again as I suspect the linking is order specific. Thinking about the problem from scratch again, I wondered if a dummy libstdc++ would be enough to make the configure tests work correctly. I've found that I can do something like: mkdir -p XXX/dummylib touch XXX/dummylib/libstdc++.so export CXX="${CXX} -nostdinc++ -LXXX/dummylib" and the configure works correctly and the resulting libs don't segfault on target. This is a bit of a hack but probably no worse than some of the other things we have to do to build so if you're not keen on the patch we could go with this. It did seem at least worth discussing our use case though! :) Cheers, Richard