Bug 509935 - Python fails after upgrade: ELF file OS ABI invalid
Python fails after upgrade: ELF file OS ABI invalid
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Nick Clifton
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-06 19:39 EDT by Valdis Kletnieks
Modified: 2009-12-04 07:13 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-04 07:13:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Valdis Kletnieks 2009-07-06 19:39:07 EDT
Description of problem:
After upgrading to 2.6-10.fc12, trying  to run Python dies an early horrid death:

%  /usr/bin/python
/usr/bin/python: error while loading shared libraries: /usr/lib64/libpython2.6.so.1.0: ELF file OS ABI invalid

This *may* be caused by the fact that I still have glibc-2.9-2.x86_64 installed (Rawhide glibc-2.9.90-12 broke some stuff on me, and I haven't gotten brave enough to revisit the issue and see if glibc 2.10 works), but the python RPM failing to flag the glibc 2.10 dependency?

How early? *very* early:

% strace /usr/bin/python
execve("/usr/bin/python", ["/usr/bin/python"], [/* 71 vars */]) = 0
brk(0)                                  = 0x866000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff4ea682000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff4ea681000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=132683, ...}) = 0
mmap(NULL, 132683, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff4ea660000
close(3)                                = 0
open("/usr/lib64/libpython2.6.so.1.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\277\3\0\0\0\0\0@"..., 832) = 832
close(3)                                = 0
writev(2, [{"/usr/bin/python"..., 15}, {": "..., 2}, {"error while loading shared librar"..., 36}, {": "..., 2}, {"/usr/lib64/libpython2.6.so.1.0"..., 30}, {": "..., 2}, {"ELF file OS ABI invalid"..., 23}, {""..., 0}, {""..., 0}, {"\n"..., 1}], 10/usr/bin/python: error while loading shared libraries: /usr/lib64/libpython2.6.so.1.0: ELF file OS ABI invalid
) = 111
exit_group(127)                         = ?

'rpm -V python' reports it as being clean, so it isn't a corrupted update...


Version-Release number of selected component (if applicable):
python-2.6-10.fc12.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Valdis Kletnieks 2009-07-06 20:21:00 EDT
Confirming - upgrading the box to glibc 2.10.1-2 made Python start working.  Only question now is why the RPM managed to escape to rawhide without a 'Requires: libc.so.6(GLIBC_2.10)' attached to it like many other recent RPMs have had, so rpm/yum don't install them until glibc has been updated.
Comment 2 Bug Zapper 2009-11-16 05:39:10 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Dave Malcolm 2009-12-03 16:28:51 EST
Thanks for reporting this bug.

The build of python-2.6-10.fc12 was:
http://koji.fedoraproject.org/koji/buildinfo?buildID=112979

/usr/lib64/libpython2.6.so.1.0 is part of the python-libs subpackage.

python-libs-2.6-10.fc12.x86_64.rpm is here:
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1342443

According to that page, that subpackage had these glibc dependencies:
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libutil.so.1()(64bit)
libutil.so.1(GLIBC_2.2.5)(64bit)
Comment 4 Dave Malcolm 2009-12-03 16:31:54 EST
...and according to the buildroot page:
http://koji.fedoraproject.org/koji/rpmlist?buildrootID=494333%20&start=50&order=nvr&type=component

that rpm was built using:
glibc-2.10.90-2.x86_64.rpm
Comment 5 Dave Malcolm 2009-12-03 16:38:50 EST
I'm not sure what went wrong here; the "ELF file OS ABI invalid" message looks like it came from inside the shared library loader.  It may have been a transitional issue with the glibc upgrade.

Reassigning to "glibc" in the hope of more insight.
Comment 6 Andreas Schwab 2009-12-04 07:09:37 EST
EI_OSABI is set by the linker.
Comment 7 Jakub Jelinek 2009-12-04 07:13:55 EST
And correctly so, binaries or shared libraries which use STB_GNU_UNIQUE really are Linux specific and need to be marked so.  glibcs before 2.10 won't be able to handle them anyway.

The rpms aren't marked with libc.so.6(GLIBC_2.10) req, because they don't use any GLIBC_2.10 symbols.  We'd need to invent some completely different req/prov for this (like was done e.g. for DT_GNU_HASH), but that wasn't added and so it is already late to do that.

Just don't mix glibc from earlier releases with rpms from a newer one, it is quite easy.

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