This is an archive of the discontinued LLVM Phabricator instance.

[libc++][release] Do not force building the runtimes with -fPIC
ClosedPublic

Authored by ldionne on Sep 22 2021, 9:26 AM.

Details

Summary

There's a lot of history behind this, so here's a summary:

  1. I stopped forcing -fPIC when building the runtimes in 30f305efe279, before the LLVM 9 release back in 2019.
  1. Someone complained that libc++.a couldn't be used in shared libraries built without -fPIC (http://llvm.org/PR43604) since the LLVM 9 release. This had been caused by my removal of -fPIC when building libc++.a in (1).
  1. I suggested two ways of fixing the issue, the first being to force -fPIC back unconditionally (http://llvm.org/D104328), and the second being to specify that option explicitly when building the LLVM release (http://llvm.org/D104327). We converged on the first solution.
  1. I landed D104328, which forced building the runtimes with -fPIC. This was included in the LLVM 13.0 release.
  1. People complained about that and requested that we be able to customize this setting (basically we should have done the second solution).

This patch makes it such that the LLVM release script will specifically
ask for building with -fPIC using CMAKE_POSITION_INDEPENDENT_CODE,
however by default the runtimes will not force that option onto users.

This patch has the unintended effect that Clang and the LLVM libraries
(not only the runtime ones like libc++) will also be built with -fPIC
in the release. It would be better if we could specify that -fPIC is to
be used only when building the runtimes, however this is left as a
future improvement. The release should probably be using a bootstrapping
build and passing those options to the stage that builds the runtimes
only, see https://reviews.llvm.org/D112748 for that change.

Diff Detail

Event Timeline

ldionne created this revision.Sep 22 2021, 9:26 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 22 2021, 9:26 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
ldionne requested review of this revision.Sep 22 2021, 9:26 AM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptSep 22 2021, 9:26 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript

Adding relevant people from my team.

I fear that while this change may make people from point 5 happy, it will add a point 6 to the summary where people are unhappy about the default ABI change.

At a glance, this does resolve our team's current (potentially artificial) issues with the PIC default. Our linker is very particular about what it allows to be interlinked. PIC vs non-PIC is one of the qualities tested.

MaskRay accepted this revision.EditedSep 22 2021, 10:25 AM

(On ELF, shared objects (-shared) needs -fPIC code; PIE executable needs -fPIE or -fPIC code; position-dependent executable accepts any of -fno-PIC/-fPIE/-fPIC.)

LLVM_ENABLE_PIC (default) adds -fPIC. -DCMAKE_POSITION_INDEPENDENT_CODE=ON adds a duplicated -fPIC.

Someone complained that libc++.a couldn't be used in shared libraries built without -fPIC (http://llvm.org/PR43604) since the LLVM 9 release.

I believe this was due to they doing a standalone libc++ build (cmake -Hlibcxx -Bout instead of cmake -Hllvm -Bout), so they did not receive -fPIC from LLVM_ENABLE_PIC.
It was a user configuration problem. They should express the PIC intention through CMAKE_POSITION_INDEPENDENT_CODE=on in the absence of LLVM_ENABLE_PIC=on.

As-is, this patch will have the unintended effect that Clang and the LLVM libraries (not only the runtime ones like libc++) will also be built with -fPIC in the release.

I think there is no difference in the build output, just one -fPIC now becoming two -fPIC in the compiler options :)


Setting -DCMAKE_POSITION_INDEPENDENT_CODE=ON looks good to me.
We may be able to drop LLVM_ENABLE_PIC in favor of the standard CMake variable.

Adding relevant people from my team.

I fear that while this change may make people from point 5 happy, it will add a point 6 to the summary where people are unhappy about the default ABI change.

FWIW, we've had that ABI (no -fPIC by default) since LLVM 9. We changed it back to having -fPIC by default in LLVM 13 (which is being released right now). If this goes through, I would cherry-pick this on the LLVM 13 release branch ASAP so that we don't flip-flop our users too much.

@chandlerc Would you be able to provide a reproducer for the testing you were doing in http://llvm.org/PR43604? I tried naively installing LLVM on a Ubuntu Docker image to repro what you were seeing and confirm that this patch solved it, but I got some bogus test.cpp:1:10: fatal error: 'iostream' file not found error, so I'm doing something wrong.

ldionne updated this revision to Diff 385803.Nov 9 2021, 6:50 AM

Rebase onto main. Gentle ping, I do not know how to verify that this is going to fix the
issues that people were seeing.

As-is, this patch will have the unintended effect that Clang and the
LLVM libraries (not only the runtime ones like libc++) will also be
built with -fPIC in the release.

Do you mean that specifying LLVM_ENABLE_RUNTIMES at configure-time causes both llvm/clang and the enabled runtimes (libc++, libc++abi, libunwind, etc) to use the same PIC selection?
The runtimes have a way to use their own configuration. Prefixing a variable with RUNTIMES_ or BUILTINS_ sends that variable to the runtime/builtins build, overwriting the one used to configure LLVM.

https://github.com/llvm/llvm-project/blob/7562c64197acbee60c4bb0d211eb699ad24f5bb8/llvm/runtimes/CMakeLists.txt#L308

MaskRay accepted this revision.Nov 26 2021, 1:45 PM

Still LGTM. I am pretty sure some people found issues because they or their distributions incorrectly specified -DLLVM_ENABLE_PIC=off (default is on).

ldionne updated this revision to Diff 390353.Nov 29 2021, 7:28 AM
ldionne edited the summary of this revision. (Show Details)

Rebase onto main and update documentation for enabling PIC with the bootstrapping build.

ldionne updated this revision to Diff 392124.Dec 6 2021, 10:46 AM

Hopefully fix the CI

ldionne updated this revision to Diff 392549.Dec 7 2021, 2:50 PM

Rebase onto main -- this should fix CI.

ldionne accepted this revision.Dec 8 2021, 5:31 AM
ldionne added a reviewer: tstellar.
ldionne added a subscriber: tstellar.

CI is green for libc++. I want to ship this but I'd like to have @tstellar's approval before I do because I am modifying test-release.sh.

This revision is now accepted and ready to land.Dec 8 2021, 5:31 AM
tstellar accepted this revision.Dec 8 2021, 8:11 AM

LGTM.

This revision was landed with ongoing or failed builds.Dec 8 2021, 8:35 AM
This revision was automatically updated to reflect the committed changes.