Description of problem: After the last software update, I'm unable to open wxGTK based applications. This affects for example Audacity, Poedit and Kicad on my system. Version-Release number of selected component (if applicable): $ rpm -qi SDL Name : SDL Relocations: (not relocatable) Version : 1.2.14 Vendor: Fedora Project Release : 9.fc14 Build Date: Fr 18 Feb 2011 13:59:37 CET Install Date: Sa 19 Feb 2011 18:31:35 CET Build Host: x86-03.phx2.fedoraproject.org How reproducible: Launch a wxGTK application Actual results: The following error message appears: $ poedit poedit: error while loading shared libraries: libSDL-1.2.so.0: cannot enable executable stack as shared object requires: Permission denied $ audacity audacity: error while loading shared libraries: libSDL-1.2.so.0: cannot enable executable stack as shared object requires: Permission denied Expected results: I would expect to start the application, of course... Additional info:
I'm not aware about any changes in SDL that could introduce this change. Both previous and current version have the stack marked as unexecutable. More ever it works for me. Can you read section <http://www.crypt.gen.nz/selinux/faq.html#CP.19> and check tour library of permission for stack (e.g. by execstack -q). Are you sure that downgrading SDL to previous version dismiss the problem?
Bellow are unpacked packages downloaded from koji and no executable bit on stack segment is set: $ scanelf --header SDL-1.2.14-{8,9}.fc14.x86_64/usr/lib64/libSDL-1.2.so.0.11.3 TYPE STK/REL/PTL FILE ET_DYN RW- --- RW- SDL-1.2.14-8.fc14.x86_64/usr/lib64/libSDL-1.2.so.0.11.3 ET_DYN RW- --- RW- SDL-1.2.14-9.fc14.x86_64/usr/lib64/libSDL-1.2.so.0.11.3 However it's visible on i686 build: $ scanelf --header SDL-1.2.14-{8,9}.fc14.i686/usr/lib/libSDL-1.2.so.0 TYPE STK/REL/PTL FILE ET_DYN RW- --- RW- SDL-1.2.14-8.fc14.i686/usr/lib/libSDL-1.2.so.0 ET_DYN RWX --- RW- SDL-1.2.14-9.fc14.i686/usr/lib/libSDL-1.2.so.0 AFAIK i686 architecture has no executable protection in CPU implemented so the marker is just informative. I guess somebody changed tool chain in F14. I will check it.
TYPE STK/REL/PTL FILE ET_DYN RW- --- RW- SDL-1.2.14-9.fc13.i686/usr/lib/libSDL-1.2.so.0 ET_DYN RW- --- RW- SDL-1.2.14-8.fc14.i686/usr/lib/libSDL-1.2.so.0 ET_DYN RWX --- RW- SDL-1.2.14-8.fc14.i686-rebuild/usr/lib/libSDL-1.2.so.0 ET_DYN RWX --- RW- SDL-1.2.14-9.fc14.i686/usr/lib/libSDL-1.2.so.0 ET_DYN RWX --- RW- SDL-1.2.14-11.fc16.i686/usr/lib/libSDL-1.2.so.0 The SDL-1.2.14-8.fc14.i686-rebuild (http://koji.fedoraproject.org/koji/taskinfo?taskID=2857019) built from the same sources as SDL-1.2.14-8.fc14.i686 differ in the bit. So it looks like a tool chain issue.
Same issue here, gnash can't be run at all on i686 due to this
I think we need this regression addressed before pushing any SDL update. I suspect a regression or an incompatible change in NASM. The good build was done with nasm-2.08.01-2.fc14, the bad one with nasm-2.09.03-2.fc14. Documented changes: http://www.nasm.us/doc/nasmdocc.html
While we really need to get NASM fixed since this can also affect other packages (in fact, at least one package in a third-party repository has a workaround for what's probably the same issue), could we try using YASM instead, which appears to be SDL upstream's preferred choice?
*** Bug 652297 has been marked as a duplicate of this bug. ***
nasm-2.08.02-1.fc14.i686 passes. nasm-2.09-1.fc14.i686 produces affected objects.
I found it. Newer nasm will not define `__OUTPUT_FORMAT__' macro as `elf', but as `elf32' if invoked as `nasm -f elf'. This is due to `elf' became alias for `elf32' in nasm-2.09: Short aliases \c{win}, \c{elf} and \c{macho} for output formats are introduced. Each stands for \c{win32}, \c{elf32} and \c{macho32} accordingly. I guess SDL sources should be patched to write: %ifidn __OUTPUT_FORMAT__,elf32 section .note.GNU-stack noalloc noexec nowrite progbits %endif instead of %ifidn __OUTPUT_FORMAT__,elf section .note.GNU-stack noalloc noexec nowrite progbits %endif
SDL-1.2.14-11.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/SDL-1.2.14-11.fc15
SDL-1.2.14-10.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/SDL-1.2.14-10.fc14
SDL-1.2.14-10.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/SDL-1.2.14-10.fc13
SDL-1.2.14-11.fc15 has been pushed to the Fedora 15 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update SDL'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/SDL-1.2.14-11.fc15
SDL-1.2.14-11.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
SDL-1.2.14-10.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
SDL-1.2.14-10.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 578707 [details] Ooops same problem with Firefox
(In reply to comment #17) > Created attachment 578707 [details] > Ooops same problem with Firefox I'm not aware that Firefox would use SDL library. Even SDL is is supposed to be fixed now. You should report your issue against Firefox component and provide all necessary details like Firefox package version.