On Tue, Jan 10, 2017 at 12:15:41AM +0100, Matthias Klose wrote:
> On 09.01.2017 21:43, Jakub Jelinek wrote:
> > On Fri, Jan 06, 2017 at 01:48:26PM +0100, Jakub Jelinek wrote:
> >> Yet another option is introduce AC_ARG_ENABLE into all those configure
> >> scripts (some macro in config/*.m4) and do the sed conditionally.
> >
> > Here is a patch to do that.
> > Bootstrapped/regtested on x86_64-linux (without
> > --with-gcc-major-version-only) and on i686-linux (with
> > --with-gcc-major-version-only), then tested make install of both.
> > The former uses the standard gcc -dumpversion of 7.0.0 and 7.0.0 in
> > pathnames (e.g. usr/local/bin/x86_64-pc-linux-gnu-gcc-7.0.0,
> > usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.0,
> > usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.0.0,
> > usr/local/lib/go/7.0.0/x86_64-pc-linux-gnu,
> > usr/local/include/c++/7.0.0 etc.), while the latter uses
> > gcc -dumpversion of 7 and 7 in pathnames (e.g.
> > i686-pc-linux-gnu-gcc-7, usr/local/lib/gcc/i686-pc-linux-gnu/7,
> > usr/local/libexec/gcc/i686-pc-linux-gnu/7,
> > usr/local/lib/go/7/i686-pc-linux-gnu,
> > usr/local/include/c++/7 etc.).
> > Ok for trunk?
>
> Thanks for working on this. I'm using such a layout for the Debian/Ubuntu GCC
> builds for some years. The one thing a dislike with your patch is the changed
> output of the -dumpversion option which is different whether you use the the
> new
> configure option or not. This could break builds of third party software. I
> would prefer having -dumpversion the very same output independent of any
> configure options. Please could you introduce a new option if you really
> need that?
As I said on IRC, I think -dumpversion of 7 in this configuration is the
right thing to do. In GCC sources, we have 3 uses of -dumpversion,
two of them look like:
gcc_version := $(shell $(GOC) -dumpversion)
...
toolexeclibgodir =
$(nover_glibgo_toolexeclibdir)/go/$(gcc_version)/$(target_alias)
libexecsubdir = $(libexecdir)/gcc/$(target_alias)/$(gcc_version)
(in libgo and gotools), one in config/tcl.m4 is like:
if test "`gcc -dumpversion | awk -F. '{print
[$]1}'`" -lt "3" ; then
AC_MSG_WARN([64bit mode not supported with GCC
< 3.2 on $system])
which works well whether it prints 7 or 7.1.1.
With --with-gcc-major-version-only, the spec_version is different from
BASEVER, and -dumpversion can print just one of those, when they are not the
same. So, we either break users that expect they can do
`$CC -dumpmachine`-gcc-`$CC -dumpversion`, or find out the C++ includes by
g++ -dumpversion, etc., or we break users that expect 3 numbers separated
by dot or 2 numbers separated by dot with optional another one.
In the past, we have not always pointed 3 numbers, releases printed just
major.minor, like gcc -dumpversion printed 3.0 (as mentioned in the manual).
But the former 3.0 in the previous versioning scheme corresponds to just 7
in the new one. So, users that expect 3 numbers are already broken,
and just one number is just adjusting those assumptions to the current
versioning scheme. Yes, we can add a new option, but IMNSHO it should
be -dumpbaseversion or -dumpfullversion that will always print
major.minor.patchlevel. From the SUSE bugzilla, it looks like SUSE has
been shipping compilers that printed just 5 or 6 for almost 2 years now,
so hopefully some changes if needed somewhere have been already upstreamed.
Jakub
