Bug 44781 - illegal instruction on 386 CPU due to glibc compilation mistake
Summary: illegal instruction on 386 CPU due to glibc compilation mistake
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-06-16 15:55 UTC by Eric Thomas
Modified: 2016-11-24 15:21 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-22 01:46:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Eric Thomas 2001-06-16 15:55:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.5 i686)

Description of problem:
glibc-2.2.2-10.i386.rpm seems to be compiled without respecting the glibc's
FAQ recommendations chapter 1.18:
"And you need to tell gcc to only generate i386 code, just add `-mcpu=i386'
(just -m386 doesn't work) to your CFLAGS."

Without this, the glibc contains non-386 code and makes all non-staticaly
linked binaries to report illegal instruction.

As a specific glibc rpm file for 686 exists, the "386 only" one should
REALLY works on the lowest i386 architecture CPUs (386 indeed :-))

How reproducible:
Always

Steps to Reproduce:
1.install RH 7.1 on a pentium computer
2.rebuild the kernel for a 386 computer as target (coprocessor emultation
etc..)
3.put the hard drive in a 386 computer
4. (try to) boot linux
	

Actual Results:  The kernel loading is ok, the computer is not frozen but
seems stuck when lunching /sbin/init
No error messages

Expected Results:  A completed boot sequence

Additional info:

The boot sequence does not report "illegal instruction" error.
Put back the hard drive in the pentium computer.
In order to manage to boot anyhow on the 386:
- rename /sbin/init as whatever you want
- replace /bin/sh by ash.static
- create /auto file containing "/bin/sh"
Boot linux on the 386 computer.
sh (ash.static) is launched by the kernel. At the prompt, every dynamicaly
linked command you launch ends on (start by) "illegal instruction".

Comment 1 Jakub Jelinek 2001-06-25 07:38:18 UTC
glibc-*.i386.rpm is compiled with -march=i386, it does not contain any
non-i386 instructions.
By pentium above, do you mean a `uname -m`=i586 or i686 machine?
Are you sure rpm -q --qf '%{arch}\n' glibc gives i386, not i686?
Is /lib/i686 directory missing?

Comment 2 Eric Thomas 2001-06-25 22:01:10 UTC
Yes, rpm -q --qf '%{arch}\n' glibc gives i386, but i hadn't noticed that
/lib/i686 directory.

In fact, glibc.i686.rpm has been automatically chosen during the install process
on the pentium computer, no way to force to use a i386 rpm (afaik).
So i manually replaced it with glibc.i386.rpm with the following command:

rpm -Uv --force glibc-2.2.2-10.i386.rpm

But /lib/i686 remains and so

[root@redrum /]# ldd /sbin/init
        libc.so.6 => /lib/i686/libc.so.6 (0x40025000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

If i rpm -qf on /lib/i686/libc.so.6, it is not owned by any package. Shouldn't
this have been removed when i replaced the i686 rpm by the i386 one ?

If i manually remove /lib/i686, the 386 boots without any problem.

Perhaps rpm -Uv --force was not the right way to replace the glibc but it is
difficult to do a rpm -e followed by a rpm -i on this library on a running
system.

Not removing /lib/i686 with rpm -U, bug or feature ?



Comment 3 Ulrich Drepper 2003-04-22 01:46:54 UTC
This is no glibc bug.  It's a user bug.  Using rpm is sometimes challenging. 
Better always use up2date and it'll automatically install the right packages.


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