Description of problem: Compilation is broken Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: Create a dll which is statically linked with SDL, as follows: bin/sh ../../../../libtool --tag=CC --mode=link i686-pc-mingw32-gcc -fPIC -DPIC -DIS_MINGW=1 -D_GNU_SOURCE=1 -Dmain=SDL_main -I/usr/i686-pc-mingw32/sys-root/mingw/include/SDL -g -O2 -Wall -shared -fPIC -DPIC -module -avoid-version --tag=disable-static -no-undefined -Wl,/usr/i686-pc-mingw32/sys-root/mingw/lib/libSDL.dll.a -Wl,/usr/i686-pc-mingw32/sys-root/mingw/lib/libSDLmain.a -o SDL.la -rpath "/usr/lib/lives/plugins/playback/video" SDL_la-SDL.lo libtool: link: i686-pc-mingw32-gcc -shared .libs/SDL_la-SDL.o -O2 -Wl,/usr/i686-pc-mingw32/sys-root/mingw/lib/libSDL.dll.a -Wl,/usr/i686-pc-mingw32/sys-root/mingw/lib/libSDLmain.a -o .libs/SDL.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/SDL.dll.a This creates SDL.dll in .libs. No warnings are given about missing functions. Actual results: When SDL.dll is loaded and run under wine, it crashes with: wine: Call from 0x7bc4c100 to unimplemented function SDL.dll.SDL_Init, aborting wine: Unimplemented function SDL.dll.SDL_Init called at address 0x7bc4c100 (thread 0023), starting debugger... Unhandled exception: unimplemented function SDL.dll.SDL_Init called in 32-bit code (0x7bc4c100). Expected results: SDL_Init should be found inside libSDL.dll.a
Version is mingw32-SDL-1.2.13-10.fc16
There were other oddities with the compilation. I had to remove the pkg-config ldflags (-mwindows -L/usr/i686-pc-mingw32/sys-root/mingw/lib -lmingw32 -lSDLmain -lSDL) otherwise I get this: *** Warning: linker path does not have real file for library -lmingw32. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libmingw32 and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/i686-pc-mingw32/sys-root/mingw/lib/libmingw32.a *** Warning: linker path does not have real file for library -lSDLmain. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libSDLmain and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/i686-pc-mingw32/sys-root/mingw/lib/libSDLmain.a *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module SDL. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. and the SDL.dll is not built.
I also just tried adding -mwindows and statically linking with libmingw32.a, as suggested by the pkg-config libs, but it did not resolve the problem.
I don't fully understand what you're trying to achieve. You mention that you want to create a dll which is statically linked against SDL. However, the mingw32-SDL package currently already provides a shared library called SDL.dll (and its corresponding import library libSDL.dll.a). The mingw32-SDL package doesn't contain a static library at the moment What package did you try to compile which produced the libtool/gcc output you mentioned? There's an argument in it which I find rather suspicious: -rpath "/usr/lib/lives/plugins/playback/video" This argument shouldn't be used when cross-compiling I just checked the SDL.dll which is part of the RPM you mentioned using a tool called Dependency Walker and I noticed that the function SDL_Init is exported as it should be in the dll. Are you sure that you're using the SDL.dll which is part of the mingw32-SDL RPM in the wine tests? The libtool warnings you get may be caused by an outdated copy of libtool which is used in the package you're trying to compile. Manually re-running 'libtoolize --copy --force' may help there
In answer to the questions, I am attempting to compile my own package, which contains a number of plugins each of which needs to be compiled as a dll. One of the plugins is called SDL.dll, but has nothing to do with the mingw32 SDL.dll. However, attempting to compile a shared lib (dll) against another shared lib (dll) produces the warning message noted in comment 2, and the output dll is not created. (This is with the standard fedora 16 libtool). As a workaround, I read somewhere that one can force static linking with the dependencies by doing -Wl,<path_to_static_lib>. In fact this has worked succesfully with other plugins. Therefore I was attempting to do the same with my SDL.dll It seems I am also misunderstanding something - I was assuming that libSDL.dll was the equivalent of a shared lib, and libSDL.dll.a was the equivalent of a static lib. I am not sure what is meant by "import library". Finally regarding the rpath, I am not sure where this comes from, I think it comes from the installation directory in Makefile.am. I tried removing this but then it was impossible to run automake, so I have been forced to leave it in.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.