affects 759038 asis-programs block 765467 by 759038 thanks I have traced #765467 to a discrepancy between debian/patches/ada-libgnatvsn.diff and debian/patches/gcc-base-version.diff, which are patches applied to both gcc-4.9 and gnat-4.9.
gcc-base-version.diff changes src/gcc/Makefile.in so that it builds version.o with the flag -DBASEVER=$(FULLVER_s) (where FULLVER_s has the value 4.9.1 and is introduced by this patch; upstream uses only BASEVER_s). This is a recent change introduced for #759038. ada-libgnatvsn.diff rebuilds version.o with -fPIC, so it can be included into libgnatvsn.so.4.9, and passes -DBASEVER=$(BASEVER_s), like upstream does. But the value of BASEVER_s is 4.9, not 4.9.1. Consequently: /usr/bin/gcc-4.9, linked statically with version.o, emits 4.9.1 /usr/bin/gnatpp, linked dynamically with version.o from libgnatvsn4.9, expects 4.9. I think the change made for #759038 should be reverted; as Matthias said, we should use "4.9" consistently, not "4.9.1". I disagree with Nicolas when he says that "gcc -dumpversion" should report 4.9.1; it should report 4.9 instead because Debian only ever uses the tip of the gcc-4_9-branch plus patches, and never exactly "4.9.1". Furthermore, 4.9.2 is looming on the horizon and will not change the format of ASIS tree files, so 4.9 is really the version that should be in the tree files. Assuming this change is reverted, gnat1 will still emit "4.9.1" into the tree files; this is the real issue. Linking gnat1 dynamically against libgnatvsn.so.4.9 might be desirable but seems like a lot of work, and also means that ada-libgnatvsn.diff would become even more intrusive than it already is (and it is not upstreamable without a lot more work because upstream supports many more cross-compiler configurations than we do ATM). In theory, gnat1 is linked statically with version.o, so emits whatever is configured into version.o. Why gnat1 would emit "4.9.1" as reported in #759038 escapes me ATM. gcc-base-version.diff was introduced back in 2011 to change the directories where various pieces of GCC are installed, e.g. /usr/lib/gcc/$(target)/4.6.1 to /usr/lib/gcc/$(target)/4.6 (changing BASEVER from 4.6.1 to 4.6). At the same time, this patch introduced FULLVER (value: 4.6.1). I am not sure why FULLVER is needed at all nowadays. Why not remove FULLVER altogether? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org