Re: MKREPRO: what variable contains the actual obj directory?

[Thomas Klausner <tk%giga.or.at@localhost>]

On Thu, Jan 07, 2016 at 07:21:04PM +0000, Christos Zoulas wrote:
> In article <alpine.NEB.2.11.1601071727540.930%galant.ogmig.net@localhost>,
> Iain Hibbert  <plunky%ogmig.net@localhost> wrote:
> >On Thu, 7 Jan 2016, Thomas Klausner wrote:
> >
> >> On Thu, Jan 07, 2016 at 04:35:44PM +0000, Iain Hibbert wrote:
> >> > On Thu, 7 Jan 2016, Thomas Klausner wrote:
> >> > 
> >> > > For reproducible builds, the binaries should be the same independent
> >> > > of the paths where the source or object directories live.
> >> > > 
> >> > > There are patches available for gcc to fix the paths (i.e., replace
> >> > > the obj directory that is actually used in a build with a fixed
> >> > > string, e.g. /usr/obj).
> >> > > 
> >> > > However, with the gazillion options we have in share/mk for choosing
> >> > > object directories, I don't know what variable contains the actual
> >> > > object directory that is used during a build.
> >> > > 
> >> > > Can someone shed a light on this?
> >> > 
> >> > Ah, its somewhat complex :)
> >> > 
> >> > see section of bsd.obj.mk in bsd.README
> >> 
> >> Yes, I saw that. That's why I'm asking (and hoping) that there is a
> >> variable which gives me the final path to foo.o. Is there such a thing?
> >
> >perhaps .OBJDIR ?
> >
> >% cd src/usr.bin/make
> >% make -V .OBJDIR
> >/home/plunky/src/usr.bin/make
> >% mkdir obj
> >% make -V .OBJDIR
> >/home/plunky/src/usr.bin/make/obj
> >% mkdir obj.i386
> >% make -V .OBJDIR
> >/home/plunky/src/usr.bin/make/obj.i386
> 
> 2. Where is OBJDIR stored in the build artifacts and why?

Let's switch questions one and two around:

When I run readelf -W --debug-dump on /bin/ls, I see

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:        0x887 (32-bit)
   Version:       4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0xad): GNU C 4.8.5 -mtune=nocona -march=x86-64 -g -O2 -std=gnu99 -fdebug-prefix-map=$NETBSDSRCDIR=/usr/src -fdebug-prefix-map=$DESTDIR=/ -fdebug-prefix-map=$X11SRCDIR=/usr/xsrc
    <10>   DW_AT_language    : 1        (ANSI C)
    <11>   DW_AT_name        : (indirect string, offset: 0x2a5): /usr/src/bin/ls/cmp.c
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x2df): /usr/obj/src.amd64/bin/ls
    <19>   DW_AT_low_pc      : 0x401730
    <21>   DW_AT_high_pc     : 0x1db
    <29>   DW_AT_stmt_list   : 0x0
...
 <0><896>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <897>   DW_AT_producer    : (indirect string, offset: 0xad): GNU C 4.8.5 -mtune=nocona -march=x86-64 -g -O2 -std=gnu99 -fdebug-prefix-map=$NETBSDSRCDIR=/usr/src -fdebug-prefix-map=$DESTDIR=/ -fdebug-prefix-map=$X11SRCDIR=/usr/xsrc
    <89b>   DW_AT_language    : 1       (ANSI C)
    <89c>   DW_AT_name        : (indirect string, offset: 0x7e7): /usr/src/bin/ls/ls.c
    <8a0>   DW_AT_comp_dir    : (indirect string, offset: 0x2df): /usr/obj/src.amd64/bin/ls
 ...
...
 <0><2198>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <2199>   DW_AT_producer    : (indirect string, offset: 0xad): GNU C 4.8.5 -mtune=nocona -march=x86-64 -g -O2 -std=gnu99 -fdebug-prefix-map=$NETBSDSRCDIR=/usr/src -fdebug-prefix-
map=$DESTDIR=/ -fdebug-prefix-map=$X11SRCDIR=/usr/xsrc
    <219d>   DW_AT_language    : 1      (ANSI C)
    <219e>   DW_AT_name        : (indirect string, offset: 0x963): /usr/src/bin/ls/main.c
    <21a2>   DW_AT_comp_dir    : (indirect string, offset: 0x2df): /usr/obj/src.amd64/bin/ls
...
 
> 1. Why does MKREPRO need to know about OBJDIR?

To fix the references to /usr/obj/src.amd64, which is influenced by my
local setting, to something stable that does not depend on the host's
settings.

> 3. Even if we find and substitute $OBJDIR with something fixed, won't
>    that cause problems because we can build with and without
>    object directories?

If e.g. for /bin/ls we always have /usr/obj/bin/ls as object
directory, then we're consistent and reproducible. Or what am I
overlooking?
 Thomas