Am 15.10.2014 um 22:16 schrieb Ludovic Brenta: > 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).
well, having the new libraries follow the style of the other runtime libraries would be a start. I didn't see any feedback on #748297. > 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? The full version is seen from users, and probably used in more places than you like. Therefore I do not want to change the output of gcc --version and having gcc -dumpversion print the same sounds reasonable too. So what about exposing the base version in version.[ch] and maybe adding a new driver option -dumpbaseversion, or -<somegnatspecific>version? Alternatively you could derive the base version from $ echo $(basename $(dirname $(gcc -print-libgcc-file-name))) 4.9 As a last resort, hard code it for jessie to 4.9. Matthias -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544103c5.9070...@debian.org