Bug 13439 - missing efiemu32/64.o in grub2 32 bit
Summary: missing efiemu32/64.o in grub2 32 bit
Status: RESOLVED WONTFIX
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Barry Jackson
QA Contact:
URL:
Whiteboard: OK
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-27 11:16 CEST by Nicolas Pomarède
Modified: 2014-08-04 01:14 CEST (History)
3 users (show)

See Also:
Source RPM: grub2-2.00-59.mga5
CVE:
Status comment:


Attachments

Description Nicolas Pomarède 2014-05-27 11:16:28 CEST
Description of problem:

while trying to multiboot using grub2, I get an error when starting OSX 64 bit kernel "file /grub2/i386-pc/efiemu64.o not found"

I see that this file is available in the x86_64 rpm, but not in the i586 rpm (I'm using a 32 bit version of Mageia)

The grub2 entries are the ones autodetected by grub2 using os-prober.

Does it means that grub2 32 bit is not able to start a 64 bit version of OSX ? (but I can succesfully start Window 7 on the same multiboot, and this is also supposed to be a 64 bit OS) 

As requested by Barry zen25000@zen.co.uk, I'm opening this BR to keep track of the problem (according to him it could be related to the options used to build the 32 bit version of grub2)

Note that on opensuse and fedora, efiemu32.o and efiemu64.o are also missing from the 32 bit packages, but maybe no one noticed it doesn't work in this case.

Reproducible: 

Steps to Reproduce:
Comment 1 Barry Jackson 2014-05-27 19:19:48 CEST
From what I can gather from upstream grub2, in order to fix this we need to be building grub2 with "gcc-multilib" as a BuildRequire and use:
CFLAGS="-m64 -nostdlib -O2 -mcmodel=large -mno-red-zone" for both i586 and x86_64 builds.

We don't have a gcc-multilib package and AFAICT we don't build gcc with --enable-multilib so cc-ing tmb for some help ;)

Assignee: bugsquad => zen25000
Whiteboard: (none) => OK
CC: (none) => tmb, zen25000

Comment 2 Barry Jackson 2014-06-11 01:36:56 CEST
Nicolas,
It seems that this is not currently supported by our build system, so it's unlikely to happen in the immediate future.

I'm somewhat puzzled as to why you are using 32 bit Mageia on 64 bit hardware?

I'm also not sure whether to leave this bug open or close it as wontfix. Thomas?
Comment 3 Nicolas Pomarède 2014-06-11 10:51:19 CEST
For personnal projects and compatibility reasons, I need to use a 32 bit system.

Too bad it's not possible.
Comment 4 Barry Jackson 2014-06-11 12:36:04 CEST
What 32 bit software will not run on a Mageia 64 bit system? 
32 bit repos are enabled by default in Mga x86_64 install, so 32 bit libs are all available.
Comment 5 Nicolas Pomarède 2014-06-11 12:41:31 CEST
My own software :)  Low level emulator, with memory access / endianess to handle, and I need a machine in 32 bit to ensure it works fine in 32 bit :)
Comment 6 Sander Lepik 2014-06-11 12:43:27 CEST
linux32 (http://linux.die.net/man/8/linux32) should be your friend.

CC: (none) => mageia

Comment 7 Nicolas Pomarède 2014-06-11 12:49:51 CEST
This is not just about running the program, but having the whole compilation chain as a normal 32 bit user would have.
I want to validate that everything compiles/works on a genuine 32 bit distrib. I could use cross compilation for different arch / cpu, but that's not the point, this PC is used to have a 32 bit distrib to be able to check the whole process in the exact condition of a full 32 bit distrib.
But this is getting slightly off topic :)
Comment 8 Sander Lepik 2014-06-11 13:12:50 CEST
Well, I'm using linux32 with iurt to test compilation on 32-bit distrib and so long it has worked like on real 32-bit system.
Comment 9 Barry Jackson 2014-06-11 14:06:21 CEST
(In reply to Sander Lepik from comment #8)
> Well, I'm using linux32 with iurt to test compilation on 32-bit distrib and
> so long it has worked like on real 32-bit system.

Exactly - I do the same.
Comment 10 Barry Jackson 2014-08-04 01:14:19 CEST
Closing as there is no way to enable this currently.

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX


Note You need to log in before you can comment on or make changes to this bug.