Bug 509935 - Python fails after upgrade: ELF file OS ABI invalid
Python fails after upgrade: ELF file OS ABI invalid
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Nick Clifton
Fedora Extras Quality Assurance
Depends On:
  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:
Last Closed: 2009-12-04 07:13:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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):

How reproducible:

Steps to Reproduce:
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:
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:

/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:

According to that page, that subpackage had these glibc dependencies:
Comment 4 Dave Malcolm 2009-12-03 16:31:54 EST
...and according to the buildroot page:

that rpm was built using:
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.