| Summary: | sys-boot/grub-9999 doesn't boot when compiled with gcc-4.5 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | cyrillic <cyrilmaley> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | alexxy, b.buschinski, chrsclmn, dschridde+gentoobugs, hirakendu, kanelxake, kernelpanic, nisselarsson000, polynomial-c, radhermit, tdalman, Wizzleby |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 296658 | ||
| Attachments: | grub-9999.ebuild | ||
|
Description
cyrillic
2010-05-02 21:51:10 UTC
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]
grub-9999.ebuild
This simplified ebuild is working.
So far I have only tested it on amd64.
Comment on attachment 243065 [details]
grub-9999.ebuild
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). |
