.../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/

.../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/

[Jakub Jelinek]

Hi!

SUSE and some other distros use a hack that omits the minor and patchlevel
versions from the directory layout, just uses the major number, it is very
uncommon to have more than one compiler for the same major number installed
in the same prefix now that major bumps every year and the distinction
between minor and patchlevel is just the amount of bugfixes it got after
the initial release.

Dunno if the following is the latest version.

The question is, do we want something like this upstream too, and
unconditionally or based on a configure option (--enable-major-version-only
?) and in the latter case what the default should be.

I must say I don't understand the cppbuiltin.c part in the patch,
CFLAGS-cppbuiltin.o += $(PREPROCESSOR_DEFINES) -DBASEVER=$(FULLVER_s)
cppbuiltin.o: $(FULLVER)
should already provide it with the full version.  And libjava bit is
obviously no longer needed.

If we apply the patch as is (sans those last two files?), the change would
be unconditional, and we'd have to adjust maintainer scripts etc. so that
if there is FULL-VER file, the full version is in there and needs to be
bumped and BASE-VER is then just the major from that.  The patch doesn't
seem to be complete though, e.g. gcc/configure.ac uses gcc_BASEVER
var for plugins and expects it to be the full version.  Or do we want
GCCPLUGIN_VERSION to be also solely the major version?

Another possibility for still unconditional change would be to sed
the major out from BASE-VER in all the places that read it from BASE-VER
file.  Files to look at are:
config/acx.m4
fixincludes/Makefile.in
gcc/configure.ac
gcc/Makefile.in
libada/Makefile.in
libatomic/Makefile.am
libcc1/configure.ac
libcilkrts/Makefile.am
libgcc/Makefile.in
libgfortran/Makefile.am
libgomp/Makefile.am
libitm/Makefile.am
libmpx/Makefile.am
libobjc/Makefile.in
liboffloadmic/Makefile.am
libquadmath/Makefile.am
libsanitizer/Makefile.am
libssp/Makefile.am
libstdc++-v3/fragment.am
libvtv/Makefile.am
lto-plugin/Makefile.am
maintainer-scripts/gcc_release
maintainer-scripts/update_web_docs_svn

Yet another option is introduce AC_ARG_ENABLE into all those configure
scripts (some macro in config/*.m4) and do the sed conditionally.

But the first and primary question is if we want to change anything in this
area.

Index: gcc/Makefile.in
===================================================================
--- gcc/Makefile.in.orig	2015-05-08 17:10:12.068697540 +0200
+++ gcc/Makefile.in	2015-05-08 17:25:31.831833081 +0200
@@ -810,12 +810,14 @@ GTM_H     = tm.h      $(tm_file_list) in
 TM_H      = $(GTM_H) insn-flags.h $(OPTIONS_H)
 
 # Variables for version information.
-BASEVER     := $(srcdir)/BASE-VER  # 4.x.y
+BASEVER     := $(srcdir)/BASE-VER  # 5
+FULLVER     := $(srcdir)/FULL-VER  # 5.x.y
 DEVPHASE    := $(srcdir)/DEV-PHASE # experimental, prerelease, ""
 DATESTAMP   := $(srcdir)/DATESTAMP # YYYYMMDD or empty
 REVISION    := $(srcdir)/REVISION  # [BRANCH revision XXXXXX]
 
 BASEVER_c   := $(shell cat $(BASEVER))
+FULLVER_c   := $(shell cat $(FULLVER))
 DEVPHASE_c  := $(shell cat $(DEVPHASE))
 DATESTAMP_c := $(shell cat $(DATESTAMP))
 
@@ -839,6 +841,7 @@ PATCHLEVEL_c := \
 # immediately after the comma in the $(if ...) constructs is
 # significant - do not remove it.
 BASEVER_s   := "\"$(BASEVER_c)\""
+FULLVER_s   := "\"$(FULLVER_c)\""
 DEVPHASE_s  := "\"$(if $(DEVPHASE_c), ($(DEVPHASE_c)))\""
 DATESTAMP_s := \
   "\"$(if $(DEVPHASE_c)$(filter-out 0,$(PATCHLEVEL_c)), $(DATESTAMP_c))\""
@@ -2028,7 +2031,7 @@ s-options-h: optionlist $(srcdir)/opt-fu
 
 dumpvers: dumpvers.c
 
-CFLAGS-version.o += -DBASEVER=$(BASEVER_s) -DDATESTAMP=$(DATESTAMP_s) \
+CFLAGS-version.o += -DBASEVER=$(FULLVER_s) -DDATESTAMP=$(DATESTAMP_s) \
 	-DREVISION=$(REVISION_s) \
 	-DDEVPHASE=$(DEVPHASE_s) -DPKGVERSION=$(PKGVERSION_s) \
 	-DBUGURL=$(BUGURL_s)
@@ -2038,10 +2041,10 @@ version.o: $(REVISION) $(DATESTAMP) $(BA
 CFLAGS-lto-compress.o += $(ZLIBINC)
 
 bversion.h: s-bversion; @true
-s-bversion: BASE-VER
-	echo "#define BUILDING_GCC_MAJOR `echo $(BASEVER_c) | sed -e 's/^\([0-9]*\).*$$/\1/'`" > bversion.h
-	echo "#define BUILDING_GCC_MINOR `echo $(BASEVER_c) | sed -e 's/^[0-9]*\.\([0-9]*\).*$$/\1/'`" >> bversion.h
-	echo "#define BUILDING_GCC_PATCHLEVEL `echo $(BASEVER_c) | sed -e 's/^[0-9]*\.[0-9]*\.\([0-9]*\)$$/\1/'`" >> bversion.h
+s-bversion: FULL-VER
+	echo "#define BUILDING_GCC_MAJOR `echo $(FULLVER_c) | sed -e 's/^\([0-9]*\).*$$/\1/'`" > bversion.h
+	echo "#define BUILDING_GCC_MINOR `echo $(FULLVER_c) | sed -e 's/^[0-9]*\.\([0-9]*\).*$$/\1/'`" >> bversion.h
+	echo "#define BUILDING_GCC_PATCHLEVEL `echo $(FULLVER_c) | sed -e 's/^[0-9]*\.[0-9]*\.\([0-9]*\)$$/\1/'`" >> bversion.h
 	echo "#define BUILDING_GCC_VERSION (BUILDING_GCC_MAJOR * 1000 + BUILDING_GCC_MINOR)" >> bversion.h
 	$(STAMP) s-bversion
 
@@ -2410,9 +2413,9 @@ build/%.o :  # dependencies provided by
 ## build/version.o is compiled by the $(COMPILER_FOR_BUILD) but needs
 ## several C macro definitions, just like version.o
 build/version.o:  version.c version.h \
-                  $(REVISION) $(DATESTAMP) $(BASEVER) $(DEVPHASE)
+                  $(REVISION) $(DATESTAMP) $(FULLVER) $(DEVPHASE)
 	$(COMPILER_FOR_BUILD) -c $(BUILD_COMPILERFLAGS) $(BUILD_CPPFLAGS) \
-	-DBASEVER=$(BASEVER_s) -DDATESTAMP=$(DATESTAMP_s) \
+	-DBASEVER=$(FULLVER_s) -DDATESTAMP=$(DATESTAMP_s) \
 	-DREVISION=$(REVISION_s) \
 	-DDEVPHASE=$(DEVPHASE_s) -DPKGVERSION=$(PKGVERSION_s) \
 	-DBUGURL=$(BUGURL_s) -o $@ $<
@@ -2623,8 +2626,8 @@ PREPROCESSOR_DEFINES = \
   -DSTANDARD_EXEC_PREFIX=\"$(libdir)/gcc/\" \
   @TARGET_SYSTEM_ROOT_DEFINE@
 
-CFLAGS-cppbuiltin.o += $(PREPROCESSOR_DEFINES) -DBASEVER=$(BASEVER_s)
-cppbuiltin.o: $(BASEVER)
+CFLAGS-cppbuiltin.o += $(PREPROCESSOR_DEFINES) -DBASEVER=$(FULLVER_s)
+cppbuiltin.o: $(FULLVER)
 
 CFLAGS-cppdefault.o += $(PREPROCESSOR_DEFINES)
 
@@ -2640,8 +2643,8 @@ build/gcov-iov$(build_exeext): build/gco
 		build/gcov-iov.o -o $@
 
 gcov-iov.h: s-iov
-s-iov: build/gcov-iov$(build_exeext) $(BASEVER) $(DEVPHASE)
-	build/gcov-iov$(build_exeext) '$(BASEVER_c)' '$(DEVPHASE_c)' \
+s-iov: build/gcov-iov$(build_exeext) $(FULLVER) $(DEVPHASE)
+	build/gcov-iov$(build_exeext) '$(FULLVER_c)' '$(DEVPHASE_c)' \
 	    > tmp-gcov-iov.h
 	$(SHELL) $(srcdir)/../move-if-change tmp-gcov-iov.h gcov-iov.h
 	$(STAMP) s-iov
Index: libjava/testsuite/lib/libjava.exp
===================================================================
--- libjava/testsuite/lib/libjava.exp.orig	2014-12-02 13:29:22.487902351 +0100
+++ libjava/testsuite/lib/libjava.exp	2015-05-08 17:25:31.831833081 +0200
@@ -179,7 +179,7 @@ proc libjava_init { args } {
 
     set text [eval exec "$GCJ_UNDER_TEST -B$specdir -v 2>@ stdout"]
     regexp " version \[^\n\r\]*" $text version
-    set libjava_version [lindex $version 1]
+    set libjava_version 5
 
     verbose "version: $libjava_version"
 
Index: gcc/cppbuiltin.c
===================================================================
--- gcc/cppbuiltin.c.orig	2015-01-12 16:22:34.486893087 +0100
+++ gcc/cppbuiltin.c	2015-05-08 17:25:31.832833089 +0200
@@ -46,9 +46,9 @@ parse_basever (int *major, int *minor, i
   static int s_major = -1, s_minor, s_patchlevel;
 
   if (s_major == -1)
-    if (sscanf (BASEVER, "%d.%d.%d", &s_major, &s_minor, &s_patchlevel) != 3)
+    if (sscanf (version_string, "%d.%d.%d", &s_major, &s_minor, &s_patchlevel) != 3)
       {
-	sscanf (BASEVER, "%d.%d", &s_major, &s_minor);
+	sscanf (version_string, "%d.%d", &s_major, &s_minor);
 	s_patchlevel = 0;
       }
 


	Jakub

Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/

[Szabolcs Nagy]

On 06/01/17 12:48, Jakub Jelinek wrote:
> SUSE and some other distros use a hack that omits the minor and patchlevel
> versions from the directory layout, just uses the major number, it is very

what is the benefit?

Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 01:07:23PM +0000, Szabolcs Nagy wrote:
> On 06/01/17 12:48, Jakub Jelinek wrote:
> > SUSE and some other distros use a hack that omits the minor and patchlevel
> > versions from the directory layout, just uses the major number, it is very
> 
> what is the benefit?

Various packages use the paths to gcc libraries/includes etc. in various
places (e.g. libtool, *.la files, etc.).  So any time you upgrade gcc
(say from 6.1.0 to 6.2.0 or 6.2.0 to 6.2.1), everything that has those paths
needs to be rebuilt.  By having only the major number in the paths (which is
pretty much all that matters), you only have to rebuild when the major
version of gcc changes (at which time one usually want to mass rebuild
everything anyway).

	Jakub

Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/

[Szabolcs Nagy]

On 06/01/17 13:11, Jakub Jelinek wrote:
> On Fri, Jan 06, 2017 at 01:07:23PM +0000, Szabolcs Nagy wrote:
>> On 06/01/17 12:48, Jakub Jelinek wrote:
>>> SUSE and some other distros use a hack that omits the minor and patchlevel
>>> versions from the directory layout, just uses the major number, it is very
>>
>> what is the benefit?
> 
> Various packages use the paths to gcc libraries/includes etc. in various
> places (e.g. libtool, *.la files, etc.).  So any time you upgrade gcc

it is a bug that gcc installs libtool la files,
because a normal cross toolchain is relocatable
but the la files have abs path in them.

that would be nice to fix, so build scripts don't
have to manually delete the bogus la files.

> (say from 6.1.0 to 6.2.0 or 6.2.0 to 6.2.1), everything that has those paths
> needs to be rebuilt.  By having only the major number in the paths (which is
> pretty much all that matters), you only have to rebuild when the major
> version of gcc changes (at which time one usually want to mass rebuild
> everything anyway).

i thought only the gcc driver needs to know
these paths because there are no shared libs
there that are linked into binaries so no binary
references those paths so nothing have to be
rebuilt.

Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 02:13:05PM +0000, Szabolcs Nagy wrote:
> On 06/01/17 13:11, Jakub Jelinek wrote:
> > On Fri, Jan 06, 2017 at 01:07:23PM +0000, Szabolcs Nagy wrote:
> >> On 06/01/17 12:48, Jakub Jelinek wrote:
> >>> SUSE and some other distros use a hack that omits the minor and patchlevel
> >>> versions from the directory layout, just uses the major number, it is very
> >>
> >> what is the benefit?
> > 
> > Various packages use the paths to gcc libraries/includes etc. in various
> > places (e.g. libtool, *.la files, etc.).  So any time you upgrade gcc
> 
> it is a bug that gcc installs libtool la files,
> because a normal cross toolchain is relocatable
> but the la files have abs path in them.

I'm not talking about *.la files installed by gcc.  I'm talking about any
*.la files created by libtool or libtool scripts themselves.
There are libtool hacks floating around that avoid the gcc internal paths,
but I think it is not in upstream libtool.

> > (say from 6.1.0 to 6.2.0 or 6.2.0 to 6.2.1), everything that has those paths
> > needs to be rebuilt.  By having only the major number in the paths (which is
> > pretty much all that matters), you only have to rebuild when the major
> > version of gcc changes (at which time one usually want to mass rebuild
> > everything anyway).
> 
> i thought only the gcc driver needs to know
> these paths because there are no shared libs
> there that are linked into binaries so no binary
> references those paths so nothing have to be
> rebuilt.

That is not the case, various programs just store the gcc
-print-file-name=<something> paths in various locations.
Some query it at runtime (not sure what e.g. clang++ does when it wants to
use libstdc++ headers), others store it.

	Jakub

Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/

[Richard Biener]

On January 6, 2017 2:11:51 PM GMT+01:00, Jakub Jelinek <jakub@redhat.com> wrote:
>On Fri, Jan 06, 2017 at 01:07:23PM +0000, Szabolcs Nagy wrote:
>> On 06/01/17 12:48, Jakub Jelinek wrote:
>> > SUSE and some other distros use a hack that omits the minor and
>patchlevel
>> > versions from the directory layout, just uses the major number, it
>is very
>> 
>> what is the benefit?
>
>Various packages use the paths to gcc libraries/includes etc. in
>various
>places (e.g. libtool, *.la files, etc.).  So any time you upgrade gcc
>(say from 6.1.0 to 6.2.0 or 6.2.0 to 6.2.1), everything that has those
>paths
>needs to be rebuilt.  By having only the major number in the paths
>(which is
>pretty much all that matters), you only have to rebuild when the major
>version of gcc changes (at which time one usually want to mass rebuild
>everything anyway).

RPMs from ISVs having this issue made us change is for SUSE.   Note another workaround is to provide symlinks from old provided versions to the actual one.

It's really all a packaging issue so not sure if upstream should change anything by default.  Providing a way to do it would be nice of course.

Richard.

>
>	Jakub

Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/

[Matthias Klose]

On 06.01.2017 15:13, Szabolcs Nagy wrote:
> On 06/01/17 13:11, Jakub Jelinek wrote:
>> On Fri, Jan 06, 2017 at 01:07:23PM +0000, Szabolcs Nagy wrote:
>>> On 06/01/17 12:48, Jakub Jelinek wrote:
>>>> SUSE and some other distros use a hack that omits the minor and patchlevel
>>>> versions from the directory layout, just uses the major number, it is very
>>>
>>> what is the benefit?
>>
>> Various packages use the paths to gcc libraries/includes etc. in various
>> places (e.g. libtool, *.la files, etc.).  So any time you upgrade gcc
> 
> it is a bug that gcc installs libtool la files,
> because a normal cross toolchain is relocatable
> but the la files have abs path in them.
> 
> that would be nice to fix, so build scripts don't
> have to manually delete the bogus la files.
> 
>> (say from 6.1.0 to 6.2.0 or 6.2.0 to 6.2.1), everything that has those paths
>> needs to be rebuilt.  By having only the major number in the paths (which is
>> pretty much all that matters), you only have to rebuild when the major
>> version of gcc changes (at which time one usually want to mass rebuild
>> everything anyway).
> 
> i thought only the gcc driver needs to know
> these paths because there are no shared libs
> there that are linked into binaries so no binary
> references those paths so nothing have to be
> rebuilt.

You also end up with dependencies of the form
/usr/lib/gcc/<target>/<version>/../../.././include which then break when you
update to a new branch version.

Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/

[Matthias Klose]

On 06.01.2017 13:48, Jakub Jelinek wrote:
> Hi!
> 
> SUSE and some other distros use a hack that omits the minor and patchlevel
> versions from the directory layout, just uses the major number, it is very
> uncommon to have more than one compiler for the same major number installed
> in the same prefix now that major bumps every year and the distinction
> between minor and patchlevel is just the amount of bugfixes it got after
> the initial release.
> 
> Dunno if the following is the latest version.

Looking at the variable naming it looks like these are taken from the
Debian/Ubuntu packages.  The latest version is
https://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-7/debian/patches/gcc-base-version.diff?view=markup

> The question is, do we want something like this upstream too, and
> unconditionally or based on a configure option (--enable-major-version-only
> ?) and in the latter case what the default should be.
> 
> I must say I don't understand the cppbuiltin.c part in the patch,
> CFLAGS-cppbuiltin.o += $(PREPROCESSOR_DEFINES) -DBASEVER=$(FULLVER_s)
> cppbuiltin.o: $(FULLVER)
> should already provide it with the full version.  And libjava bit is
> obviously no longer needed.

I didn't want to change the preprocessor defines. Maybe it's clearer to
s/BASEVER/FULLVER/ in cppbuiltin.c and just passing FULLVER to the build.

> If we apply the patch as is (sans those last two files?), the change would
> be unconditional, and we'd have to adjust maintainer scripts etc. so that
> if there is FULL-VER file, the full version is in there and needs to be
> bumped and BASE-VER is then just the major from that.  The patch doesn't
> seem to be complete though, e.g. gcc/configure.ac uses gcc_BASEVER
> var for plugins and expects it to be the full version.  Or do we want
> GCCPLUGIN_VERSION to be also solely the major version?

The patch predates the plugin, I should update it for the gccplugin as well.

> Another possibility for still unconditional change would be to sed
> the major out from BASE-VER in all the places that read it from BASE-VER
> file.  Files to look at are:

Some configure files use sed, some use gcc -dumpversion to construct gcc libdir.

Matthias