[Reproducible-builds] Minimising work needed for this build-path issue

Ximin Luo infinity0 at debian.org
Mon Sep 5 20:10:00 UTC 2016


HW42:
> Ximin Luo:
>> [..]
>>
>> 1. Patch GCC to set debug-prefix-map to "$pwd=." by default (and the
>> analogue for other languages / tools).
>>
>> This behaviour is concretely different from the current situation:
>> during recursive-make scenarios, the gcc in subdirectories will have
>> different values for debug-prefix-map. Our current situtation OTOH is
>> that dpkg-buildflags is called once at the top-level directory, and
>> this value persists for all gcc subchildren for the whole build
>> (unless the upstream buildscripts do something weird to CFLAGS).
>>
>> If the behaviour were not different, I would strongly suggest "let's
>> just do this". But it's different, and I'm not sure what consequences
>> that would have. I'm looking for your comments on this.
> 
> I think this breaks the mapping to the source file, for example in gdb.
> So I think this is not a good solution.
> 

Yeah, this is what I was worried about, but my background knowledge here isn't good enough to be sure. Do you know where I could read up on how this all works?

>> Note that for languages that define "the path is the namespace" like
>> golang or java, this does not really matter. So in these cases I
>> strongly suggest patching the tool itself, instead of adding extra
>> command-line flags.
> 
> Could you clarify what you mean? I don't think the namespace and the
> path are the same in golang or in Java (sure, the namespace is the
> suffix of the path but including java.nio.file.Path into the binary
> doesn't break any of our assumptions).
> 

What I meant more specifically is that, either there is only one source root (GOPATH) or different source roots are not generally expected to be children of each other (in the directory tree of a source repo written in that language). For example one never sees a Java project with src/com/google and src/com/google/org/apache, but it's fairly common to see C/C++ projects with src/a/*.c treating src/a as the include-root, but with src/a/1/*.c treating src/a/1 as the include-root, yet with src/a/2/*.c treating src/a as the include-root.

With the former, it's fairly easy for a debugger to see that src/ is the source root. And I'm guessing the latter case is what would mess with gdb's source-file mappings if we went with (1). But it would be good to have someone explain this in more detail.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



More information about the Reproducible-builds mailing list