[gentoo-dev] RFC: masking old versions of sys-devel/gcc

[gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]

Hi,

I'm thinking of masking old versions of sys-devel/gcc, in particular
older than the 4.9 branch.


The problem
===========

Gentoo users still sometimes try to build new packages with old gcc
versions which inevitably fails, either due to bugs or missing features
in the old versions of gcc. The most relevant example is C++ packages
requiring support for C++11 which is obviously missing from old gcc
versions.

I think this mostly affects old installations where sysadmins fail to
update and/or switch gcc before starting system upgrades. While I don't
think it's a major issue anymore, some developers still try to make
their ebuilds more complex to account for that.

Most of the time fixing the support for old gcc is out of the question.
In that case, developers add checks for appropriately new gcc version
(which may randomly fail with clang) and/or features. While this solves
the immediate problem, it causes unnecessary complexity. With EAPI 5,
the proper way of checking this involves running pkg_pretend() -- which
causes a major slowdown for the package manager.

Nowadays a great number of packages requires C++11. Adding pkg_pretend()
check for every single one of them is both a lot of work
and a significant slowdown to support outdated systems. Or rather, to
replace a error from the build system with early error from ebuild.
Worse than that, developers sometimes deploy different kinds of checks,
some of which are buggy.


My solution
===========

I think there is no point in having explicit support for ancient gcc
versions these days. However, I admit that some specific developers
and users may have a need for them. Therefore, I think the best way
forward would be to keep them in ::gentoo but p.mask with
an explanatory message.

The most important goal of having the packages masked is that it would
cause Portage to verbosely complain whenever the users have it
installed. With appropriate comment (displayed by Portage), we could
clearly inform users that they need to upgrade gcc and switch to a new
version to ensure that majority of packages work.

We would also clearly indicate that we no longer support the old
versions and do not have to explicitly indicate this non-support via
explicit version checks in ebuilds.

At the same time, users who really need those versions could unmask them
on their own responsibility and knowing the implications of setting them
as system-wide compilers.


What do you think?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3207 bytes --]

On Sun, Apr 23, 2017 at 02:35:48PM +0200, Michał Górny wrote:
> Hi,
> 
> I'm thinking of masking old versions of sys-devel/gcc, in particular
> older than the 4.9 branch.
> 
> 
> The problem
> ===========
> 
> Gentoo users still sometimes try to build new packages with old gcc
> versions which inevitably fails, either due to bugs or missing features
> in the old versions of gcc. The most relevant example is C++ packages
> requiring support for C++11 which is obviously missing from old gcc
> versions.
> 
> I think this mostly affects old installations where sysadmins fail to
> update and/or switch gcc before starting system upgrades. While I don't
> think it's a major issue anymore, some developers still try to make
> their ebuilds more complex to account for that.
> 
> Most of the time fixing the support for old gcc is out of the question.
> In that case, developers add checks for appropriately new gcc version
> (which may randomly fail with clang) and/or features. While this solves
> the immediate problem, it causes unnecessary complexity. With EAPI 5,
> the proper way of checking this involves running pkg_pretend() -- which
> causes a major slowdown for the package manager.
> 
> Nowadays a great number of packages requires C++11. Adding pkg_pretend()
> check for every single one of them is both a lot of work
> and a significant slowdown to support outdated systems. Or rather, to
> replace a error from the build system with early error from ebuild.
> Worse than that, developers sometimes deploy different kinds of checks,
> some of which are buggy.
> 
> 
> My solution
> ===========
> 
> I think there is no point in having explicit support for ancient gcc
> versions these days. However, I admit that some specific developers
> and users may have a need for them. Therefore, I think the best way
> forward would be to keep them in ::gentoo but p.mask with
> an explanatory message.
> 
> The most important goal of having the packages masked is that it would
> cause Portage to verbosely complain whenever the users have it
> installed. With appropriate comment (displayed by Portage), we could
> clearly inform users that they need to upgrade gcc and switch to a new
> version to ensure that majority of packages work.
> 
> We would also clearly indicate that we no longer support the old
> versions and do not have to explicitly indicate this non-support via
> explicit version checks in ebuilds.
> 
> At the same time, users who really need those versions could unmask them
> on their own responsibility and knowing the implications of setting them
> as system-wide compilers.
> 
> 
> What do you think?

Honestly,

if we aren't going to officially support those older versions of gcc, I
would rather see them moved to an overlay and removed from the main
tree.

Yes, some users and developers may need them for some obscure purpose,
but that doesn't justify keeping them permanently masked in the main
tree especially since package.mask isn't supposed to be a permanent
thing.

There is a ::toolchain overlay somewhere, maybe they should go there
instead of in the main tree.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Guilherme Amadio]

On Mon, Apr 24, 2017 at 11:01:32AM -0500, William Hubbs wrote:
> On Sun, Apr 23, 2017 at 02:35:48PM +0200, Michał Górny wrote:
> > Hi,
> > 
> > I'm thinking of masking old versions of sys-devel/gcc, in particular
> > older than the 4.9 branch.
> [...]
> > My solution
> > ===========
> > 
> > I think there is no point in having explicit support for ancient gcc
> > versions these days. However, I admit that some specific developers
> > and users may have a need for them. Therefore, I think the best way
> > forward would be to keep them in ::gentoo but p.mask with
> > an explanatory message.
> > 
> > The most important goal of having the packages masked is that it would
> > cause Portage to verbosely complain whenever the users have it
> > installed. With appropriate comment (displayed by Portage), we could
> > clearly inform users that they need to upgrade gcc and switch to a new
> > version to ensure that majority of packages work.
> > 
> > We would also clearly indicate that we no longer support the old
> > versions and do not have to explicitly indicate this non-support via
> > explicit version checks in ebuilds.
> > 
> > At the same time, users who really need those versions could unmask them
> > on their own responsibility and knowing the implications of setting them
> > as system-wide compilers.
> > 
> > 
> > What do you think?

+1

> Honestly,
> 
> if we aren't going to officially support those older versions of gcc, I
> would rather see them moved to an overlay and removed from the main
> tree.

I would rather prefer to keep essential development tools in tree.
GCC is not only used as system compiler, but also for development.
I already had problems before with CMake being aggressively removed,
so I couldn't just install CMake 3.5.2 to test something that got
broken with the latest CMake (3.7.2 at the time).

For things like autotools, CMake, compilers, etc, I would like to
see at least the latest release of the previous major version (e.g.
CMake 2.8), and the last few latest releases from the current major
version (e.g. CMake 3.{5,6,7}). Similarly for essential libraries,
as in prefix you may be somewhat limited by the host (think macOS),
so removing old ebuilds aggressively breaks stuff. I think this was
the case with clang before, where we needed 3.5 and that got removed,
so bootstrapping on macOS was broken for sometime.

Cheers,
—Guilherme

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

On Mon, Apr 24, 2017 at 07:59:53PM +0200, Guilherme Amadio wrote:
> 
> I would rather prefer to keep essential development tools in tree.
> GCC is not only used as system compiler, but also for development.
> I already had problems before with CMake being aggressively removed,
> so I couldn't just install CMake 3.5.2 to test something that got
> broken with the latest CMake (3.7.2 at the time).
>
> For things like autotools, CMake, compilers, etc, I would like to
> see at least the latest release of the previous major version (e.g.
> CMake 2.8), and the last few latest releases from the current major
> version (e.g. CMake 3.{5,6,7}). Similarly for essential libraries,
> as in prefix you may be somewhat limited by the host (think macOS),
> so removing old ebuilds aggressively breaks stuff. I think this was
> the case with clang before, where we needed 3.5 and that got removed,
> so bootstrapping on macOS was broken for sometime.

That's completely reasonable. My concern is that we have the following
versions of gcc in the tree:

gcc-2.95.3-r10
gcc-3.3.6-r1
gcc-3.4.6-r2
gcc-4.0.4
gcc-4.1.2
gcc-4.2.4-r1
gcc-4.3.6-r1
gcc-4.4.7
gcc-4.5.4
gcc-4.6.4
gcc-4.7.4
gcc-4.8.5
gcc-4.9.3
gcc-4.9.4
gcc-5.4.0
gcc-5.4.0-r3
gcc-6.3.0

Under your proposal, I guess we would just have gcc-5.4.0-r3, gcc-4.9.4
and maybe gcc-3.4.6-r2 and *definitely maybe* gcc-2.95.3-r10. Is this
correct?

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Guilherme Amadio]

On Tue, Apr 25, 2017 at 11:26:16AM -0500, William Hubbs wrote:
> On Mon, Apr 24, 2017 at 07:59:53PM +0200, Guilherme Amadio wrote:
> > 
> > I would rather prefer to keep essential development tools in tree.
> > GCC is not only used as system compiler, but also for development.
> > I already had problems before with CMake being aggressively removed,
> > so I couldn't just install CMake 3.5.2 to test something that got
> > broken with the latest CMake (3.7.2 at the time).
> >
> > For things like autotools, CMake, compilers, etc, I would like to
> > see at least the latest release of the previous major version (e.g.
> > CMake 2.8), and the last few latest releases from the current major
> > version (e.g. CMake 3.{5,6,7}). Similarly for essential libraries,
> > as in prefix you may be somewhat limited by the host (think macOS),
> > so removing old ebuilds aggressively breaks stuff. I think this was
> > the case with clang before, where we needed 3.5 and that got removed,
> > so bootstrapping on macOS was broken for sometime.
> 
> That's completely reasonable. My concern is that we have the following
> versions of gcc in the tree:
> 
> gcc-2.95.3-r10
> gcc-3.3.6-r1
> gcc-3.4.6-r2
> gcc-4.0.4
> gcc-4.1.2
> gcc-4.2.4-r1
> gcc-4.3.6-r1
> gcc-4.4.7
> gcc-4.5.4
> gcc-4.6.4
> gcc-4.7.4
> gcc-4.8.5
> gcc-4.9.3
> gcc-4.9.4
> gcc-5.4.0
> gcc-5.4.0-r3
> gcc-6.3.0
> 
> Under your proposal, I guess we would just have gcc-5.4.0-r3, gcc-4.9.4
> and maybe gcc-3.4.6-r2 and *definitely maybe* gcc-2.95.3-r10. Is this
> correct?

I'm not saying we should cut down to the set of versions I mentioned.
I think it's totally fine to have all the gcc versions above in the tree.
What I want to avoid is having less than what I said due to aggressive
removal of older versions, at least for critical packages like the toolchain
and related tools. So, I'd be happy with the set below for gcc, for example:

> gcc-4.4.7
> gcc-4.7.4
> gcc-4.8.5
> gcc-4.9.4
> gcc-5.3.0
> gcc-5.4.0-r3
> gcc-6.3.0

However, it doesn't hurt to have the older 3.x and 2.95 versions in case
someone needs to compile, say, software that was developed a long time
ago and doesn't compile anymore with the latest compilers.

Cheers,
—Guilherme

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Francesco Riosa]

On 25/04/2017 18:44, Guilherme Amadio wrote:
> On Tue, Apr 25, 2017 at 11:26:16AM -0500, William Hubbs wrote:
>> On Mon, Apr 24, 2017 at 07:59:53PM +0200, Guilherme Amadio wrote:
>>> I would rather prefer to keep essential development tools in tree.
>>> GCC is not only used as system compiler, but also for development.
>>> I already had problems before with CMake being aggressively removed,
>>> so I couldn't just install CMake 3.5.2 to test something that got
>>> broken with the latest CMake (3.7.2 at the time).
>>>
>>> For things like autotools, CMake, compilers, etc, I would like to
>>> see at least the latest release of the previous major version (e.g.
>>> CMake 2.8), and the last few latest releases from the current major
>>> version (e.g. CMake 3.{5,6,7}). Similarly for essential libraries,
>>> as in prefix you may be somewhat limited by the host (think macOS),
>>> so removing old ebuilds aggressively breaks stuff. I think this was
>>> the case with clang before, where we needed 3.5 and that got removed,
>>> so bootstrapping on macOS was broken for sometime.
>> That's completely reasonable. My concern is that we have the following
>> versions of gcc in the tree:
>>
>> gcc-2.95.3-r10
>> gcc-3.3.6-r1
>> gcc-3.4.6-r2
>> gcc-4.0.4
>> gcc-4.1.2
>> gcc-4.2.4-r1
>> gcc-4.3.6-r1
>> gcc-4.4.7
>> gcc-4.5.4
>> gcc-4.6.4
>> gcc-4.7.4
>> gcc-4.8.5
>> gcc-4.9.3
>> gcc-4.9.4
>> gcc-5.4.0
>> gcc-5.4.0-r3
>> gcc-6.3.0
>>
>> Under your proposal, I guess we would just have gcc-5.4.0-r3, gcc-4.9.4
>> and maybe gcc-3.4.6-r2 and *definitely maybe* gcc-2.95.3-r10. Is this
>> correct?
> I'm not saying we should cut down to the set of versions I mentioned.
> I think it's totally fine to have all the gcc versions above in the tree.
> What I want to avoid is having less than what I said due to aggressive
> removal of older versions, at least for critical packages like the toolchain
> and related tools. So, I'd be happy with the set below for gcc, for example:
>
>> gcc-4.4.7
>> gcc-4.7.4
>> gcc-4.8.5
>> gcc-4.9.4
>> gcc-5.3.0
>> gcc-5.4.0-r3
>> gcc-6.3.0
> However, it doesn't hurt to have the older 3.x and 2.95 versions in case
> someone needs to compile, say, software that was developed a long time
> ago and doesn't compile anymore with the latest compilers.
>
last time I've checked (year 2010?) gcc-2.95 was impossible to emerge 
with a newer version of gcc.
gcc-3.4.6 (I'm a bit surprised) _can_ be compiled by gcc-6.3
USE="-* nptl" emerge -1 -a --buildpkgonly =gcc-3.4.6-r2
but it was released March 06, 2006.

IMHO who need these old versions of gcc for good reasons is able to use 
$preferred_search_engine to find them, if toolchain overlay can be 
resumed to host those.
Of the fairly extensive (but far from complete) subset of gentoo tree 
installed on my machines only Nvidia/cuda stuff require gcc older than 5 
and nothing require something older than 4.9

my vote would be keep:
gcc-4.{8.5,9.4}
gcc-5.4
gcc-6.3

and call it northern emisphere spring cleaning (NESC)

regards,
Francesco

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

Am Sonntag, 23. April 2017, 14:35:48 CEST schrieb Michał Górny:
> Hi,
> 
> I'm thinking of masking old versions of sys-devel/gcc, in particular
> older than the 4.9 branch.
> 

Masking is fine; some time later (maybe in a few months) I'd even suggest 
masking all of gcc-4. After all, unmasking them if you really need them is 
rather easy.

About removing them (what William proposed), I'd keep what we have now. We had 
this discussion already in lots of detail in the past, and convincing points 
were made to keep one of each 4.x ...

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Francesco Riosa]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

2017-04-26 0:26 GMT+02:00 Andreas K. Huettel <dilfridge@gentoo.org>:

> Am Sonntag, 23. April 2017, 14:35:48 CEST schrieb Michał Górny:
> > Hi,
> >
> > I'm thinking of masking old versions of sys-devel/gcc, in particular
> > older than the 4.9 branch.
> >
>
> Masking is fine; some time later (maybe in a few months) I'd even suggest
> masking all of gcc-4. After all, unmasking them if you really need them is
> rather easy.
>

well if the intent is cleaning adding a package mask is just more burden,
not less.
If they compile fine with the latest stable gcc better leave them unmasked,
right?



>
> About removing them (what William proposed), I'd keep what we have now. We
> had
> this discussion already in lots of detail in the past, and convincing
> points
> were made to keep one of each 4.x ...
>

do you have any pointers or keyword to search?
Because once upon a time there were incompatible changes frequently (2.95
=> 3.x with x < 4 was bloody) but nowadays everything "C" seem more stable.
And the switch to c++11 still ongoing started with 4.8 and far less
problematic.
Maybe different arches than amd64? Binary packages? Embedded platforms?


>
> --
> Andreas K. Hüttel
> dilfridge@gentoo.org
> Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: Type: text/html, Size: 2097 bytes --]

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

Am Mittwoch, 26. April 2017, 02:37:17 CEST schrieb Francesco Riosa:
> 2017-04-26 0:26 GMT+02:00 Andreas K. Huettel <dilfridge@gentoo.org>:
> > Am Sonntag, 23. April 2017, 14:35:48 CEST schrieb Michał Górny:
> > > Hi,
> > > 
> > > I'm thinking of masking old versions of sys-devel/gcc, in particular
> > > older than the 4.9 branch.
> > 
> > Masking is fine; some time later (maybe in a few months) I'd even suggest
> > masking all of gcc-4. After all, unmasking them if you really need them is
> > rather easy.
> 
> well if the intent is cleaning adding a package mask is just more burden,
> not less.
> If they compile fine with the latest stable gcc better leave them unmasked,
> right?

Except that "switching back" from gcc-5 to gcc-4 doesn't really work, and that 
gcc-4 will happily use gcc-5 libraries, with unintended consequences. 

As far as I understand it, the clean way is to either emerge gcc-5 and set it 
as default, or mask gcc-5 and keep it off your system.

Masking gcc-4 would force people to make a decision.


> > About removing them (what William proposed), I'd keep what we have now. We
> > had
> > this discussion already in lots of detail in the past, and convincing
> > points
> > were made to keep one of each 4.x ...
> 
> do you have any pointers or keyword to search?
> Because once upon a time there were incompatible changes frequently (2.95
> => 3.x with x < 4 was bloody) but nowadays everything "C" seem more stable.
> And the switch to c++11 still ongoing started with 4.8 and far less
> problematic.
> Maybe different arches than amd64? Binary packages? Embedded platforms?

I don't know the details anymore, will search later. But blueness was the 
right person to ask.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Mike Gilbert]

On Wed, Apr 26, 2017 at 5:32 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> Am Mittwoch, 26. April 2017, 02:37:17 CEST schrieb Francesco Riosa:
>> 2017-04-26 0:26 GMT+02:00 Andreas K. Huettel <dilfridge@gentoo.org>:
>> > Am Sonntag, 23. April 2017, 14:35:48 CEST schrieb Michał Górny:
>> > > Hi,
>> > >
>> > > I'm thinking of masking old versions of sys-devel/gcc, in particular
>> > > older than the 4.9 branch.
>> >
>> > Masking is fine; some time later (maybe in a few months) I'd even suggest
>> > masking all of gcc-4. After all, unmasking them if you really need them is
>> > rather easy.
>>
>> well if the intent is cleaning adding a package mask is just more burden,
>> not less.
>> If they compile fine with the latest stable gcc better leave them unmasked,
>> right?
>
> Except that "switching back" from gcc-5 to gcc-4 doesn't really work, and that
> gcc-4 will happily use gcc-5 libraries, with unintended consequences.

What do you mean by "gcc-4 will happily use gcc-5 libraries"?

If you mean at build time, it does NOT use gcc-5 libs. If it does, that's a bug.

% gcc-4.9.4 --print-search-dirs | grep ^libraries:
libraries: =/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.9.4/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../x86_64-pc-linux-gnu/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../x86_64-pc-linux-gnu/4.9.4/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../lib64/:/lib/x86_64-pc-linux-gnu/4.9.4/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/4.9.4/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../:/lib/:/usr/lib/

If you mean runtime, that's controlled by
/etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf. There's really
nothing wrong with using a newer libstdc++ at runtime; they should be
ABI compatible.

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Walter Dnes]

On Wed, Apr 26, 2017 at 11:32:21AM +0200, Andreas K. Huettel wrote

> Except that "switching back" from gcc-5 to gcc-4 doesn't really work,
> and that gcc-4 will happily use gcc-5 libraries, with unintended
> consequences.

  It can be done, but it takes a little work.  I do a contributed build
for Pale Moon using gcc 4.9.4 as per the developers' specs, and I use
5.4.0 for personal builds at home.  This is done on a 32-bit CoentOS 6.5
chroot, in order to use an older gtk2 (long story).  The native compiler
is gcc 4.7.4.  I build self-contained gcc 4.9.4 and 5.4.0 environments.
Example follows, with gcc-4.9.4 going into $HOME/gcc494/

#######################################################################
#
# Instructions adapted from https://gcc.gnu.org/wiki/InstallingGCC

wget http://ftpmirror.gnu.org/gcc/gcc-4.9.4/gcc-4.9.4.tar.bz2
tar xjf gcc-4.9.4.tar.bz2

#
# To get gmp, mpc, mpfr, and isl libs
# You *MUST* run this script from the top-level GCC source dir

cd gcc-4.9.4
contrib/download_prerequisites

export CFLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
export CXXFLAGS="${CFLAGS}"
export MAKEOPTS="-j4"

#
# You *MUST NOT* run ./configure from the toplevel GCC source dir

mkdir gcc-build && cd gcc-build

../configure --prefix=$HOME/gcc494 \
             --disable-multilib \
             --enable-libstdcxx-threads \
             --enable-libstdcxx-time \
             --enable-shared \
             --enable-__cxa_atexit \
             --disable-libunwind-exceptions \
             --disable-libada

make -j4

make install
#######################################################################

  So far, so good, but we also need to force invocations of "gcc" to use
this version.  The build script sources the following commands (and
other build-specific stuff) before starting the compile...

#######################################################################
export GCCX_ROOT=$HOME/gcc494
export PATH=$GCCX_ROOT/bin:$PATH
export MANPATH=$GCCX_ROOT/share/man:MANPATH
export INFOPATH=$GCCX_ROOT/share/info:$INFOPATH
export LD_LIBRARY_PATH=$GCCX_ROOT/lib:$GCCX_ROOT/lib:$LD_LIBRARY_PATH
export LD_RUN_PATH=$GCCX_ROOT/lib:$GCCX_ROOT/lib:$LD_RUN_PATH
export LIBRARY_PATH=$GCCX_ROOT/lib:$GCCX_ROOT/lib:$LIBRARY_PATH
export INCLUDE_PATH=$GCCX_ROOT/include:$INCLUDE_PATH
export CPLUS_INCLUDE_PATH=$GCCX_ROOT/include:$CPLUS_INCLUDE_PATH
export C_INCLUDE_PATH=$GCCX_ROOT/include:$C_INCLUDE_PATH
#######################################################################

  The include script to use gcc 5.4.0 differs in only the first line...

#######################################################################
export GCCX_ROOT=$HOME/gcc540
#######################################################################

  Would the various "export" commands work if inserted into make.conf?
Actually, would they even need the "export " portion of the declaration?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On Wed, Apr 26, 2017 at 12:26:19AM +0200, Andreas K. Huettel wrote:
> Am Sonntag, 23. April 2017, 14:35:48 CEST schrieb Michał Górny:
> > Hi,
> > 
> > I'm thinking of masking old versions of sys-devel/gcc, in particular
> > older than the 4.9 branch.
> > 
> 
> Masking is fine; some time later (maybe in a few months) I'd even suggest 
> masking all of gcc-4. After all, unmasking them if you really need them is 
> rather easy.
> 
> About removing them (what William proposed), I'd keep what we have now. We had 
> this discussion already in lots of detail in the past, and convincing points 
> were made to keep one of each 4.x ...

I"m not talking about 4.x, just 2.x and 3.x. I'm not even talking about
masking 4.x. I'm sure there may be reasons to keep these in the tree.

I'm just questioning why we need 2.x and 3.x in the main tree.

As has been said by others on the thread, those really old versions
could probably go to the toolchain overlay.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

On Thu, 27 Apr 2017 10:27:08 -0500 William Hubbs wrote:
> On Wed, Apr 26, 2017 at 12:26:19AM +0200, Andreas K. Huettel wrote:
> > Am Sonntag, 23. April 2017, 14:35:48 CEST schrieb Michał Górny:
> > > Hi,
> > > 
> > > I'm thinking of masking old versions of sys-devel/gcc, in particular
> > > older than the 4.9 branch.
> > > 
> > 
> > Masking is fine; some time later (maybe in a few months) I'd even suggest 
> > masking all of gcc-4. After all, unmasking them if you really need them is 
> > rather easy.
> > 
> > About removing them (what William proposed), I'd keep what we have now. We had 
> > this discussion already in lots of detail in the past, and convincing points 
> > were made to keep one of each 4.x ...
> 
> I"m not talking about 4.x, just 2.x and 3.x. I'm not even talking about
> masking 4.x. I'm sure there may be reasons to keep these in the tree.
> 
> I'm just questioning why we need 2.x and 3.x in the main tree.

I still use fortran software which needs 3.4.x g77. There may be
similar cases for people to use 2.95. IMO removing older gcc will
do much more harm than good.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:
> The most important goal of having the packages masked is that it would
> cause Portage to verbosely complain whenever the users have it
> installed. With appropriate comment (displayed by Portage), we could
> clearly inform users that they need to upgrade gcc and switch to a new
> version to ensure that majority of packages work.

Portage already tells users to run --depclean after each @world update, 
which will remove old gcc versions (except if stuff like gcj-jdk is 
installed).
What your proposal does is to remind users who don't act on the first 
message, or who never do world updates, do I get this right?


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

On śro, 2017-04-26 at 11:42 +0200, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
> > The most important goal of having the packages masked is that it would
> > cause Portage to verbosely complain whenever the users have it
> > installed. With appropriate comment (displayed by Portage), we could
> > clearly inform users that they need to upgrade gcc and switch to a new
> > version to ensure that majority of packages work.
> 
> Portage already tells users to run --depclean after each @world update, 
> which will remove old gcc versions (except if stuff like gcj-jdk is 
> installed).
> What your proposal does is to remind users who don't act on the first 
> message, or who never do world updates, do I get this right?

Yes, mostly those users. However, it will also remind those who decided
not to upgrade for some reason, e.g. planned to do it later, then
forgot.

Plus those users who have old systems and attempt to do larger upgrades
-- as an explicit note that they need to take special care to switch gcc
before upgrading most of their system.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]