Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[John David Anglin]

On 2018-09-23 4:56 PM, Michael Biebl wrote:
> Am 23.09.18 um 22:44 schrieb Michael Biebl:
>> Looking at the "ld" man page, it doesn't say anything about -fPIE, only
>> about -pie.
>> Can you please provide some references why on hppa the linker needs
>> -fPIE in addition to -pie
> Fwiw, this command succeeded for 239-7
>
> [425/1545] cc  -o src/udev/ata_id
> 'src/udev/src at udev@@ata_id at exe/ata_id_ata_id.c.o' -flto
> -Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie
> -Wl,--gc-sections -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -Wformat
> -Werror=format-security -Wl,--start-group src/udev/libudev_static.a
> src/shared/libsystemd-shared-239.a src/libsystemd/libsystemd_static.a
> src/basic/libbasic.a src/udev/libudev-basic.a -lrt
> /usr/lib/hppa-linux-gnu/libcap.so -lacl
> /usr/lib/hppa-linux-gnu/libcryptsetup.so -lgcrypt
> /usr/lib/hppa-linux-gnu/libip4tc.so /usr/lib/hppa-linux-gnu/libip6tc.so
> /usr/lib/hppa-linux-gnu/libselinux.so /usr/lib/hppa-linux-gnu/libidn.so
> /usr/lib/hppa-linux-gnu/liblzma.so /usr/lib/hppa-linux-gnu/liblz4.so
> /usr/lib/hppa-linux-gnu/libblkid.so -lrt
> /usr/lib/hppa-linux-gnu/libmount.so -Wl,--end-group
>
> Why is this now suddenly failing on hppa?
This is difficult to say as it's no longer possible to redo the 239-7 
without the exact same library
versions.  The meson package is now updated in sid.

Here is the gcc documentation for -flto:

@item -flto[=@var{n}]
@opindex flto
This option runs the standard link-time optimizer.  When invoked
with source code, it generates GIMPLE (one of GCC's internal
representations) and writes it to special ELF sections in the object
file.  When the object files are linked together, all the function
bodies are read from these ELF sections and instantiated as if they
had been part of the same translation unit.

To use the link-time optimizer, @option{-flto} and optimization
options should be specified at compile time and during the final link.
*It is recommended that you compile all the files participating in the**
**same link with the same options and also specify those options at**
**link time.*
For example:

@smallexample
gcc -c -O2 -flto foo.c
gcc -c -O2 -flto bar.c
gcc -o myprog -flto -O2 foo.o bar.o
@end smallexample

The first two invocations to GCC save a bytecode representation
of GIMPLE into special ELF sections inside @file{foo.o} and
@file{bar.o}.  The final invocation reads the GIMPLE bytecode from
@file{foo.o} and @file{bar.o}, merges the two files into a single
internal image, and compiles the result as usual.  Since both
@file{foo.o} and @file{bar.o} are merged into a single image, this
causes all the interprocedural analyses and optimizations in GCC to
work across the two files as if they were a single one.  This means,
for example, that the inliner is able to inline functions in
@file{bar.o} into functions in @file{foo.o} and vice-versa.

Another (simpler) way to enable link-time optimization is:

@smallexample
gcc -o myprog -flto -O2 foo.c bar.c
@end smallexample

The above generates bytecode for @file{foo.c} and @file{bar.c},
merges them together into a single GIMPLE representation and optimizes
them as usual to produce @file{myprog}.

The only important thing to keep in mind is that to enable link-time
optimizations you need to use the GCC driver to perform the link step.
GCC then automatically performs link-time optimization if any of the
objects involved were compiled with the @option{-flto} command-line option.
You generally
should specify the optimization options to be used for link-time
optimization though GCC tries to be clever at guessing an
optimization level to use from the options used at compile time
if you fail to specify one at link time.  You can always override
the automatic decision to do link-time optimization
by passing @option{-fno-lto} to the link command.

To make whole program optimization effective, it is necessary to make
certain whole program assumptions.  The compiler needs to know
what functions and variables can be accessed by libraries and runtime
outside of the link-time optimized unit.  When supported by the linker,
the linker plugin (see @option{-fuse-linker-plugin}) passes information
to the compiler about used and externally visible symbols.  When
the linker plugin is not available, @option{-fwhole-program} should be
used to allow the compiler to make these assumptions, which leads
to more aggressive optimization decisions.

When @option{-fuse-linker-plugin} is not enabled, when a file is
compiled with @option{-flto}, the generated object file is larger than
a regular object file because it contains GIMPLE bytecodes and the usual
final code (see @option{-ffat-lto-objects}.  This means that
object files with LTO information can be linked as normal object
files; if @option{-fno-lto} is passed to the linker, no
interprocedural optimizations are applied.  Note that when
@option{-fno-fat-lto-objects} is enabled the compile stage is faster
but you cannot perform a regular, non-LTO link on them.

...

-- 
John David Anglin  dave.anglin at bell.net