From: Matthias Klose <doko@ubuntu.com>
To: Jakub Jelinek <jakub@redhat.com>,
gcc@gcc.gnu.org, Richard Biener <rguenther@suse.de>
Subject: Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/
Date: Sat, 07 Jan 2017 10:35:00 -0000 [thread overview]
Message-ID: <8efe05da-cf5e-46e5-c4f7-a0565bdae05f@ubuntu.com> (raw)
In-Reply-To: <20170106124826.GJ21933@tucnak>
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
prev parent reply other threads:[~2017-01-07 10:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-06 12:48 Jakub Jelinek
2017-01-06 13:07 ` Szabolcs Nagy
2017-01-06 13:12 ` Jakub Jelinek
2017-01-06 14:13 ` Szabolcs Nagy
2017-01-06 14:21 ` Jakub Jelinek
2017-01-07 10:22 ` Matthias Klose
2017-01-06 17:51 ` Richard Biener
2017-01-07 10:35 ` Matthias Klose [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8efe05da-cf5e-46e5-c4f7-a0565bdae05f@ubuntu.com \
--to=doko@ubuntu.com \
--cc=gcc@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).