I installed a system from the i486 stage3. I have CHOST="i486-pc-linux-gnu". When I don't say otherwise in make.conf, I get these defaults: # emerge --info|grep FLAGS= CFLAGS="-O2 -march=i686 -pipe" CXXFLAGS="-O2 -march=i686 -pipe" FCFLAGS="-O2 -march=i686 -pipe" FFLAGS="-O2 -march=i686 -pipe" LDFLAGS="-Wl,--hash-style=gnu -Wl,-O1 -Wl,--as-needed" The problem is the i686. Reproducible: Always
Created attachment 348006 [details] emerge --info (this time with all the *FLAGS set explicitly to "" in make.conf)
(In reply to comment #0) > CFLAGS="-O2 -march=i686 -pipe" > CXXFLAGS="-O2 -march=i686 -pipe" > FCFLAGS="-O2 -march=i686 -pipe" > FFLAGS="-O2 -march=i686 -pipe" > LDFLAGS="-Wl,--hash-style=gnu -Wl,-O1 -Wl,--as-needed" The above settings are all inherited from ${PORTDIR}/profiles/arch/x86/make.defaults, and portage it bound to respect the profile settings. So, there's really nothing that portage can do about it. Maybe re-assign to the docs team or something?
(In reply to comment #2) > it. Maybe re-assign to the docs team or something? That sounds sensible. A warning should be included in the Handbook and in the starting make.conf in the i486 stage3. I suppose changing the -march to i486 in make.defaults is not worth it.
I'm adding release@gentoo to CC: - please, claim the bug (or pass it on to docs-team@gentoo); I can't seem to be able to re-assign it.
we have no control over what goes into make.conf; some other team is responsible for installed files. nothing we do goes into the end-user's system. what is it you think we should do for the handbook, exactly?
(In reply to comment #5) > we have no control over what goes into make.conf; some other team is > responsible for installed files. nothing we do goes into the end-user's > system. Yes, I'm asking release@gentoo to handle that. > what is it you think we should do for the handbook, exactly? Please consider adding a note to it for the users of the i486 stage3: if you remove or comment-out C/CXX(/FC/FF)FLAGS in make.conf, emerge will start compiling everything with -march=i686 as that's the profile default.
(In reply to comment #6) > (In reply to comment #5) > > we have no control over what goes into make.conf; some other team is > > responsible for installed files. nothing we do goes into the end-user's > > system. > > Yes, I'm asking release@gentoo to handle that. What release does is provide stages built using the values in the tree. Since the x86 arch team set the values for the x86 profile, what are we expected to do? This is also the first bug we get about this issue for a very long time (I'm following release bugs for more than 2 years) and we haven't done any changes to catalyst or the x86 spec files recently that affect CFLAGS on make.conf. > > what is it you think we should do for the handbook, exactly? > > Please consider adding a note to it for the users of the i486 stage3: if you > remove or comment-out C/CXX(/FC/FF)FLAGS in make.conf, emerge will start > compiling everything with -march=i686 as that's the profile default. I wonder why no one complained before. Can we conclude that no one is using i486 any more?
(In reply to comment #7) > (In reply to comment #6) > > Please consider adding a note to it for the users of the i486 stage3: if you > > remove or comment-out C/CXX(/FC/FF)FLAGS in make.conf, emerge will start > > compiling everything with -march=i686 as that's the profile default. > > I wonder why no one complained before. Can we conclude that no one is using > i486 any more? we don't really even talk about i486 stages -- i seem to recall releng/arch teams dropping their status to "experimental" some years ago, since they're at the edge of easy maintenance, and the "x86" (or i586-ish) stages were good enough. anything older is a vanishingly small use case. i'm inclined to just drop the i486 references entirely from the handbook, and maybe get the stages pushed to one of the "experimental" subdirs rather than in the top-level x86 archdir.
(In reply to comment #7) > What release does is provide stages built using the values in the tree. > Since the x86 arch team set the values for the x86 profile, what are we > expected to do? I'm saying that a comment should be put into the default make.conf in the i486 stage3. A comment just above C(XX)FLAGS saying "don't remove this or comment it out, lest i686 binaries will befall thee". > I wonder why no one complained before. Can we conclude that no one is using > i486 any more? Either that (but hey - now there's me:) ) or that the i486 users have CFLAGS in make.conf and never get hit by the -march=i686 default. But yeah, my reason for installing the i486 stage3 has nothing to do with the 80486 processor and i686 binaries wouldn't destroy the system for me. They would quietly make it useless w.r.t. its purpose, though. Yes, I could've started from the i686 stages.
Is there any reason that -march=i686 needs to be set in the profile's flags at all? It seems to me that just plain CFLAGS="-O2 -pipe" would be just fine.
the i486 stages ship with -march=i486 in their make.conf. so it'd only be a problem if you turned off all the settings. our gcc does default to the -march according to the CHOST: x86) # Default arch for x86 is normally i386, lets give it a bump # since glibc will do so based on CTARGET anyways confgcc+=( --with-arch=${CTARGET%%-*} ) so the -march is generally redundant. but i don't see the big deal with people setting their own things for i386/i486/i586. creating subprofiles for each one seems like a lot of effort for no real gain.
x86 arch team, this is your call. FWIW, I think Ben is right, we shouldn't be setting i686 in the profile and overriding in make.conf for i486.
@x86: any progress / comments on this?
not something for the docs-team to take care of; it's on the arches to figure out what goes in the appropriate configs.
My personal comment/point (not from the x86 team as a whole): 1) I think I'm one of the few arch testers that actually use x86 hardware (instead of a x86 VM) and I haven't seen any i486 or i586 hardware in years. i{4,5}68 is not really tested by the x86 team. 2) If I'm correct the only stages present are i686. I understood from the comments here that those can run on i{4,5}86. 3) If you're so old-school to run i{4,5}86, I'm pretty sure you have the knowledge to resolve the issue mentioned in this bug yourself. 4) Really, building from source with something less that 100MHz... that's a hobby and not something serious... see point 3. I would say, close as WONTFIX/OBSOLETE.
We are still building i486 stages - at least we're "trying" to build. http://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3-i486/ The i686 stages were meant to be the ones requiring at least an i686. http://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3-i686/ If the x86 team thinks there's no point in building the i486 stages, we can just stop trying to do it.
(In reply to Myckel Habets from comment #15) > My personal comment/point (not from the x86 team as a whole): > > 1) I think I'm one of the few arch testers that actually use x86 hardware > (instead of a x86 VM) and I haven't seen any i486 or i586 hardware in years. > i{4,5}68 is not really tested by the x86 team. > 2) If I'm correct the only stages present are i686. I understood from the > comments here that those can run on i{4,5}86. > 3) If you're so old-school to run i{4,5}86, I'm pretty sure you have the > knowledge to resolve the issue mentioned in this bug yourself. > 4) Really, building from source with something less that 100MHz... that's a > hobby and not something serious... see point 3. > > I would say, close as WONTFIX/OBSOLETE. Please don't change the status to unconfirmed as this is clearly confirmed. You (x86 arch team) can close it as OBSOLETE / WONTFIX, but let's not pretend the issue is real.
(In reply to Jorge Manuel B. S. Vicetto from comment #17) > > Please don't change the status to unconfirmed as this is clearly confirmed. > You (x86 arch team) can close it as OBSOLETE / WONTFIX, but let's not > pretend the issue is real. Sorry, that was an accident. I didn't mean to change that. Just to express my opinion.
(In reply to Jorge Manuel B. S. Vicetto from comment #16) > We are still building i486 stages - at least we're "trying" to build. > http://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3-i486/ > > The i686 stages were meant to be the ones requiring at least an i686. > http://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3-i686/ > > If the x86 team thinks there's no point in building the i486 stages, we can > just stop trying to do it. How often are the i486 stages downloaded? And is there a way to build for i486 if there is no stage3 (although not supported)?
(In reply to Myckel Habets from comment #18) > (In reply to Jorge Manuel B. S. Vicetto from comment #17) > > > > Please don't change the status to unconfirmed as this is clearly confirmed. > > You (x86 arch team) can close it as OBSOLETE / WONTFIX, but let's not > > pretend the issue is real. > > Sorry, that was an accident. I didn't mean to change that. Just to express > my opinion. np, it happens. BTW, I meant "let's not pretend the issue *isn't* real" (In reply to Myckel Habets from comment #19) > How often are the i486 stages downloaded? I have no idea. I'll ask to the other @infra members if we have any ready stats, although we can only count data from Gentoo controlled mirrors. > And is there a way to build for > i486 if there is no stage3 (although not supported)? If we drop the i486, we'll have to use stage3-i686 for the install-cd (it's currently built from the i486 stage3). IIRC, using an i686 stage and compiling the kernel for i686 will either cause it not to boot or may cause random breaks / kernel oops when programs try to use processor features not available in the < i686 processors.
(In reply to Jorge Manuel B. S. Vicetto from comment #20) > (In reply to Myckel Habets from comment #18) > > And is there a way to build for > > i486 if there is no stage3 (although not supported)? > > If we drop the i486, we'll have to use stage3-i686 for the install-cd (it's > currently built from the i486 stage3). > IIRC, using an i686 stage and compiling the kernel for i686 will either > cause it not to boot or may cause random breaks / kernel oops when programs > try to use processor features not available in the < i686 processors. But it isn't necessarily required to start from a Gentoo live CD. And one could still do a cross-compilation if someone wanted to install on a i486 system, right? I checked the forums and some posts regarding i486/i586 are still pretty recent, so I guess people are still using it. Reading one time through the whole bug post, to me it seems that the best answer already has been given in comment 10. I guess compilers these days also default to --march=native, which would solve the problem, but still keeps i486 open as an option. Not sure how that would work out with releasing the i486 stage3 tarball?
If the X86 arch team doesn't reply in the next month and if people still care about this bug, I'll update our scripts and just stop building i486 stages. So @x86, it's up to you.
I am actively using the i486 port. While it is not a production platform, it is a very useful teaching tool. Simple hardware is much easier for students to understand compared to the complex systems made today. Also, students can submit patches for old hardware, building a portfolio of programming experience. Please do not drop this platform. I am using it to teach both operating system basics and also kernel programming. You provide the essential i486 userland that the _still supported_ i486 kernels very much need.
A compromise solution could be to use "-march=i486 -mtune=i686". This would make it compatible with i486, but would tune the code to work best on i686.
This has become more a pressing problem. See bug 654080. We really need to make these x86 CFLAGS generic.
Status for release@ here is... everything's fine. Catalyst can and is producing i486 stages. The bug remains open only because of what the title literally says: that the x86 profile defaults to -march=i686.
I think we're planning on fixing this for 23.0 by doing x86 properly with subprofiles.
(In reply to Sam James from comment #27) > I think we're planning on fixing this for 23.0 by doing x86 properly with > subprofiles. This should be fixed in the 23.0 profiles.
(In reply to Andreas K. Hüttel from comment #28) > (In reply to Sam James from comment #27) > > I think we're planning on fixing this for 23.0 by doing x86 properly with > > subprofiles. > > This is fixed in the 23.0 profiles (available and stable now). Closing.
