From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id E66793846400 for ; Wed, 3 Apr 2024 13:05:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E66793846400 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E66793846400 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::52b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712149529; cv=none; b=DiiPGbxsPm8AjqBSn1DU1e6YsoPv7Vtbj0QuRda4xcDUAfNlAbNMH5uMDwyB0b6b9F0YD06coI73ArQZbosSDJ99h3qs1Iryety6rRz2cC1xN6FkJjCysdfRJAqoe+x7Y8n16YI0XrNqzWId7yFer3bwgm/HSImQP7kXUEj43dA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712149529; c=relaxed/simple; bh=x6nuVW0qAOLi2sAHKqTBAE5hE/gS2SdBM3n//roVUI4=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=H30RVnmbXkAY5/fhnHYasIPjwNXcAM+YTPJ73zJNsCBsUnF+/aXY5hGCFJpMhjFA9HvHtwJGFADVhBDJXcN0vgi4Nv6TKZwzEQkQmFovrd46lf4z6pL5Jq3QSQAL6OBeieFo9m1/+SVJP1CBBvgXjz4mHg8hy/JqWB8D6vEb9qc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-565c6cf4819so1641018a12.1 for ; Wed, 03 Apr 2024 06:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712149524; x=1712754324; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qLnVaN71Vz99o6vdCf3+ZZyJsqcRGh9CxwBMmhKaK7Q=; b=kbce7qFPX8Gxr00xrzr0/8i39QfKFxyPQNmaydBsUzBzGQXPQIQfcTKeLVFQ2LnVl5 KlVgWRbwR7ontctotrdo8XcMqFkS6SlQE4Drq9whv4DuEoTEKjpAHtR0AJYOYPDZDrSM 1f/uRmvKZ2qlhTLgJAKJCU36GQ96RfIhmzc9n75RNrbChXEis5HxrIQZ0QUaeAEY9n6V YZeYgbB56OVh31rUAGd6qpXB7EMmbqjsEeVTzgZ9ledGWgWFnsz04hfxWgL0H34BilL7 Uv6hrEnvYGeByrvJGMqSa6noRGm24QtiN7Wlseu+YNeEao02JzQ/WV+J7ibJE1x+oDaa x3rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712149524; x=1712754324; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qLnVaN71Vz99o6vdCf3+ZZyJsqcRGh9CxwBMmhKaK7Q=; b=lofOCOs2js1OGXFTj0jB9e1AZ5Y+mtd1ahYZAjQfzto0ew39L8KbRmkM7G6lHBdXqN beZ7l7PWO+Xnn4FssWugFaNnxpGXKsESgoom/Xnnrz7Fzy7r1uQN4alyTNhkBFORdu4f NBudmkHUq0D2UTAl9x/39LU7Zzp6Ivwts86acUXrsV5nBnL+5IjY4QUyMo+AXHbkXBJY pOaY4KYT3S/kLj6FX3zSvHUi5l/+COuWFkrSg9rCT8JVIBGWQvcvvcF3rgv/gZZI/2o9 vE8c97TToWK6bIH+9DUX/Z+lwPGFLMMGHS1Qpp853TffrC9xiE0sUN58r4UCuJIebxOr VgBw== X-Gm-Message-State: AOJu0Yx/P2qOsZX8Zyv8GVy8wHdl53ir9JNPw9noCwLiv3xmWhHZJwML UD/jWqoCdVNqGm++MvBbm4IlrRkmQqZ/Tt2e0WnY9bCtpXM/dxPaVEpkTawKnKNlRG311d4Lq+8 brzW5I3nXlG+kvJBaZI0ZJ6YZkTd2aD7kXNSoGA== X-Google-Smtp-Source: AGHT+IFZdTjq3+Hw+3189cRqKnF8RToFZ1DuSs+q7fCRuxNLnrCmyS+fj+KAbx0KA9vas8aBV4eKfMKfmpVAejlv58g= X-Received: by 2002:a17:906:e0d0:b0:a4e:4981:d3fb with SMTP id gl16-20020a170906e0d000b00a4e4981d3fbmr2180984ejb.29.1712149524100; Wed, 03 Apr 2024 06:05:24 -0700 (PDT) MIME-Version: 1.0 References: <475e64e4-c6c4-4d12-9550-7193ce0d91c8@app.fastmail.com> In-Reply-To: <475e64e4-c6c4-4d12-9550-7193ce0d91c8@app.fastmail.com> From: Jonathan Wakely Date: Wed, 3 Apr 2024 14:05:11 +0100 Message-ID: Subject: Re: Multiple libstdc++ builds To: John F Cc: gcc-help Content-Type: multipart/alternative; boundary="0000000000002fc21a061530e008" X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000002fc21a061530e008 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 3 Apr 2024, 12:36 John F via Gcc-help, wrote: > Hello, > > I=E2=80=99m building GCC from a release branch (13.2.0). For the majority= of > things I=E2=80=99m trying to compile, I want to produce static + lto=E2= =80=99d binaries, > linking the c++ lib in statically via the typical -static-libstdc++. So I > initially configured gcc with =E2=80=94disable-shared and everything seem= ed to work > just fine. > > There are a few things though that I need to build dynamically. In the > past, I configured with =E2=80=94with-pic, but I wanted to avoid paying t= he PIC tax > for my true static links. So I rebuilt gcc without =E2=80=94disable-share= d. 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=E2=80=99t 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=E2=80=99t 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 b= ut > 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. --0000000000002fc21a061530e008--