From: "John F" <gcchelplist@tower89.com>
To: gcc-help@gcc.gnu.org
Subject: Multiple libstdc++ builds
Date: Wed, 03 Apr 2024 13:34:55 +0200 [thread overview]
Message-ID: <475e64e4-c6c4-4d12-9550-7193ce0d91c8@app.fastmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
Hello,
I’m building GCC from a release branch (13.2.0). For the majority of things I’m trying to compile, I want to produce static + lto’d binaries, linking the c++ lib in statically via the typical -static-libstdc++. So I initially configured gcc with —disable-shared and everything seemed to work just fine.
There are a few things though that I need to build dynamically. In the past, I configured with —with-pic, but I wanted to avoid paying the PIC tax for my true static links. So I rebuilt gcc without —disable-shared. And again, everything works fine and now I can produce shared c++ libraries where I need.
But I noticed that now the libstdc++ components objects are again getting built with -fPIC -DPIC as far as I can tell. Not surprising but disappointing.
Which brings me to the question: is there a good way to produce the libstdc++.a and .so from separate compilations s.t. the objects in the archive don’t have -fPIC? Or, even better, produce both a libstdc++.a and a libstdc++_pic.a (assuming I can then link the latter via -nostdlib++ libstdc++_pic.a)? I tried to wrap my head around the build machinery, but couldn’t really make any progress.
Relatedly, can libstdc++.a practically be built with (fat) LTO support for non-cross builds? Bug 59893 discusses some issues with Canadian crosses but nothing for native and the discussion is largely from a decade ago.
Appreciate your time!
next reply other threads:[~2024-04-03 11:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-03 11:34 John F [this message]
2024-04-03 13:05 ` Jonathan Wakely
2024-04-08 21:32 ` John F
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=475e64e4-c6c4-4d12-9550-7193ce0d91c8@app.fastmail.com \
--to=gcchelplist@tower89.com \
--cc=gcc-help@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).