Re: Multiple libstdc++ builds

[Jonathan Wakely <jwakely.gcc@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]

On Wed, 3 Apr 2024, 12:36 John F via Gcc-help, <gcc-help@gcc.gnu.org> wrote:

> 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?




It's doable but I don't remember the incantation off the top of my head.
Some users want to link libstdc++.a into their own .so and doing that needs
the .a to be built with PIC. The default build supports that and most users
who are just using the .a directly via static linking will never notice any
overhead from PIC.


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

Not easily, no.

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.


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


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.