* [gentoo-dev] RFC: masking old versions of sys-devel/gcc @ 2017-04-23 12:35 Michał Górny 2017-04-24 16:01 ` William Hubbs ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Michał Górny @ 2017-04-23 12:35 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-23 12:35 [gentoo-dev] RFC: masking old versions of sys-devel/gcc Michał Górny @ 2017-04-24 16:01 ` William Hubbs 2017-04-24 17:59 ` Guilherme Amadio 2017-04-25 22:26 ` Andreas K. Huettel 2017-04-26 9:42 ` Chí-Thanh Christopher Nguyễn 2 siblings, 1 reply; 15+ messages in thread From: William Hubbs @ 2017-04-24 16:01 UTC (permalink / raw To: gentoo-dev; +Cc: mgorny [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-24 16:01 ` William Hubbs @ 2017-04-24 17:59 ` Guilherme Amadio 2017-04-25 16:26 ` William Hubbs 0 siblings, 1 reply; 15+ messages in thread From: Guilherme Amadio @ 2017-04-24 17:59 UTC (permalink / raw To: gentoo-dev, mgorny 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-24 17:59 ` Guilherme Amadio @ 2017-04-25 16:26 ` William Hubbs 2017-04-25 16:44 ` Guilherme Amadio 0 siblings, 1 reply; 15+ messages in thread From: William Hubbs @ 2017-04-25 16:26 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-25 16:26 ` William Hubbs @ 2017-04-25 16:44 ` Guilherme Amadio 2017-04-25 18:38 ` Francesco Riosa 0 siblings, 1 reply; 15+ messages in thread From: Guilherme Amadio @ 2017-04-25 16:44 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-25 16:44 ` Guilherme Amadio @ 2017-04-25 18:38 ` Francesco Riosa 0 siblings, 0 replies; 15+ messages in thread From: Francesco Riosa @ 2017-04-25 18:38 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-23 12:35 [gentoo-dev] RFC: masking old versions of sys-devel/gcc Michał Górny 2017-04-24 16:01 ` William Hubbs @ 2017-04-25 22:26 ` Andreas K. Huettel 2017-04-26 0:37 ` Francesco Riosa 2017-04-27 15:27 ` William Hubbs 2017-04-26 9:42 ` Chí-Thanh Christopher Nguyễn 2 siblings, 2 replies; 15+ messages in thread From: Andreas K. Huettel @ 2017-04-25 22:26 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-25 22:26 ` Andreas K. Huettel @ 2017-04-26 0:37 ` Francesco Riosa 2017-04-26 9:32 ` Andreas K. Huettel 2017-04-27 15:27 ` William Hubbs 1 sibling, 1 reply; 15+ messages in thread From: Francesco Riosa @ 2017-04-26 0:37 UTC (permalink / raw To: gentoo development [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-26 0:37 ` Francesco Riosa @ 2017-04-26 9:32 ` Andreas K. Huettel 2017-04-26 14:59 ` Mike Gilbert 2017-04-27 2:08 ` Walter Dnes 0 siblings, 2 replies; 15+ messages in thread From: Andreas K. Huettel @ 2017-04-26 9:32 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-26 9:32 ` Andreas K. Huettel @ 2017-04-26 14:59 ` Mike Gilbert 2017-04-27 2:08 ` Walter Dnes 1 sibling, 0 replies; 15+ messages in thread From: Mike Gilbert @ 2017-04-26 14:59 UTC (permalink / raw To: Gentoo Dev 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-26 9:32 ` Andreas K. Huettel 2017-04-26 14:59 ` Mike Gilbert @ 2017-04-27 2:08 ` Walter Dnes 1 sibling, 0 replies; 15+ messages in thread From: Walter Dnes @ 2017-04-27 2:08 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-25 22:26 ` Andreas K. Huettel 2017-04-26 0:37 ` Francesco Riosa @ 2017-04-27 15:27 ` William Hubbs 2017-04-27 22:56 ` Andrew Savchenko 1 sibling, 1 reply; 15+ messages in thread From: William Hubbs @ 2017-04-27 15:27 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-27 15:27 ` William Hubbs @ 2017-04-27 22:56 ` Andrew Savchenko 0 siblings, 0 replies; 15+ messages in thread From: Andrew Savchenko @ 2017-04-27 22:56 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-23 12:35 [gentoo-dev] RFC: masking old versions of sys-devel/gcc Michał Górny 2017-04-24 16:01 ` William Hubbs 2017-04-25 22:26 ` Andreas K. Huettel @ 2017-04-26 9:42 ` Chí-Thanh Christopher Nguyễn 2017-04-26 12:22 ` Michał Górny 2 siblings, 1 reply; 15+ messages in thread From: Chí-Thanh Christopher Nguyễn @ 2017-04-26 9:42 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc 2017-04-26 9:42 ` Chí-Thanh Christopher Nguyễn @ 2017-04-26 12:22 ` Michał Górny 0 siblings, 0 replies; 15+ messages in thread From: Michał Górny @ 2017-04-26 12:22 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2017-04-27 22:56 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-04-23 12:35 [gentoo-dev] RFC: masking old versions of sys-devel/gcc Michał Górny 2017-04-24 16:01 ` William Hubbs 2017-04-24 17:59 ` Guilherme Amadio 2017-04-25 16:26 ` William Hubbs 2017-04-25 16:44 ` Guilherme Amadio 2017-04-25 18:38 ` Francesco Riosa 2017-04-25 22:26 ` Andreas K. Huettel 2017-04-26 0:37 ` Francesco Riosa 2017-04-26 9:32 ` Andreas K. Huettel 2017-04-26 14:59 ` Mike Gilbert 2017-04-27 2:08 ` Walter Dnes 2017-04-27 15:27 ` William Hubbs 2017-04-27 22:56 ` Andrew Savchenko 2017-04-26 9:42 ` Chí-Thanh Christopher Nguyễn 2017-04-26 12:22 ` Michał Górny
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox