Compiling and installing grub appears to work fine, but booting stops with an error instead of displaying the grub menu.
Steps to Reproduce:
1. emerge =grub-9999
Welcome to GRUB!
out of range pointer 0x7fde0
Aborted. Press any key to exit.
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
dev-lang/python: 2.6.5-r1, 3.1.2-r2
sys-devel/autoconf: 2.13, 2.65
sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1
CFLAGS="-O2 -march=nocona -pipe"
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"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
report it upstream. live ebuilds are not our problem.
Just for the record, I can also reproduce it with 1.98
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.
feel free to debug it and figure things out. grub-2 ebuilds arent really supported.
Created attachment 243065 [details]
This simplified ebuild is working.
So far I have only tested it on amd64.
Comment on attachment 243065 [details]
this has a lot of problems, ignoring all the features you simply cut out
The main feature I was actually looking for is :
a bootloader that boots
The rest of the features were not interesting to me.
that may be, but it doesnt get changes into the tree
So what the grub2 ebuild needs to compile on GCC 4.5 is a RESTRICT="strip"?
i'm not adding RESTRICT=strip. there is already a STRIP_MASK ... if it is insufficient, then expand it to cover the files needed.
Same problem exist here
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/grub-shell.in) 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.
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?
(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.
(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.
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.
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
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?
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.
thanks for the update
(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.
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).