I recently used 2006.0 to build a new system on a HT Pentium 4 3.4 GHz box. Grub kept segfaulting when attempting to install it to my MBR, and trying to use tabcompletion from within the grub shell resulted in very strange results. Running strace provided no helpful information. Eventually I realized that the default CFLAGS now contain -O3 (I had not used this architecture before). Bumping it down to -O2 or lower and re-emerging grub fixed the problem. The folks at #grub, who had been trying to help me figure out the problem, confirmed that grub tends to have issues building with optimizations, and that they often see Gentoo folks with strange grub problems that are probably related to this. When trying to figure out the problem, I actually found several threads off my Google searches that related to various other issues people had with grub that were caused by using optimizations. I would suggest one or more of the following: 1) Grub is forced to use -O2 or lower, probably -O0 to be safe (probably the best idea...why does the boot loader really need to be optimized anyways), or 2) A warning is put in make.conf above the CFLAGS variable (probably not a good idea, several warnings already), or 3) A warning is displayed while building grub that optimizations may cause unpredictable results (probably good in combination with #1, if optimization levels higher than 0 are detected)
(Changing to blocker severity, as with the default configuration off the 2006.0 profile, this can cause grub to not be able to be installed, and therefore blocks finishing the installation of Gentoo).
-O3 is definitely not default...
make.conf.example: # Decent examples: # #CFLAGS="-mcpu=athlon-xp -O3 -pipe" #CFLAGS="-march=pentium3 -O3 -pipe"
grub ignores user CFLAGS flags already and has for quite a while
If grub ignored user CFLAGS, changing the following line in make.conf: CFLAGS="-march=pentium4 -O3 -pipe" to CFLAGS="-march=pentium4 -O2 -pipe" would have no effect. But it does, repeatedly. Changing it back to -O3 and re-emerging grub (and nothing else, just grub) causes it to act incorrectly and segfault again. Changing it once more to -O2 and re-emerging grub makes it work. If the grub ebuild is supposed to be ignoring CFLAGS, there's a bug in it.
well you still havent posted `emerge info` `emerge grub >& log` would be useful as well
I didn't post emerge info because I know what the cause of the problem is. I'm not having a problem and asking folks to look through my emerge info and figure out what's going on. I know exactly what the problem is. Whatever, I'll attach emerge info as well as logs of emerging grub with -O2 and -O3.
Created attachment 84958 [details] emerge --info
Created attachment 84959 [details] emerge grub with -O3
Created attachment 84960 [details] emerge grub with -O2
you're using custom-cflags that means *you* get to pick up the broken pieces
You clearly didn't read the bug report. I copied over the make.conf.example to make.conf and proceeded to edit it. This is not an unreasonable thing to do, as the normal make.conf included on 2006.0 has no comments, does not contain all variables that can be set, etc. You do this for plenty of other files, for instance /etc/conf.d/net.example I then proceeded to set my CFLAGS based on the information provided in make.conf.example: # Decent examples: # #CFLAGS="-mcpu=athlon-xp -O3 -pipe" #CFLAGS="-march=pentium3 -O3 -pipe" The point is that if using those (substituting my processor, pentium4, in march) is considered a custom CFLAG that will be unsupported, then they are not decent examples and should not be portrayed to users as such. You can't provide an example to users and then tell them it's their fault when they take your example and things break. Furthermore, from make.conf.example: # Please note that if you experience strange issues with a package, it may be # due to gcc's optimizations interacting in a strange way. Please test the # package (and in some cases the libraries it uses) at default optimizations # before reporting errors to developers. That's exactly what I did. GCC's optimizations caused grub to screw up, I tested it at default optimizations (-O0) and it worked. So now I'm reporting the error to you as an ebuild problem, as upstream simply says "don't use optimizations" and are not going to (or can't) fix the problems. One of the earlier comments to this bug stated that the grub ebuild is supposed to disable optimizations anyways. You can either bitch at me for following the instructions provided -- which I did -- or you can fix the ebuild to disable optimizations correctly, or post a warning to others that grub doesn't like optimizations. It boggles my mind that missing buttons in xmms warrant a comment in make.conf.example (bug #50616) but a bootloader that fails to install, thus rendering your Gentoo installation unbootable and unusable, gets a smack on the wrist for using "custon" CFLAGS considered by Gentoo as "decent examples." For the record, as I said before, the folks at #grub said they see more Gentoo users with problems than anyone else. Isn't that kind of embarassing? Maybe fixing the ebuild to disable optimizations would help erase that dubious distinction.
i clearly did you have USE=custom-cflags NOTABUG
Saying I was using USE=custom-cflags instead of simply saying I was using custom-cflags (which makes it sound like my make.conf CFLAG setting) is much more useful. I had no idea that I was using custom-cflags. Wouldn't it be a good idea to display a warning during emerging if custom-cflags is on? Many other packages display a warning if the user has dangerous USE flag settings.
> Saying I was using USE=custom-cflags instead of simply saying I was using > custom-cflags (which makes it sound like my make.conf CFLAG setting) is much > more useful. bugzilla crashed before i could correct the comment > Wouldn't it be a good idea to display a warning during emerging if > custom-cflags is on? no ... the mere fact that it's a USE flag is hint enough that we really really dont want you screwing around
>no ... the mere fact that it's a USE flag >is hint enough that we really really >dont want you screwing around 1) That assumes you know you have the USE flag enabled 2) USE flags are not normally there to keep you from screwing around, they're there to enable or disable optional features 3) Going by that logic, you should remove all USE-flag-related warnings from all other ebuilds
> 1) That assumes you know you have the USE flag enabled well, if you dont know you enabled it, then it must have been little magic gremlins ... custom-cflags is not enabled anywhere by default
It was apparently enabled on the machine I took the USE string from; I wanted to set this new machine up to be very similar. What about #2 and #3?
> 2) USE flags are not normally there to keep you from screwing around, they're > there to enable or disable optional features this USE flag was added because some people still wanted to use their own CFLAGS since the default was to always ignore them > 3) Going by that logic, you should remove all USE-flag-related warnings from > all other ebuilds i dont control all othe rebuilds
>i dont control all othe rebuilds Okay, so how about adding a warning to yours so that users can be made aware if they're about to do something potentially harmful, like many of the other, more helpful ebuilds?
no the custom-cflags USE descriptions say "not supported"
I don't know what USE description you're looking at, but nowhere in my /usr/portage/profiles/use.desc or /usr/portage/profiles/use.local.desc, synced as of last night, does it say that custom-clfags is "not supported." Not that having the description say "not supported" (which it doesn't) helps if you're not aware you turned that USE flag on. Adding a warning to the ebuild, displayed during emerge if custom-cflags is on, is much more clear and helpful.
$ grep custom-cflags use.local.desc app-emulation/xen:custom-cflags - Use CFLAGS from /etc/make.conf rather than the default Xen CFLAGS (not supported) app-emulation/xen-tools:custom-cflags - Use CFLAGS from /etc/make.conf rather than the default Xen CFLAGS (not supported) media-video/mplayer:custom-cflags - Enables custom cflags (not supported) sys-boot/grub:custom-cflags - Enables custom cflags (not supported)
That's because you, or someone else, just added them. Download a snapshot of Portage from 4/18/2006 from one of the mirrors and check out the corresponding use.local.desc, and you'll find that "(not supported)" does not appear in relation to the custom-cflags USE flag. Although I suspect you're already fully aware of this fact, and are trying to cover up your negligence. Probably trying to pick up *your* "broken pieces." Why not do the useful thing and add a warning to the grub ebuild if someone has custom-clfags enabled?
i know i just added them
*** Bug 140287 has been marked as a duplicate of this bug. ***
