dietlibc; build path issue on ARM despite -fdebug-prefix-map

[Christian Seiler]

Dear reproducible builds team,
(please Cc me, I'm not subscribed to the list)

I've recently fixed dietlibc to properly pass all dpkg-buildflags
to the compile process (doing that with upstream's Makefile is a
bit tricky). This fixed the build path reproducibility issue that
was present in previous versions on amd64 and i386.

However, on armhf there still is a problem:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/diffoscope-results/dietlibc.html

Somewhere in the debug info, the path for start.o is still hard
coded - but only for the binaries using that object file, as
compiled with the 'diet' wrapper.

Offending line in the build log [1]:

bin-arm/diet gcc -D__dietlibc__ \
   -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 \
   -fdebug-prefix-map=/build-1st/dietlibc-0.34~cvs20160606=. \
   -fstack-protector-strong -Wformat -Werror=format-security -Wall \
   -fno-pie -Wl,-z,relro -Wl,-z,now -no-pie -pipe \
   -nostdinc -D_REENTRANT -Os -fomit-frame-pointer -fstrict-aliasing \
   -W -Wall -Wextra -Wchar-subscripts -Wmissing-prototypes \
   -Wmissing-declarations -Wno-switch -Wno-unused -Wredundant-decls \
   -Wshadow  \
    -o bin-arm/elftrunc contrib/elftrunc.c

This translates to (if you run diet -v it will output the command
used for compilation):

gcc -nostdlib -static \
  -L/build-1st/dietlibc-0.34~cvs20160606/bin-arm \
  -L/usr/lib/diet/lib \
  /build-1st/dietlibc-0.34~cvs20160606/bin-arm/start.o \
  -D__dietlibc__ \
  -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 \
  -fdebug-prefix-map=/build-1st/dietlibc-0.34~cvs20160606=. \
  -fstack-protector-strong -Wformat -Werror=format-security -Wall \
  -fno-pie -Wl,-z,relro -Wl,-z,now -no-pie -pipe \
  -nostdinc -D_REENTRANT -Os -fomit-frame-pointer -fstrict-aliasing \
  -W -Wall -Wextra -Wchar-subscripts -Wmissing-prototypes \
  -Wmissing-declarations -Wno-switch -Wno-unused -Wredundant-decls \
  -Wshadow \
  -o bin-arm/elftrunc contrib/elftrunc.c \
  -isystem /build-1st/dietlibc-0.34~cvs20160606/include \
  -D__dietlibc__ \
  /build-1st/dietlibc-0.34~cvs20160606/bin-arm/dietlibc.a \
  -lgcc \
  /build-1st/dietlibc-0.34~cvs20160606/bin-arm/dietlibc.a

I tried putting -fdebug-prefix-map= first, but that doesn't change
anything. The 'diet' wrapper itself is not affected, because that's
compiled manually before that. After comparing both lines, the
difference here appears to be that the wrapper explicitly references
the absolute path of the object file,
/build-1st/dietlibc-0.34~cvs20160606/bin-arm/start.o,
while the manual compilation command in the Makefile just uses the
relative path bin-arm/start.o.

It appears as though gcc hard-codes the path for the startup file
on armhf, while it doesn't do so on x86. A simple way to try this
out, even without dietlibc:

cat > hello.c <<EOF
#include <stdio.h>

int main()
{
    puts("Hello World!");
    return 0;
}
EOF
gcc -g -Wall -o hello hello.c
readelf -Ws hello | grep FILE

On x86 the internal startup files (start.o for dietlibc, Scrt1.o,
crti.o, crtn.o, elf-init.oS for glibc) are not referenced at all,
while on ARM they are not only referenced, but are referenced with
absolute paths.

The funny thing is: normally this isn't really a problem for
reproducibility, because if the library is installed, the absolute
paths will be something along the lines of /usr/lib/.../*.o. And
binaries built with that path hard-coded are still going to be
reproducible across systems. But when building a C library this
is an actual issue.

Any suggestions on what to do about this? Did you encounter this
kind of issue before?

Regards,
Christian

[1] https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/dietlibc_0.34~cvs20160606-3.rbuild.log