Bug 2134146 - relocation R_X86_64_32S when mixing clang++ with gfortran
Summary: relocation R_X86_64_32S when mixing clang++ with gfortran
Alias: None
Product: Fedora
Classification: Fedora
Component: llvm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Tom Stellard
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2022-10-12 15:26 UTC by Christoph Junghans
Modified: 2022-10-18 14:23 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2022-10-17 13:52:32 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github kokkos ci-containers pull 28 0 None Merged Revert "CI: try never fedora version" 2022-10-12 15:28:16 UTC

Description Christoph Junghans 2022-10-12 15:26:36 UTC
Have a file 'hello.f90':
program hello
  print *, 'Hello, World!'
end program hello

and a file 'tools.cpp':
int yes() {
  return 0;

Building them into one executable leads to a linking error:
$ clang++ -c tools.cpp  -o tools.o
$ gfortran -c hello.f90 -o hello.o
$ clang++ -o hello tools.o hello.o -lgfortran
/usr/bin/ld: hello.o: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value

Originally I found this in https://github.com/kokkos/ci-containers/pull/28 and filed a CMake issue here: https://gitlab.kitware.com/cmake/cmake/-/issues/24051
but CMake's Brad King found that the underlying issue is that gfortran wasn't compiled with "--enable-default-pie". In F36 the above example works with errors.

Comment 1 Jakub Jelinek 2022-10-12 15:35:54 UTC
This is a user error.  If you want to make a PIE, you should request it explicitly (so link with -pie).

Comment 2 Florian Weimer 2022-10-12 15:49:28 UTC
No, this is an inconsistency between GCC and Clang that needs to be fixed. Either both should default to PIE, nor neither should.

Comment 3 Christoph Junghans 2022-10-12 15:52:12 UTC
I agree with Florian, we should make this consistent. Or patch CMake to take care of it.

Comment 4 Jakub Jelinek 2022-10-12 16:03:03 UTC
GCC is intentionally not configured with --enable-default-pie or similar significant behavior changing options by default, because then users simply have no idea what
the compiler will do, they can't rely on anything and so if they care, they need to disable or enable all these options explicitly.
While if the default isn't changing, they can rely on it, it isn't a moving target.
It is like all of sudden changing the default to be -O2 instead of -O0...
So not a GCC bug.

Comment 5 Christoph Junghans 2022-10-12 16:09:50 UTC
Why did it work on F36? Did the clang default change?

Comment 6 Jakub Jelinek 2022-10-12 16:33:42 UTC
Most likely.

Note, not having -fpie for compiling and -pie for linking by default doesn't mean Fedora isn't built with PIE, the options are added explicitly in %{optflags} etc.

Comment 7 Timm Bäder 2022-10-13 06:16:47 UTC
Yes, clang's default changed to ON: https://releases.llvm.org/15.0.0/tools/clang/docs/ReleaseNotes.html#build-system-changes and we don't set that option in the spec file.

Comment 8 Nikita Popov 2022-10-13 08:06:41 UTC
> Note, not having -fpie for compiling and -pie for linking by default doesn't mean Fedora isn't built with PIE, the options are added explicitly in %{optflags} etc.

This is true for GCC, but for clang only -fPIE gets added to CFLAGS, but not -pie to LDFLAGS (https://bugzilla.redhat.com/show_bug.cgi?id=2084460). I'm not really clear on why this is the case though.

The situation here is somewhat ugly because gcc and clang now have different upstream defaults (the bug for changing gcc defaults is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398, which makes the incorrect claim that Fedora already enables this by default -- I guess there is confusion there between enabling something for RPM packages, and enabling it for end users).

But anyway, given that GCC is the primary toolchain for Fedora, we should follow whatever it does, so I've put up https://src.fedoraproject.org/rpms/clang/pull-request/183.

Comment 9 Fedora Update System 2022-10-17 12:55:29 UTC
FEDORA-2022-7011f92b71 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7011f92b71

Comment 10 Fedora Update System 2022-10-17 13:52:32 UTC
FEDORA-2022-7011f92b71 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 11 Nikita Popov 2022-10-18 14:23:55 UTC
Update for f37: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9dcdd39f09

Note You need to log in before you can comment on or make changes to this bug.