We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 938 - SDL fails to link in mingw+msys+libtool
Summary: SDL fails to link in mingw+msys+libtool
Status: CLOSED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: main (show other bugs)
Version: 1.2.14
Hardware: x86 Windows (All)
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-27 10:06 UTC by Carlo Bramini
Modified: 2011-12-30 11:15 UTC (History)
0 users

See Also:


Attachments
Removes refereces to mingwex and force creation on .la file. (7.96 KB, patch)
2011-12-30 10:15 UTC, Carlo Bramini
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlo Bramini 2010-01-27 10:06:17 UTC
When building third party software powered by libtool (like xine-lib and several others) under Mingw+MSys, libSDL fails to link.
I got this message when building SDL video out component of xine-lib:

*** 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: /mingw/lib/libmingw32.a

Apparently there is no need to manually add -lmingw32 for making libSDL working.
If this flag is removed, everything is built without troubles.
If it has been added for fixing a cross-compiler, perhaps if would be a better idea to adjust its SPECS file in the same manner it has been done in the true one used by mingw on Windows (I'm just guessing why it exists here).

There is also another message received on the console:

*** 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: /mingw/lib/libSDLmain.a

This message, like previous one, is caused by -no-undefined flag sent to libtool when building shared libraries.
Actually adding an .la file with its dependencies solves the troubles, so I believe it would be better to create it too in the build process of libSDL.
Comment 1 Sam Lantinga 2011-12-29 01:15:11 UTC
Can you provide a patch to fix this issue?
Comment 2 Carlo Bramini 2011-12-29 14:03:06 UTC
I tried to do a patch, it is complete itself but I was not able to tell to libtool to create the right thing with SDLmain.
If a script called libSDLmain.la like this one exists near libSDLmain.a, compilation of third party softwares will always work fine:

# libSDLmain.la - a libtool library file
# Generated by ltmain.sh (GNU libtool) 2.2.6
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names='libSDLmain.a'

# The name of the static archive.
old_library='libSDLmain.a'

# Linker flags that can not go in dependency_libs.
inherited_linker_flags=''

# Libraries that this one depends upon.
dependency_libs=''

# Names of additional weak libraries provided by this library
weak_library_names=''

# Version information for libSDLmain.
current=11
age=11
revision=4

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/mingw/lib'


But the problem is the library_names field.
When building static libraries, that item is always *empty*, it seems to be filled only when building DLLs.
If library_names is empty, this message will be printed:

*** Warning: This system can not link to static lib archive c:/mingw/lib/libSDLmain.la.
*** 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.
*** But as you try to build a module library, libtool will still create
*** a static module, that should work as long as the dlopening application
*** is linked with the -dlopen flag to resolve symbols at runtime.

I tried to experiment *all* options of libtool without success.
If I compile a static only library, then there is library_names=''
If some of you have some suggestions...
Comment 3 Sam Lantinga 2011-12-30 03:33:39 UTC
Yeah, the .la file is only for shared libraries, and I think the result is that you end up not linking libSDLmain.a.

I'm going to leave it alone since it's just a warning from libtool and not a real problem.
Comment 4 Carlo Bramini 2011-12-30 10:04:30 UTC
Thank you for your reply, Sam.

(In reply to comment #3)
> Yeah, the .la file is only for shared libraries, and I think the result is that
> you end up not linking libSDLmain.a.
> 
> I'm going to leave it alone since it's just a warning from libtool and not a
> real problem.

but in fact, this is not exactly true, from what I could see, it is a *real* problem.
I did again my test with XINE, which compiles a core and a set of DLLs (audio renderer, video renderer, etc) but hopefully this could be also quickly and easily tested with a sample application and it will be seen that's not a simple warning message.

Let's assume that your project wants to build a DLL which depends on SDL.
If the .la file is missing or library_names field is empty, it won't link a DLL but a static library .a file.

So, everything will fail here: if an application wants to to do LoadLibrary() on this DLL, it won't work.

I must also say that if people will encounter this troubles with some applications (especially when doing porting of existing un*x software to mingw+msys) and SDLmain, this problem can be also resolved by putting "--disable-sdl" at configure time, if supported.
Comment 5 Carlo Bramini 2011-12-30 10:15:49 UTC
Created attachment 750 [details]
Removes refereces to mingwex and force creation on .la file.

I decided to share my patch anyways, if somebody will find it useful for some reasons.
It has been created on the most recent sources I could find in the repository.
I had not written it in previous comments, but libtool does not seem to be exactly happy to mix .lo and .o files (I'm talking about version.o).
Rather than doing things "by hand", it would be better to let libtool to call windres and leave all the task to him.
I used --tag option to libtool when building resources, newer versions will just ignore it, older versions required it: in the doubt, I placed it in the command.
Comment 6 Sam Lantinga 2011-12-30 11:15:38 UTC
I see why this is needed.
I applied your patch, but I needed to change it so SDLmain is static on all platforms (e.g. Mac OS X).
http://hg.libsdl.org/SDL/rev/987c365cc7bf

Thanks!