I can't reproduce this, I just tried it with a fresh checkout in Ubuntu Oneiric 64 bits.

Created attachment 829 [details]
Generated Makefile

Broken Makefile

Configure options: --disable-static --enable-assertions=paranoid --enable-sse2 --disable-esd --disable-pulseaudio --disable-nas --disable-fusionsound

In Makefile present next lines:

SDLMAIN_OBJECTS = $(objects)/SDL_dummy_main.o
...
$(objects)/SDL_dummy_main.o: ./src/main/dummy/SDL_dummy_main.c
	$(LIBTOOL) --mode=compile $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -MMD -MT $@ -c $< -o $@

But libtool place SDL_dummy_main.o into build/.libs/

libtool version: 2.4

It seems the problem is --disable-static, remove that switch from the configure line and it works fine. This should be fixed anyway.

I'm assigning this to me, I'll try to fix it soon.

*** Bug 1541 has been marked as a duplicate of this bug. ***

Created attachment 1099 [details]
Fix for --disable-static bug

The attached patch should solve the problem, if anyone else can confirm or Sam gives the go ahead I'll commit it.

Created attachment 1114 [details]
Use libtool everywhere

The problem is caused by mixing libtool builds with non-libtool builds.  The quick fix is to replace .o and .a with .lo and .a, replace explicit calls to `ar` and `ranlib` with $(LIBTOOL) --mode=link, and replace explicit install calls with $(LIBTOOL) --mode=install. I've attached a patch to the ticket.

Thanks John, but I had already attached a patch quite similar to yours :)

The thing is, we will probably remove the --disable-static switch altogether unless someone comes up with a good reason not to.

(In reply to comment #10)
> The thing is, we will probably remove the --disable-static switch altogether
> unless someone comes up with a good reason not to.

In the meantime, it's probably worth applying this patch instead of leaving it broken.

--ryan.

Sam said that he remembered there was probably a reason behind doing things without libtool, that's why the patch hasn't been applied.

If we're going to take action on this bug before 2.0 ship, I'd rather remove the --disable-static option.

We gentoo devs are currently working on packaging SDL2 and the brokenness of --disable-static is a major bummer for us. It is common to provide this as an option for the user, so he can control static libraries globally.

I do not see any reason to remove this feature. It will rather force us to apply patches downstream and will slow us down on version bumps.

The problem with --disable-static, at least conceptually, is that there are two libraries which are not available in dynamic versions, and we want them to always be available.

There are folks on other operating systems which have in the past complained about libtool because of bugs in their OS libtool installations.  I'm not opposed to putting that back if there are compelling reasons to do so.

Thoughts?

(In reply to Sam Lantinga from comment #15)
> The problem with --disable-static, at least conceptually, is that there are
> two libraries which are not available in dynamic versions, and we want them
> to always be available.
> 

I am unable to follow here.
I get:
/usr/lib64/libSDL2.a
/usr/lib64/libSDL2_test.a
/usr/lib64/libSDL2main.a

and:
/usr/lib64/libSDL2.so
/usr/lib64/libSDL2_test.so
/usr/lib64/libSDL2main.so


> There are folks on other operating systems which have in the past complained
> about libtool because of bugs in their OS libtool installations.  I'm not
> opposed to putting that back if there are compelling reasons to do so.
> 
> Thoughts?

I don't have a strong opinion about libtool. I'd just like this bug resolved without loosing the ability of disabling static libs for compile time.

Created attachment 1499 [details]
MingW fixes for "Use libtool everywhere"

The "Use libtool everywhere" patch posted john and applied in Gentoo breaks (cross-)compilation with MingW.

First, linking fails completely:

 libtool: link: `build/version.lo' is not a valid libtool object

This is because version.o was renamed to .lo while the output of the resource compiler is obviously not a libtool object. Renaming it back to .o doesn't work either, as libtool will then complain about non-libtool objects. What does work however is wrapping the $(WINDRES) call with libtool.

Now linking the static library works, but libtool skips the dynamic library:

 *** Warning: linker path does not have real file for library -luuid.
 *** 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 libuuid and none of the candidates passed a file format test
 *** using a file magic. Last file checked: /usr/i686-w64-mingw32/lib/libuuid.a
 *** The inter-library dependencies that have been dropped here will be
 *** automatically added whenever a program is linked with this library
 *** or is declared to -dlopen it.
 
 *** Since this library must not contain undefined symbols,
 *** because either the platform does not support them or
 *** it was explicitly requested with -no-undefined,
 *** libtool will only create a static version of it.

This can be fixed by changing -luuid into -Wl,-luuid to bypass libtool. A similar workaround was applied in GTK+ 3: https://bugzilla.gnome.org/show_bug.cgi?id=642214

(In reply to Julian Ospald from comment #16)
> (In reply to Sam Lantinga from comment #15)
> > The problem with --disable-static, at least conceptually, is that there are
> > two libraries which are not available in dynamic versions, and we want them
> > to always be available.
> > 
> 
> I am unable to follow here.
> I get:
> /usr/lib64/libSDL2.a
> /usr/lib64/libSDL2_test.a
> /usr/lib64/libSDL2main.a
> 
> and:
> /usr/lib64/libSDL2.so
> /usr/lib64/libSDL2_test.so
> /usr/lib64/libSDL2main.so

This won't work on all platforms as libSDL2main contains the main() entry point, at least on Windows. Also, linking the SDL2main dll will fail with undefined references to SDL functions. I got around this by adding -all-static to the SDL2main and SDL2_test link commands so that libtool does not try to link dynamic libraries. I'm no libtool/autoconf expert, but it seems to work fine (always creates static SDLmain), even with --disable-static.

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.