On Thu, 2018-09-27 at 12:18 +1200, Douglas Royds wrote: > > $ arm-tait-linux-gnueabi-gcc -march=armv5te -marm -mcpu=arm926ej-s > > --sysroot=/home/douglas/workspace/upstream1/build/tmp/work/armv5e- > > tait-linux-gnueabi/glibc/2.28-r0/recipe-sysroot -nostdlib > > -nostartfiles -r -o > > /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux- > > gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/crt1.o > > /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux- > > gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/start.o > > /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux- > > gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/abi-note.o > > /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux- > > gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/init.o > > /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux- > > gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/static- > > reloc.o > > Note the -r = --relocatable, an ld option, which, "Generate[s] > relocatable output---i.e., generate[s] an output file that can in > turn serve as input to ld. This is often called partial linking", > ie. the glibc build is just putting these .o files together for later > convenience. > Regrettably, this command both ignores -fdebug-prefix-map (which ld > doesn't accept) and puts the fully-qualified path to some of the > input .o files in the resulting crt1.o. At package splitdebuginfo() > time, although the fully-qualified path info is split off into the > .debug files, a (relative) path to the .debug files plus a checksum > is tacked onto libc.so by objcopy --add-gnu-debuglink ... and the > checksum depends on the path to the build. > 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?
Good work in tracking it down so far. Going off a bit of a random memory fragment, would it help to use relative paths in the compile/link command? Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
