From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wfout1-smtp.messagingengine.com (wfout1-smtp.messagingengine.com [64.147.123.144]) by sourceware.org (Postfix) with ESMTPS id 961C23858D28 for ; Mon, 8 Apr 2024 21:33:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 961C23858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=tower89.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tower89.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 961C23858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=64.147.123.144 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712611992; cv=none; b=n85N7F9nD+ichR4sc3cDgaauKsnUq+qKAkkSZdWRsEJPAQsbSEOxPrq1u4xjWqyJEUS2P6L0a3Z+Q1ZjRhlLqzJAi6p+9hFHorYBGOrNk2NmSgHkUdrogXAVUiqPI9pRhIbTH2ntebniQ5DU3quilw7/6P8PZ/RDayh0tTmfMak= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712611992; c=relaxed/simple; bh=DXx5PfY9zwspI7Dz2ts+6P67gvH5klS+ZPBsqpcN1ao=; h=DKIM-Signature:DKIM-Signature:MIME-Version:Message-Id:Date:From: To:Subject; b=aMysZP0ixjS/+4YtVagTRIMqwbHj5EHeot4UEOPwxUjlljaRY0zC+WIJTZsI8bU7K7D8R1cQv34DtQ3SoqZjrMHDF1PAl4LFgOCe8FGQGBH8uIC/gog58AfU6f+eFRlO0Brifu1Y2dGliGgd3Dr27IgW4SZP7OaYM7SzBzP3n0k= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.west.internal (Postfix) with ESMTP id 928461C000E3; Mon, 8 Apr 2024 17:33:07 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute5.internal (MEProxy); Mon, 08 Apr 2024 17:33:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tower89.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1712611987; x=1712698387; bh=mjAiqcbJ3+ En1rEftInQ1eakphMY7FOc8S8Y+Re2A98=; b=cuS3qAqXkR2/UkB8YeF8zNR99w iC30LveToHhkdDQjOdrxQjHz+3irxAmYrgGEVzuCCGOkZ+F+Sr+B/gtBqe1BAbkQ 3dn3YA6NwLHtyQPmu453MEjtWm42PchaT5mBCHMRpSvdKhfIV409NnsFRNvswcvX bCNEbGoXNCD0fuDWuZjVLdG0lphgtvW5BIdh+fJ9NN6WRxUJ1CgIRnTC0krqhqNU X0jzewp1VD44laYJVzHV9ZrBN6p7kvU1gqDobOo7Gd1q7e77uYhCFrbhcQ0spBtx lVH5CkbTtNBc9gr20Ts/KG6kAlRxsob5q5u6azKDQRjDqEeXBswVyACtZJew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1712611987; x=1712698387; bh=mjAiqcbJ3+En1rEftInQ1eakphMY 7FOc8S8Y+Re2A98=; b=Hpd6Di+n58pyZiJ689PBgFTj17o1HEgdiwbY+ms5idGV mviK6lK3VXJqPfm8qMu6LE054qjQZKjLplgrXLbCGxlIp6Enw2VNBtEGAVenmUTS 2BzAOF96uePnMl+oxyzDXlrNKFlpcUYRw/erQ/iueOeZP+x3lLsF7O1abWloCWx/ DiHn0D22hunicBJc1SMqgWyTL6LRwr1aBJAIAN4W4t5wmmhVx8jkQpm/EMY+y+9y hwS5rXOx2WYPLzVg4hPygGzH8rqWiptHc60NjD6tki/S8gqi3D7bxGAM9DOrfPSP osTw0Hhs1T82NTrumch+SekTlfEP9HZKq6YKtuKnPQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudegiedgudeiudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvfevufgtse httdertderredtnecuhfhrohhmpedflfhohhhnucfhfdcuoehgtggthhgvlhhplhhishht sehtohifvghrkeelrdgtohhmqeenucggtffrrghtthgvrhhnpeetheegudfhtedujedtfe dtudevuedvvdelfeeludejteeiueeujeeguedvuefhieenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehgtggthhgvlhhplhhishhtsehtohifvg hrkeelrdgtohhm X-ME-Proxy: Feedback-ID: ic9b946e8:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9E55331A0065; Mon, 8 Apr 2024 17:33:06 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-368-gc733b1d8df-fm-20240402.001-gc733b1d8 MIME-Version: 1.0 Message-Id: <3ae1b3e6-bf12-4780-bad9-69ac3f2fabef@app.fastmail.com> In-Reply-To: References: <475e64e4-c6c4-4d12-9550-7193ce0d91c8@app.fastmail.com> Date: Mon, 08 Apr 2024 16:32:46 -0500 From: "John F" To: "Jonathan Wakely" Cc: gcc-help Subject: Re: Multiple libstdc++ builds Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,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, Apr 3, 2024, at 8:05 AM, Jonathan Wakely wrote: > TBH I'd just build GCC twice and copy the .a from one build into the installed tree from the other build (renaming it to _pic.a if desired). You could then use a spec file to select the right one based on other options such as -shared or -fPIC being used. Thanks for the advice. Very helpful. I was getting some spooky crashes in iostream code (segfault putting a uint16_t to cerr for example) that ended up being due to a different issue (a 3rd-party library pulling in the system libstdc++.so and that clashing with my static non-PIC build). Not sure if that's maybe supposed to work, but luckily I was able to recompile that library as well and sub in my build of libstdc++. Along the way to debugging that though, I diffed across the two gcc build tree and noticed some differences in bits/c++config.h diff -r include/c++/13.2.0/x86_64-pc-linux-gnu/bits/c++config.h include_pic/c++/13.2.0/x86_64-pc-linux-gnu/bits/c++config.h 973c973 < /* #undef _GLIBCXX_HAVE_EXCEPTION_PTR_SINCE_GCC46 */ --- > #define _GLIBCXX_HAVE_EXCEPTION_PTR_SINCE_GCC46 1 1296c1296 < /* #undef _GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT */ --- > #define _GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT 1 1762c1762 < /* #undef _GLIBCXX_SYMVER */ --- > #define _GLIBCXX_SYMVER 1 1768c1768 < /* #undef _GLIBCXX_SYMVER_GNU */ --- > #define _GLIBCXX_SYMVER_GNU 1 I think most of them end up being no-ops as far as the include headers, but there is a difference in whether _GLIBCXX_SYMVER_GNU is defined. And that one *is* used in the iostream header. // For construction of filebuffers for cout, cin, cerr, clog et. al. // When the init_priority attribute is usable, we do this initialization // in the compiled library instead (src/c++98/globals_io.cc). #if !(_GLIBCXX_USE_INIT_PRIORITY_ATTRIBUTE \ && __has_attribute(__init_priority__)) static ios_base::Init __ioinit; #elif defined(_GLIBCXX_SYMVER_GNU) __extension__ __asm (".globl _ZSt21ios_base_library_initv"); #endif So the libstdc++ headers are ultimately slightly sensitive to whether the library was built for shared or not. And it is an iostream initialization difference, so I may ultimately have been seeing a manifestation of a similar issue. Anyways, the point for anybody else who stumbles across this is that in addition to installing the pic build of the archive, it seemed like I *also* needed to install a separate copy of the headers to use with my pic builds (via --nostdinc++). > No, using LTO for libstdc++ is not possible. We rely on the compiler not being able to see past the boundary between translation units. It might be possible to disable LTO just for the relevant files, but somebody would have to do the work to determine which ones are the relevant ones. I'd be happy to help, though I can't say I understand what types of issues require avoiding cross-unit visibility.