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 -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-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
