Description of problem: libSDLmain.a was removed from SDL-devel and no dynamic library is provided. Version-Release number of selected component (if applicable): 1.2.13-1 How reproducible: always Steps to Reproduce: 1. Install SDL-devel 2. rpm -ql SDL-devel | grep SDLmain Actual results: rpm -ql SDL-devel | grep SDLmain returns nothing Expected results: rpm -ql SDL-devel | grep SDLmain should return /usr/lib*/libSDLmain.a Additional info: libSDLmain.a is required to compile, for instance, virtualbox (http://www.virtualbox.org/)
SDL-1.2.13-2.fc8 has been submitted as an update for Fedora 8
SDL-1.2.13-2.fc8 has been pushed to the Fedora 8 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: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1225
Imho the SDL main package should Requires: the -static subpackage util F10 is released, because this splitup (or removal of the static libraries from SDL-devel) is a major change, that should only happen within distro upgrades and mentioned in the release notes.
Is it possible to patch SDL to have a dynamic library for SDLmain? I do not understand why there is a dynamic library for SDL and only a static for SDLmain, but I'm just a user...
SDL-1.2.13-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
> Is it possible to patch SDL to have a dynamic library for SDLmain? I do not > understand why there is a dynamic library for SDL and only a static for > SDLmain, but I'm just a user... libSDLmain contains the main function. Its purpose is to wrap the actual main function of the program (which gets renamed to SDL_main) with SDL error handling (the parachute system). So main gets renamed to SDL_main in the main program and libSDLmain contains the real main function the linker sees. I guess this doesn't work with a shared library. In any case, this is still broken in Rawhide. Libraries which are static only should be provided in the -devel package, not -static.
See also bug 434317 for a build failure caused by this.
One big request (requirement) in the package review of SDL was to remove the static libraries from the devel package. I have made an extra static package to not loose them.
That makes sense for the libraries with both a static and a dynamic version (e.g. libSDL.*), but libSDLmain.a is _only_ static. Should this be discussed on the fedora-packaging-list maybe? Or brought to the attention of the Fedora Packaging Committee? (Their next meeting will be 13 days from now.)
The review guidelines are pretty clear about this imho: - MUST: Static libraries must be in a -static package. The reason for this I read on the mailinglist is, that this allows to track where static libraries are still used easily, to make it easier to remove them.
But the guidelines also say: > When a package only provides static libraries you can place all the files in > the *-devel subpackage. When doing this you also have to have a virtual > Provide for the static package: > %package devel > Provides: foo-static = %{version}-%{release} The last part obviously isn't possible here because this package contains _both_ libraries which are available as shared and static _and_ a static-only library! They also say: > If a library you depend on _only_ provides a static version your package can > link against it provided that you BuildRequire the *-devel subpackage. The only way BRing SDL-devel rather than SDL-static is going to work here is if libSDLmain.a is in SDL-devel, not SDL-static. Therefore IMHO the right solution is to put libSDLmain.a into SDL-devel and libSDL.a (and other static libraries which also have a shared version, if any) into SDL-static.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
builds as of 2008-07-03, version 1.2.13-4.fc10.