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 -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
