On 03/10/18 05:58, Richard Purdie wrote:
On Thu, 2018-09-27 at 12:18 +1200, Douglas Royds wrote:When I build glibc in two different places, I get non-reproducible results - a 4-byte difference:$ cmp -l ~/workspace/upstream[12]/build/tmp/work/armv5e-tait-linux- gnueabi/glibc/2.28-r0/package/lib/libc-2.28.so 1259181 71 172 1259182 27 304 1259183 152 77 1259184 363 243These 4 bytes are the checksum that objcopy --add-gnu-debuglink adds to the binary when the .debug info is split out at do_package time, see package.bbclass +416 So why is the debug info different? We add -fdebug-prefix-map to our CFLAGS, which ensures that all our intra-component debug paths are prefixed with /usr/src/debug/glibc/, for instance, but this isn't working in this case. The difference is happening in csu/crt1.o, which is being linked into libc.so (and others):$ ../recipe-sysroot-native/usr/bin/arm-tait-linux-gnueabi/arm-tait- linux-gnueabi-objdump -t csu/crt1.o ... 00000000 l df *ABS* 00000000 /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux- gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/abi-note.o 00000000 l df *ABS* 00000000 /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux- gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/start.oThis abi-note.o symbol is finding its way into libc.so:$ ../recipe-sysroot-native/usr/bin/arm-tait-linux-gnueabi/arm-tait- linux-gnueabi-objdump -t libc.so ... 00000000 l df *ABS* 00000000 /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux- gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/abi-note.o
No it isn't, it turns out. The non-reproducibility of crt1.o and
friends is a problem, as they get copied into the recipe-sysroot
of all other components, causing the 780ish different packages
observed by Juro in https://bugzilla.yoctoproject.org/show_bug.cgi?id=12743
There is a work-around: turn off the debug packaging:INHIBIT_PACKAGE_DEBUG_SPLIT_pn-glibc = "1"I don't have a solution for this. Suggestions?I did some digging. I tried what I suggested using relative paths: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=22189be4bf508851950f72654870c4eebd4b73d9 and whilst it helps remove some references, there is a much wider problem. I therefore went and had a look at the linker itself to understand why its injecting this path. I found this code: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=f9aca51204990fbdbdfa7442f1dcc938e97bf782 which if disabled as per this hack, makes the binaries reproducible and drops the problematic references. We're swapping some misleading debug output for reproducibility with that hack. At this point we probably need to talk to some toolchain people about what 'real' fixes may be possible...
$ ../recipe-sysroot-native/usr/bin/arm-tait-linux-gnueabi/arm-tait-linux-gnueabi-objdump -t math/libm.so | grep armv5e
00000000 l df *ABS* 00000000 /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/abi-note.o
00000000 l df *ABS* 00000000 /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/crti.o
00000000 l df *ABS* 00000000 /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/crtn.o
From temp/log.do_compile:
This link command ignores -fdebug-prefix-map even if we add it (ld doesn't accept it). The fully-qualified paths to crti.o and crtn.o come from the -B option. If we use relative paths to these files and to abi-note.o, the problem goes away:arm-tait-linux-gnueabi-gcc
-march=armv5e -marm
...
-B/home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/
...
-o /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/math/libm.so
...
/home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/abi-note.o
...
$ cd git/math/Make is invoked from the build-arm-tait-linux-gnueabi/ directory, whose Makefile recursively invokes the Makefile in ../git/, passing in a fully-qualified "objdir":
$ arm-tait-linux-gnueabi-gcc \
-march=armv5e -marm \
...
-B../../build-arm-tait-linux-gnueabi/csu/ \
...
-o /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/math/libm.so \
...
../../build-arm-tait-linux-gnueabi/csu/abi-note.o \
...
$ cd ../../build-arm-tait-linux-gnueabi/
$ ../recipe-sysroot-native/usr/bin/arm-tait-linux-gnueabi/arm-tait-linux-gnueabi-objdump -t math/libm.so | grep csu
00000000 l df *ABS* 00000000 ../../build-arm-tait-linux-gnueabi/csu/abi-note.o
00000000 l df *ABS* 00000000 ../../build-arm-tait-linux-gnueabi/csu/crti.o
00000000 l df *ABS* 00000000 ../../build-arm-tait-linux-gnueabi/csu/crtn.o
all .DEFAULT:Unfortunately, the makefiles are written on the assumption that the objdir is fully-qualified, so simply hacking this line doesn't work.
$(MAKE) -r PARALLELMFLAGS="$(PARALLELMFLAGS)" -C $(srcdir) objdir=`pwd` $@
$(extra-B-$(@F:lib%.so=%).so) -B$(csu-objpfx) \I added "realpath" to the HOSTTOOLS, and precomputed a relative path to the csu/ dir in git/Makerules.
...
$(csu-objpfx)abi-note.o $(build-shlib-objlist)
csu-objpfx-relative = $(shell realpath --relative-to=`pwd` $(csu-objpfx))/Seems to do the trick. I'll send a patch(ish) separately.