Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 318215 - sys-boot/grub-9999 doesn't boot when compiled with gcc-4.5
Summary: sys-boot/grub-9999 doesn't boot when compiled with gcc-4.5
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: High normal with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Blocks: gcc-4.5
  Show dependency tree
Reported: 2010-05-02 21:51 UTC by cyrillic
Modified: 2011-02-28 05:05 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---

grub-9999.ebuild (grub-9999.ebuild,930 bytes, text/plain)
2010-08-15 14:26 UTC, cyrillic

Note You need to log in before you can comment on or make changes to this bug.
Description cyrillic 2010-05-02 21:51:10 UTC
Compiling and installing grub appears to work fine, but booting stops with an error instead of displaying the grub menu.

Reproducible: Always

Steps to Reproduce:
1. emerge =grub-9999
2. grub-install
3. reboot

Actual Results:  
GRUB loading.
Welcome to GRUB!

out of range pointer 0x7fde0
Aborted. Press any key to exit.

Expected Results:  
Normal boot sequence

# emerge --info
Portage 2.2_rc67 (default/linux/amd64/10.0, gcc-4.5.0, glibc-2.11.1-r0, 2.6.34-rc6 x86_64)
System uname: Linux-2.6.34-rc6-x86_64-AMD_Phenom-tm-_II_X4_965_Processor-with-gentoo-2.0.1
Timestamp of tree: Sun, 02 May 2010 13:45:01 +0000
app-shells/bash:     4.1_p5
dev-lang/python:     2.6.5-r1, 3.1.2-r2
dev-util/cmake:      2.8.1-r1
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.1-r1
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.13, 2.65
sys-devel/automake:  1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:  2.20.1
sys-devel/gcc:       4.5.0
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.33
CFLAGS="-O2 -march=nocona -pipe"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -march=nocona -pipe"
FEATURES="protect-owned sandbox sfperms strict unmerge-orphans"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTDIR_OVERLAY="/usr/portage/local/cross /usr/portage/local/gnome /usr/portage/local/x11 /usr/portage/local/fixes"
USE="X a52 aac acpi alsa amd64 avahi boost bzip2 cairo cracklib css cups curl custom-cflags custom-cpuopts custom-optimization cxx dbus dri dts dvd encode exceptions expat fbcon ffmpeg flac fortran gallium gif glib gnome gpm graphite gstreamer gtk imagemagick ithreads jpeg lcms mmx mmxext mp2 mp3 mpeg multilib ncurses nls nptl offensive ogg opengl openmp pam pcre png policykit python3 qt3support readline samba slang spell sqlite sse sse2 sse3 ssl svg theora threads tiff udev unicode usb vorbis x264 xcb xorg xulrunner xv xvid zeroconf zlib" ALSA_PCM_PLUGINS="*" ELIBC="glibc" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LINGUAS="en" RUBY_TARGETS="ruby18" SANE_BACKENDS="*" USERLAND="GNU" VIDEO_CARDS="nouveau radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" 
Comment 1 SpanKY gentoo-dev 2010-05-06 18:09:28 UTC
report it upstream.  live ebuilds are not our problem.
Comment 2 Bernd Buschinski 2010-05-06 20:12:58 UTC
Just for the record, I can also reproduce it with 1.98
Comment 3 cyrillic 2010-08-05 23:51:31 UTC
I just upgraded to gcc-4.5.1 and got the same results, but I also noticed this.

gcc-4.5 and grub2 built with portage = broken
gcc-4.5 and grub2 built by hand = works ok

So, I guess this is not an upstream issue after all.
Comment 4 SpanKY gentoo-dev 2010-08-06 21:13:16 UTC
feel free to debug it and figure things out.  grub-2 ebuilds arent really supported.
Comment 5 cyrillic 2010-08-15 14:26:06 UTC
Created attachment 243065 [details]

This simplified ebuild is working.

So far I have only tested it on amd64.
Comment 6 SpanKY gentoo-dev 2010-08-15 17:53:37 UTC
Comment on attachment 243065 [details]

this has a lot of problems, ignoring all the features you simply cut out
Comment 7 cyrillic 2010-08-15 22:43:50 UTC
The main feature I was actually looking for is :
a bootloader that boots

The rest of the features were not interesting to me.
Comment 8 SpanKY gentoo-dev 2010-08-15 22:50:13 UTC
that may be, but it doesnt get changes into the tree
Comment 9 Nils Larsson 2010-09-06 20:35:18 UTC
So what the grub2 ebuild needs to compile on GCC 4.5 is a RESTRICT="strip"?
Comment 10 SpanKY gentoo-dev 2010-09-06 20:43:25 UTC
i'm not adding RESTRICT=strip.  there is already a STRIP_MASK ... if it is insufficient, then expand it to cover the files needed.
Comment 11 Alexey Shvetsov archtester gentoo-dev 2010-09-18 09:33:20 UTC
Same problem exist here
Comment 12 Xake 2010-10-20 08:20:07 UTC
I am afraid RESTRICT="strip" does not take care of the real problem.
If you run the testsuit (which is easily made working by emerging a qemu implementation and some sed to tests/ then with gcc-4.3 it passes fine, but with gcc-4.5 grub-shell hangs. And this is even before anything in the ebuild is supposed to strip files.
Comment 13 Xake 2010-11-23 08:03:56 UTC
So the reason why cyrillic's ebuild "worked" was not because he "removed features" or by letting grub handle the stripping.

What actually made grub2 work with qemu wrt his ebuild was that he did not pass "--disable-efiemu" to econf.

So everything else was just nice bug noise, lovely is it not?;)

So what we need to figure out is why --disable-efiemu works with gcc-4.4 and not with gcc-4.5. Maybe something gcc-4.5 optimizes differently?
Comment 14 Xake 2010-11-25 05:00:17 UTC
(In reply to comment #13)
> What actually made grub2 work with qemu wrt his ebuild was that he did not pass
> "--disable-efiemu" to econf.

Ok, I said wrong here. It was that he did not pass *-mm-debug, as for 1.98 it seem like this if you pass *-mm-debug to ./configure then you have a broken grub with gcc-4.5.

However -9999 seems to be fixed now, boots both in qemu and directly on my computer.
Comment 15 Dennis Schridde 2010-12-06 01:03:13 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > What actually made grub2 work with qemu wrt his ebuild was that he did not pass
> > "--disable-efiemu" to econf.
> Ok, I said wrong here. It was that he did not pass *-mm-debug, as for 1.98 it
> seem like this if you pass *-mm-debug to ./configure then you have a broken
> grub with gcc-4.5.
USE=debug (which should enable mm-debug) did not fix the issue for me, neither did FEATURES=nostrip.
Comment 16 Dennis Schridde 2010-12-06 01:11:09 UTC
P.S: This was using sys-boot/grub-1.98.
I've installed grub-1.98-1 from GRML and am back at a working system.
Comment 17 Jochen Schlick 2010-12-31 20:16:31 UTC
same for gcc-4.5.2:

gcc-4.5.2 -> sys-boot/grub-1.97.2-r2 -> out of range pointer 0x7fe80
gcc-4.5.2 -> sys-boot/grub-1.98-r8   -> out of range pointer 0x7fe80

Comment 18 Michelangelo Scopelliti 2011-01-12 19:11:17 UTC
I don't think it's a compiler problem. As per comment #14, the problem is the *-mm-debug option.
My gcc is "gcc (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2" and the system boots fine in qemu simply removing the $(use_enable debug mm-debug) line from grub-1.98.ebuild.
So, in the end, it seems to be a configure script issue, not a compiler one.

This said, is there any reason to disable efiemu? since vesafb and grub2 are not so happy together, I think efifb should be the way; shouldn't efiemu be used?
Comment 19 Xake 2011-01-14 10:29:45 UTC
Did I menation this is fixed upstream, and either we have to have someone hunting down what revision and port it to <=grub-1.98, add a ebuild based on a specific bzr-revision, or we simple wait for a new upstream release?

Also USE="debug" is not a workaround, as passing --<anything>-mm-debug for <=grub-1.98 makes grub unbootable.
So workaround is to remove *-mm-debug from ebuild IIRC (am using -9999 currently and not very motivated to break this working grub just to check), the fix is to use newer code from upstream.
Comment 20 SpanKY gentoo-dev 2011-01-14 21:17:40 UTC
thanks for the update
Comment 21 Nils Larsson 2011-01-17 01:10:04 UTC
(In reply to comment #19)
> ... we have to have someone hunting down what revision and port it to <=grub-1.98, add a ebuild based on a
> specific bzr-revision, or we simple wait for a new upstream release?

Looking at the bzr commit log there appears to be a 1.99-rc1 on its way.
Comment 22 hirakendu 2011-02-28 05:05:17 UTC
Thanks for all the info. I can confirm that grub-9999 works with gcc-4.5.2 with debug configure options removed from ebuild (and did not have time to test with debug options enabled).