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 2129

Summary: fix for bug 2121 breaks linking for mingw and throws multiple warnings
Product: SDL Reporter: Andreas Ertelt <bugzilla-sdl>
Component: *don't know*Assignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: parasti+libsdl
Version: HG 2.0   
Hardware: x86_64   
OS: Windows 8   
Attachments: Proposed fix

Description Andreas Ertelt 2013-10-02 05:29:04 UTC 
The problem in question is caused by changeset 7771 (http://hg.libsdl.org/SDL/rev/4434498bf4b9 / https://bugzilla.libsdl.org/show_bug.cgi?id=2121)

The redefinition of __inline__ (introduced by the addition of begin_code.h:128's "|| __STRICT_ANSI__") results in mingw's gcc throwing multiple

   warning: always_inline function might not be inlinable [-Wattributes]

as well as a whole bunch of redefinitions of mingw internals which break linking of projects including the SDL2 headers.
Comment 1 Sam Lantinga 2013-10-03 09:12:30 UTC 
Do you have a proposed fix?  I don't have that environment set up, so I can't test this.

Thanks!
Comment 2 Andreas Ertelt 2013-10-03 09:28:14 UTC 
This would do the job:

#if !SDL_INLINE_OKAY || __STRICT_ANSI__ && !__MINGW32__
Comment 3 Sam Lantinga 2013-10-06 04:56:39 UTC 
Does mingw32 define __STRICT_ANSI__? Or does SDL_INLINE_OKAY not end up getting set for some reason?
Comment 4 Andreas Ertelt 2013-10-06 10:33:57 UTC 
__STRICT_ANSI__ is implied when using any of the ansi/iso standards (eg. c90, c98, c++11, etc.).

SDL_INLINE_OKAY is defined in line 119 for MINGW, which now gets overridden by __STRICT_ANSI__ and forces a redifinition of __inline__ which should not occur in MINGW environments.

If the problem had been caused by an undefined SDL_INLINE_OKAY it would have existed prior to this patch ;)
Comment 5 Jānis Rūcis 2013-10-08 01:20:16 UTC 
Just noticed this. I made the original bug report. (Wish you'd reopened that one instead of making a new one!)

I can confirm that the fix breaks MinGW builds hardcore. Fundamentally, the problem is that SDL redefines the __inline__ keyword to mean nothing, and this definition is then leaked to system headers which have been written with the full expectation that __inline__ is not going to be nothing.

It seems that __inline__ works even in ANSI C (at least when using GCC):

http://gcc.gnu.org/onlinedocs/gcc/Inline.html
Comment 6 Jānis Rūcis 2013-10-08 03:22:11 UTC 
Created attachment 1358 [details]
Proposed fix

I put together a quick patch. It doesn't throw errors or warnings on my MinGW cross-compile setup nor native Linux when compiling ANSI C code, but I can't really say if it still works, either. In the very least, I think not hijacking __inline__ would be a good first step.
Comment 7 Sam Lantinga 2013-10-21 04:58:27 UTC 
Fixed, thanks!
http://hg.libsdl.org/SDL/rev/2b0bcdea3a79
Comment 8 Jānis Rūcis 2013-10-21 06:03:32 UTC 
Reopening as compilation with ANSI C throws lots of unnecessary warnings, both using MinGW and using Linux GCC. (BTW, what happened? MinGW is broken to all hell. sdl2-config does not even link SDLMain anymore?)

I think this may have been lost somewhere, so again: GCC supports inlining via __inline__ in all known versions of GCC, regardless of the C standard in use. Please don't assume that __STRICT_ANSI__ implies no inlining support.

My patch addressed the original problem (that I reported) as well as the problems with the fix (reported by Andreas Ertelt). Was there a problem with it that made it unsuitable on a particular compiler?
Comment 9 Sam Lantinga 2013-10-21 09:34:30 UTC 
No, your patch was fine.  I didn't realize that __inline__ was always available with gcc.

Thanks!
http://hg.libsdl.org/SDL/rev/ca36ab2a8179

Please report separate bugs with mingw builds.  I just installed msys and the latest mingw32 gcc on Windows 7 a few days ago and successfully built and used SDL in that configuration.