Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 192286 - 32bit packages on amd64 require IA32 support in kernel (duh)
Summary: 32bit packages on amd64 require IA32 support in kernel (duh)
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: AMD64 Linux
: High trivial (vote)
Assignee: AMD64 Project
URL:
Whiteboard:
Keywords:
Depends on: 326693
Blocks:
  Show dependency tree
 
Reported: 2007-09-12 11:13 UTC by Pieter de Rijk
Modified: 2015-12-03 14:08 UTC (History)
3 users (show)

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


Attachments
Code snippet example for checking multilib options (snippet.txt,337 bytes, text/plain)
2007-09-13 00:11 UTC, Chris Gianelloni (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pieter de Rijk 2007-09-12 11:13:13 UTC
When installing nspluginwrapper, the install doesn't check if the kernel is compiled with the CONFIG_IA32_EMULATION enabled.

When you run the command nspluginwrapper -i [plugin_to_install] you will have an error message:
npviewer.bin: cannot execute binary file

Reproducible: Always

Steps to Reproduce:
1. Build a kernel with IA32 emulation support (grep IA32_EMULATION /usr/src/linux/.config. (output must be: "# CONFIG_IA32_EMULATION is not set" )
2. Install the kernel and boot from it.
3. Install nspluginwrapper (emerge nspluginwrapper)
4. Install netscape-flash
5. Run nspluginwrapper -i [location of libflash.so]

Actual Results:  
The result will be that bash will say:
"npviewer.bin: cannot execute binary file"

And no plugin is installed via the wrapper.

Expected Results:  
The installation process of nspluginwrapper must be aborted, because the kernel doesn't support IA32 emulation. So the user must be given a hint that the IA32 Emulation must get enabled.

Used kernel: 2.6.22.5 (from kernel.org)

nspluginwrapper version: 0.9.91.5
netscape-flash version.: 9.0.48.0-r1
mozilla-firefox version: 2.0.0.6
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2007-09-12 11:25:37 UTC
You'll have a _lot_ more trouble without IA32 that nspluginwrapper on multilib profiles; on no-multilib ones it's package.masked.

http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml#kernel
Comment 2 Chris Gianelloni (RETIRED) gentoo-dev 2007-09-12 16:28:26 UTC
While I do agree that anyone not following the FAQ is asking for trouble, I think the ebuilds themselves should be giving information about this.  It could be done via the multilib eclass or some other similar method.  Basically, we'd want the following:

- is this a multilib profile?
- does this profile require special kernel parameters?
- are those parameters enabled?
- if not, throw a WARNING

Of course, this would end up leaving a good bit of work to anyone who maintains a binary ebuild that has amd64 KEYWORDS, but I think I maintain a majority of them, if not most of them, and I'm willing to put in the work.  Users should be informed when they need to do something for an ebuild to work and we can never assume that they've read any of our wonderful documentation.
Comment 3 Chris Gianelloni (RETIRED) gentoo-dev 2007-09-12 16:30:06 UTC
I'm reassigning this to amd64, since I know they have a kernel option for 32-bit support.  Do other arches have the same thing and also multilib?  If so, we'd likely want to add them to CC also.
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2007-09-12 16:45:59 UTC
(In reply to comment #2)
> While I do agree that anyone not following the FAQ is asking for trouble, I
> think the ebuilds themselves should be giving information about this. It could
> be done via the multilib eclass or some other similar method. 

Uh, which ebuilds? You can't even install basic multilib AMD64 system without having IA32 emulation enabled, things like gcc or sandbox won't compile... Are you seriously suggesting to make all ebuilds that use multilib eclass depend on configured kernel sources to check for this? Oh wow, that will really rock. o_O
Comment 5 Olivier Crete (RETIRED) gentoo-dev 2007-09-12 16:58:04 UTC
I kind of agree with jakub... That said, maybe in the multilib profile bashrc we should check for IA32 mode or something, not having it is really not a good idea (unless you use the no-multilib profile)... 
Comment 6 Chris Gianelloni (RETIRED) gentoo-dev 2007-09-12 23:12:11 UTC
I know you might not believe this, but I'm not an idiot.  I never once mentioned requiring kernel sources.  Go back and look at comment #2 please before making any more comments here.  Also, you very well can setup a Gentoo box without CONFIG_IA32_EMULATION, it's called a stage3.  Now, if you have actual factual technical information to provide, feel free.  There's no need for sarcastic comments which provide nothing to the issue at hand.

Thanks
Comment 7 Chris Gianelloni (RETIRED) gentoo-dev 2007-09-13 00:11:46 UTC
Created attachment 130780 [details]
Code snippet example for checking multilib options

OK.  This is a general idea on how this can be done.  It might not be 100% correct, but it gets the idea across.

Since I am using only a WARNING, there's no reason to *DEPEND on any kernel sources, nor do we fail on missing kernel sources.  This still allows for compiling (where necessary) on alternate machines and only runs the checks when necessary.  Of course, other arches could be added, if necessary.
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2007-09-13 07:50:40 UTC
(In reply to comment #7)
Yeah, you can install from stage 3 - and on any gcc upgrade you've get non-compilable gcc without IA32 emulation.

Back to this 'issue': Producing spurious warnings because of missing/uncofigured kernel sources is a _lot_ worse than users occasionally hitting a 'problem' because they didn't follow the docs. Also you can even have IA32 emulation enabled in currently unpacked/configured kernel, but that doesn't say anything at all about the running kernel. As these packages we are talking about here don't require kernel sources to compile at all, similar checks are essentially bogus.

On another note, linux-info eclass already depends on virtual/linux-sources, so where exactly do you want to stick the above attached code snippet? Can't be any eclass/ebuild, and not really sure how will using inherit fly in profile.bashrc.

If this is such a horrible issue, why don't you ask kernel folks to make that option hard-enabled on amd64 multilib? Yeah, they won't do it because it doesn't make sense. Nor does a similar check for PEBKAC cases make sense elsewhere, kinda sounds like the "don't put your dog into your microwave" warnings.

If you want a real check, compile a stub of 32bit code and try to run it, that won't produce any spurious warnings anywhere - but will still be a complete over -engineering.
Comment 9 Mike Doty (RETIRED) gentoo-dev 2007-09-13 16:30:27 UTC
So, how many ebuilds do we have that depend on compiling 32bit code on a x86_64 platform?  I want to say very few, so we should avoid using a check in the profile.bashrc on every package and instead patch the ebuild and/or configure script.  I'm of the opinion that this is something autoconf should be catching, but I can see an argument for doing the check inside the ebuild too.  Before considering any approach, we should figure out how many packages depend on the functionality proposed.

On a unrelated note, the tone on this bug seems to be very negative, lets try to keep it more professional.
Comment 10 Chris Gianelloni (RETIRED) gentoo-dev 2007-09-13 17:20:14 UTC
(In reply to comment #8)
> (In reply to comment #7)
> Yeah, you can install from stage 3 - and on any gcc upgrade you've get
> non-compilable gcc without IA32 emulation.

...and?  What does that have to do with *this* bug report?

> Back to this 'issue': Producing spurious warnings because of
> missing/uncofigured kernel sources is a _lot_ worse than users occasionally
> hitting a 'problem' because they didn't follow the docs. Also you can even

That is totally your opinion, which I and the original bug poster do not share.  As such, I asked the affected architecture team(s) what they thought of my idea for a solution and will be proceeding based on their valued input.

> On another note, linux-info eclass already depends on virtual/linux-sources, so
> where exactly do you want to stick the above attached code snippet? Can't be
> any eclass/ebuild, and not really sure how will using inherit fly in
> profile.bashrc.

*yawn*

Did you ever think that it could be put *in* linux-info?  It really doesn't matter very much where it ends up, so long as it doesn't affect the dependency tree in the lower stages, which is my playground/responsibility and something I'm not exactly apt to go around breaking.

> If this is such a horrible issue, why don't you ask kernel folks to make that
> option hard-enabled on amd64 multilib? Yeah, they won't do it because it
> doesn't make sense. Nor does a similar check for PEBKAC cases make sense
> elsewhere, kinda sounds like the "don't put your dog into your microwave"
> warnings.

Why does an issue have to be "horrible" to be fixed?  How about I go and change the severity to "trivial" instead. Will that stop this incessant non-technical badgering?  Oh wait, it already is marked trivial.  Go figure.

> If you want a real check, compile a stub of 32bit code and try to run it, that
> won't produce any spurious warnings anywhere - but will still be a complete
> over -engineering.

That would actually be fine, if we were talking about compiling 32-bit code.  We aren't.

This bug report has to do with *running* 32-bit code on a multilib x86_64 system.  I am looking into how many packages this entails, but I know that I maintain at least 50 or so such packages myself.  The issue of compiling 32-bit code came up during the course of the bug report, but really is less of an issue, in this case, since someone can quite easily do a stage3 install, then go and install some binary package without compiling a single thing.
Comment 11 Jakub Moc (RETIRED) gentoo-dev 2007-09-13 17:59:19 UTC
(In reply to comment #10)
> That would actually be fine, if we were talking about compiling 32-bit code. 
> We aren't.
> 
> This bug report has to do with *running* 32-bit code on a multilib x86_64
> system. 

No, this is bug is about the fact that amd64 multilib profiles do NOT work without IA32 emulation enabled in kernel. By do not work, I seriously mean do NOT work. Being unable to compile toolchain is not something you could call a working profile no matter how many time you mumble something about your stage3 installs. 

So, lets forget some flash crap and focus on the real issue, and lets not use nonsensical kernel checks that fail to check anything relevant.
Comment 12 Chris Gianelloni (RETIRED) gentoo-dev 2007-09-17 17:38:03 UTC
wolf31o2@inertia /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64 $ grep jakub *
wolf31o2@inertia /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64 $ grep wolf31o2 *
index.xml:<dev role="Developer" description="games">wolf31o2</dev>

When you join the AMD64 team, let me know and I'll consider your input on this.  Until then, I'm waiting to hear from the people I've actually asked since their opinion on this actually matters to me and is going to be the basis of my work on this issue.  Feel free to discuss your ideas with the AMD64 team and get them to agree with you.  I'm not interested in the opinion of someone who will not be supporting whatever changes are made, if any.  As such, I'll be waiting for the respective team to come to a decision.
Comment 13 Chris Gianelloni (RETIRED) gentoo-dev 2007-11-06 01:13:06 UTC
So I am thinking of adding a "check_ia32" (or whatever, name doesn't matter) function to multilib.eclass, since that seems like the most likely location for it.  I'm willing to put in the work to add the check to any ebuilds which needs it.  Does anyone from amd64 have any objections?
Comment 14 Mike Doty (RETIRED) gentoo-dev 2007-11-06 01:26:02 UTC
(In reply to comment #13)
> So I am thinking of adding a "check_ia32" (or whatever, name doesn't matter)
> function to multilib.eclass, since that seems like the most likely location for
> it.  I'm willing to put in the work to add the check to any ebuilds which needs
> it.  Does anyone from amd64 have any objections?
> 

This seems reasonable.  Please call it check_ia32_emulation so there is no confusion as to what it does.
Comment 15 SpanKY gentoo-dev 2007-11-07 16:19:00 UTC
or "check_emulation_ia32" ...
Comment 16 Andrey Falko 2008-07-02 19:39:23 UTC
any update on this? I just hit this problem with some other 32bit apps on amd64. Let me know if there is any tedious work that needs to be done. I'll gladly do it on a weekend. 
Comment 17 Chris Gianelloni (RETIRED) gentoo-dev 2008-07-10 16:52:57 UTC
I was going to get back onto this over the next few days.  I've been terribly swamped with work and the release and am just now starting to get a little free time.
Comment 18 Ferris McCormick (RETIRED) gentoo-dev 2008-07-10 17:04:07 UTC
Why are we (devrel) CC on this?  We got added last November for no reason that I can see.  Anyone object if I take us off?
Comment 19 Łukasz Damentko (RETIRED) gentoo-dev 2008-09-17 09:49:40 UTC
11:45 < ColdWind> feel free to unCC devrel from #192286, there wasn't ever a
                  reason to CC you, and now there's even less since neither
                  wolf or jakub are around


Done.
Comment 20 Chris Gianelloni 2008-09-19 20:24:55 UTC
Ehh... I'm still around and this is still on my TODO.  I'll put up a patch here for the support once I get it done, then file bugs for the individual packages that require it.
Comment 21 Pacho Ramos gentoo-dev 2011-01-30 11:41:01 UTC
After reading the bug, looks like this is not a emul packages set problem as this is more general 
Comment 22 Pacho Ramos gentoo-dev 2015-12-03 14:08:01 UTC
What more are we expected to fix here?