public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
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!




             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).