From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21308 invoked by alias); 7 Jan 2017 10:35:08 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21298 invoked by uid 89); 7 Jan 2017 10:35:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-languages-length:2255, plugins, gcccvs, sans X-HELO: einhorn.in-berlin.de Received: from einhorn.in-berlin.de (HELO einhorn.in-berlin.de) (192.109.42.8) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 07 Jan 2017 10:34:57 +0000 X-Envelope-From: doko@ubuntu.com Received: from [192.168.178.26] (ip5f5af460.dynamic.kabel-deutschland.de [95.90.244.96]) (authenticated bits=0) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v07AYrPr030829 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Jan 2017 11:34:53 +0100 Subject: Re: .../lib/gcc//7.1.1/ vs. .../lib/gcc//7/ To: Jakub Jelinek , gcc@gcc.gnu.org, Richard Biener References: <20170106124826.GJ21933@tucnak> From: Matthias Klose Message-ID: <8efe05da-cf5e-46e5-c4f7-a0565bdae05f@ubuntu.com> Date: Sat, 07 Jan 2017 10:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170106124826.GJ21933@tucnak> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-01/txt/msg00049.txt.bz2 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