[yocto] Setting LDFLAGS for all packages

Blaettler, Michael michael.blaettler at siemens.com
Tue Dec 12 02:07:35 PST 2017


Hello

The problem I'm currently facing is the removal (unset) of the LDFLAGS variable within the glibc compile step.

A bit of background information:
I'm working on reproducible builds and found one major problem which occurs by many of the packages. By default, the debug information is extracted from the build output and stored in a separate *-dbg package. GDB wants to do a matching before using a debug file for debugging. This matching is currently done by adding a debuglink to the binary. This link contains the filename and a CRC checksum of the corresponding debug file. Since the debug information is very specific, it's almost impossible to get them reproducible. In conclusion, the debuglink breaks reproducibility.
A short look into the gdb documentation (https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html) reveals another possibility to link a binary with its  debug information - the build-id. This build-id can either be generated by the linker or can be set to a fixed value. To ensure reproducibility, I hashed ${PF} in an anonymous-python function and passed the result to the build. In this case, I can guarantee a reproducible output as well as splitting debug information.

Long story short:
After first successful tests I decided to make my changes upstream, by introducing a new variable to specify the link style for debug files. Possible setting would be 'debuglink', 'build-id' and 'both'.
When using the debuglink option the flag "-build-id" must be passed to the linker. To have a reproducible glibc, it is not possible to set this flag in LDFLAGS, since this variable gets removed (unset) before compilation. The next idea was to pass it to TARGET_CC_ARCH. According to the documentation this is the way to deal with such an issue. But the next problem lured right there: libtool usese the "compiler call" to infer the build configuration. Since the build-id is now inside the "compiler call", it's not possible anymore for libtool to infer the configuration (the build id is different for every package).

Before the unset-command in the glibc recipe, there's the following comment:
"-Wl,-rpath-link <staging>/lib in LDFLAGS can cause breakage if another glibc is in staging"
Is this still required or is it a leftover from previous version where there weren't recipe specific sysrots?
If not, does anybody of you know, how I could set the flag without breaking libtool?

Thanks in advance

Michael



More information about the yocto mailing list