[PATCH] Introduce --with-gcc-major-version-only configure option

Jakub Jelinek jakub@redhat.com
Tue Jan 10 06:56:00 GMT 2017

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.


More information about the Gcc-patches mailing list