Bug 2061010

Description of problem:
Shared objects provided by devtoolset-10-elfutils-devel are built without -fPIC


Version-Release number of selected component (if applicable):
devtoolset-10-elfutils-devel-0.182-3.el7.x86_64


How reproducible:
Always.


Steps to Reproduce:
Try to build dwarves-1.21 against devtoolset-10. The build fails when the linker tries to created shared object libdwarves.so.1.0.0 and encounters R_X86_64_32S relocations in libdw:

Linking C shared library libdwarves.so
/usr/bin/cmake -E cmake_link_script CMakeFiles/dwarves.dir/link.txt --verbose=1
/opt/rh/devtoolset-10/root/usr/bin/cc  -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -DCOMPAT_NEED_REALLOCARRAY -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -O2  -Wl,-z,relro  -shared -Wl,-soname,libdwarves.so.1 -o libdwarves.so.1.0.0 CMakeFiles/dwarves.dir/dwarves.c.o CMakeFiles/dwarves.dir/dwarves_fprintf.c.o CMakeFiles/dwarves.dir/gobuffer.c.o CMakeFiles/dwarves.dir/strings.c.o CMakeFiles/dwarves.dir/ctf_encoder.c.o CMakeFiles/dwarves.dir/ctf_loader.c.o CMakeFiles/dwarves.dir/libctf.c.o CMakeFiles/dwarves.dir/btf_encoder.c.o CMakeFiles/dwarves.dir/btf_loader.c.o CMakeFiles/dwarves.dir/libbtf.c.o CMakeFiles/dwarves.dir/dwarf_loader.c.o CMakeFiles/dwarves.dir/dutil.c.o CMakeFiles/dwarves.dir/elf_symtab.c.o CMakeFiles/dwarves.dir/rbtree.c.o CMakeFiles/bpf.dir/lib/bpf/src/bpf_prog_linfo.c.o CMakeFiles/bpf.dir/lib/bpf/src/bpf.c.o CMakeFiles/bpf.dir/lib/bpf/src/libbpf_errno.c.o CMakeFiles/bpf.dir/lib/bpf/src/btf.c.o CMakeFiles/bpf.dir/lib/bpf/src/str_error.c.o CMakeFiles/bpf.dir/lib/bpf/src/ringbuf.c.o CMakeFiles/bpf.dir/lib/bpf/src/libbpf.c.o CMakeFiles/bpf.dir/lib/bpf/src/xsk.c.o CMakeFiles/bpf.dir/lib/bpf/src/netlink.c.o CMakeFiles/bpf.dir/lib/bpf/src/btf_dump.c.o CMakeFiles/bpf.dir/lib/bpf/src/nlattr.c.o CMakeFiles/bpf.dir/lib/bpf/src/hashmap.c.o CMakeFiles/bpf.dir/lib/bpf/src/libbpf_probes.c.o -ldw -lelf -lz 
/opt/rh/devtoolset-10/root/usr/libexec/gcc/x86_64-redhat-linux/10/ld: /opt/rh/devtoolset-10/root/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/libdw.ar(i386_disasm.o): relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/opt/rh/devtoolset-10/root/usr/libexec/gcc/x86_64-redhat-linux/10/ld: /opt/rh/devtoolset-10/root/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/libdw.ar(x86_64_disasm.o): relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/opt/rh/devtoolset-10/root/usr/libexec/gcc/x86_64-redhat-linux/10/ld: /opt/rh/devtoolset-10/root/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/libdw.ar(bpf_disasm.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/dwarves.dir/build.make:446: libdwarves.so.1.0.0] Error 1
make[2]: Leaving directory '/spare/tmp/ion/BUILD/dwarves-1.21'
make[1]: *** [CMakeFiles/Makefile2:209: CMakeFiles/dwarves.dir/all] Error 2


Additional info:
An analysis of the elftools build process shows that it creates both a libdw.a without -fPIC and a libdw.so with -fPIC, but the devtoolset-10 rpm spec file replaces libdw.so with a linker script pointing to libdw.a (renamed as libdw.ar).

Incidentally, the DTS-[89] versions of elfutils are fine, while the DTS-11 version has the same problem described above. I didn't look very closely into it, but the little I did leads to me to believe the DTS-[89] versions are fine only because their build process uses -fPIC for everything. I could have gotten a few details wrong, though; again, I didn't spend a lot of time on it.

It's also easy enough to check the libraries with objdump. For the DTS-9 version, objdump -x libdw.a | grep R_X86_64_32 | grep rodata is clean (no output). For DTS-10 it matches a ton of symbols.