<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>The relocatable link is defined in glibc csu/Makefile line 125<br>
    </p>
    <p><br>
    </p>
    <p>On 27/09/18 12:18, Douglas Royds wrote:
      <blockquote type="cite">
        <meta http-equiv="content-type" content="text/html;
          charset=utf-8">
        <p>When I build glibc in two different places, I get
          non-reproducible results - a 4-byte difference:</p>
        <blockquote>
          <p><tt>$ cmp -l
~/workspace/upstream[12]/build/tmp/work/armv5e-tait-linux-gnueabi/glibc/2.28-r0/package/lib/libc-2.28.so</tt><tt><br>
            </tt><tt>1259181  71 172</tt><tt><br>
            </tt><tt>1259182  27 304</tt><tt><br>
            </tt><tt>1259183 152  77</tt><tt><br>
            </tt><tt>1259184 363 243</tt></p>
        </blockquote>
        <p>These 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</p>
        <p>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):</p>
        <blockquote>
          <p><tt>$
../recipe-sysroot-native/usr/bin/arm-tait-linux-gnueabi/arm-tait-linux-gnueabi-objdump
              -t csu/crt1.o</tt><tt><br>
            </tt><tt>...</tt><tt><br>
            </tt><tt>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</tt><tt><br>
            </tt><tt>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.o</tt><br>
          </p>
        </blockquote>
        This abi-note.o symbol is finding its way into libc.so:
        <blockquote>
          <p><tt>$
../recipe-sysroot-native/usr/bin/arm-tait-linux-gnueabi/arm-tait-linux-gnueabi-objdump
              -t libc.so<br>
              ...</tt><tt><br>
            </tt><tt>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</tt></p>
        </blockquote>
        So where does csu/crt1.o come from?<br>
        <blockquote>
          <blockquote> </blockquote>
          <p><tt>$ 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 </tt><tt><b>-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</b></tt><tt>
/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</tt></p>
          <blockquote> </blockquote>
        </blockquote>
        <p>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.</p>
        <p>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.</p>
        <p>There is a work-around: turn off the debug packaging:</p>
        <blockquote>
          <p><tt>INHIBIT_PACKAGE_DEBUG_SPLIT_pn-glibc = "1"</tt><br>
          </p>
        </blockquote>
        <p>I don't have a solution for this. Suggestions?</p>
      </blockquote>
    </p>
    <p><br>
    </p>
  </body>
</html>