Bug 86359
| Summary: | /lib/i686 no longer used? | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Nadav Har'El <nyh> |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | mitr, radu, rl, sretr |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-04-10 23:09:24 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Cannot reproduce it.
What exact kernel are you running?
ls -l /lib/i686
strace /bin/echo
rpm -q --qf '%{arch}\n' glibc
I tried this on two different computers (upgraded seperately) and I got the same
results. Here is the results on one of them, "flower":
$ uname -a
Linux flower 2.4.18-27.8.0 #1 Fri Mar 14 06:45:49 EST 2003 i686 i686 i386 GNU/Linux
$ ls -l /lib/i686
total 1684
-rwxr-xr-x 1 root root 1448819 Mar 19 14:45 libc-2.3.2.so
lrwxrwxrwx 1 root root 13 Mar 20 14:30 libc.so.6 -> libc-2.3.2.so
-rwxr-xr-x 1 root root 171281 Mar 19 14:45 libm-2.3.2.so
lrwxrwxrwx 1 root root 13 Mar 20 14:30 libm.so.6 -> libm-2.3.2.so
-rwxr-xr-x 1 root root 87941 Mar 19 14:45 libpthread-0.10.so
lrwxrwxrwx 1 root root 18 Mar 20 14:30 libpthread.so.0 ->
libpthread-0.10.so
$ strace /bin/echo
execve("/bin/echo", ["/bin/echo"], [/* 13 vars */]) = 0
uname({sys="Linux", node="flower", ...}) = 0
brk(0) = 0x804bb08
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=78781, ...}) = 0
old_mmap(NULL, 78781, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300Y\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1292588, ...}) = 0
old_mmap(NULL, 1298244, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000
old_mmap(0x4015e000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x136000) = 0x4015e000
old_mmap(0x40163000, 8004, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40163000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40165000
munmap(0x40014000, 78781) = 0
brk(0) = 0x804bb08
brk(0x804cb08) = 0x804cb08
brk(0) = 0x804cb08
brk(0x804d000) = 0x804d000
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40014000
write(1, "\n", 1
) = 1
munmap(0x40014000, 4096) = 0
_exit(0) = ?
$ rpm -q --qf '%{arch}\n' glibc
i686
Strange. Can you: LD_SHOW_AUXV=1 /bin/echo ldconfig -p | grep libc.so echo assume kernel $LD_ASSUME_KERNEL Sure.
$ LD_SHOW_AUXV=1 /bin/echo
AT_HWCAP: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36
mmx fxsr sse
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x8048034
AT_PHENT: 32
AT_PHNUM: 6
AT_BASE: 0x40000000
AT_FLAGS: 0x0
AT_ENTRY: 0x8048a88
AT_UID: 502
AT_EUID: 502
AT_GID: 501
AT_EGID: 501
AT_PLATFORM:
$ /sbin/ldconfig -p | grep libc.so
libc.so.6 (libc6, hwcap: 0x8000000000000, OS ABI: Linux 2.4.1) =>
/lib/i686/libc.so.6
libc.so.6 (libc6, OS ABI: Linux 2.2.5) => /lib/libc.so.6
$ echo assume kernel $LD_ASSUME_KERNEL
assume kernel
AT_PLATFORM: This is the problem. It should print AT_PLATFORM: i686 I checked ld-linux.so.2 under debugger and it is the kernel which is passing bogus AT_PLATFORM to the userland, reassigning to kernel. I'd like to comment that on my home machine, another Redhat 8.0 but slightly
less updated with all the latest errata (running kernel 2.4.18-24.8.0 and the
original glibc-2.2.93-5), when I run
$ LD_SHOW_AUXV=1 /bin/echo
I also get
AT_PLATFORM:
but still,
$ ldd /bin/echo
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
So either the correct linking has nothing to do with this AT_PLATFORM, or,
alternatively, the old glibc.2.2.93-5 ignored this parameter and the new
glibc.2.3 now (correctly?) makes use of it.
Good luck fixing this bug :)
*** Bug 86398 has been marked as a duplicate of this bug. *** An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2003-089.html |
After upgrading my Redhat 8.0 to glibc-2.3.2-4.80, a program I am writing stopped working (segmentation violation on malloc()). Unfortunately, I could not isolate this problem yet, but while researching it I found another very strange thing, looks like a bug that I can't explain in the new glibc: When I do "ldd /bin/ls" (for example) on an original Redhat 8.0 I get: .. libc.so.6 => /lib/i686/libc.so.6 (0x42000000) .. I.e., the libc is taken from the /lib/i686 directory. But when I do that with the upgraded glibc, I get: libc.so.6 => /lib/libc.so.6 (0x40033000) Note /lib, not /lib/i686, is used. I doubt this is what cause my segfault, but I think its a bug nontheless - I installed the i686 RPMs because I wanted them to be used! :)