Including windows.h in SDL_atomic.h?

Well, there are several options.

  1. Do as you say, and use the library functions.
  2. Locally add intrin.h from the MingGW-W64 distro - much as we need
    to use alternate sources for dsound.h and dinput.h.
  3. Implement intrin.h and get the mingw.org folk to accept it into the
    distro. They’re very strict about not taking anything that could, in
    even the most far fetched way, run afoul of Microsoft’s lawyers,
    though.
  4. Start using a MinGW-W64 based distro, such as either the MinGW-W32
    auto-build snapshot, or the the MinGW-W64 bi-lib distro from TDM-GCC.

I’m going to try both 4 & 2. As I mentioned, I find MinGW-W64 based
distributions annoyingly messy, because of the multitude of include,
lib and lib32 directories. None the less, that may be the path of
least suck, especially if just locally stealing intrin.h doesn’t do
the trick.On Mon, Jan 17, 2011 at 19:00, Nathaniel J Fries wrote:

I also lack intrin.h
My MinGW installation is a recent one from the official sourceforge page.

Perhaps the solution here is to just always use the SDL library functions on
MinGW? Certainly not ideal, but…


Do what you can, where you are, with what you have. - T. Roosevelt

So, I left one option off - gcc specific code using the gcc atomic
builtins. Haven’t worked with them, nor thought hard about how/if we
could use them to work around this issue. Perhaps someone else on the
list can pipe up if they can lend a clue.

Regarding the more “brute force” solutions to the missing intrin.h
issue, I tried the following:

  1. Just steal the intrin.h from MinGW-W32 or MinGW-W64 (TDM), and
    compile with my trusty MinGW32 install. I tried both. Both failed.

  2. Compile with the TDM-GCC bi-lib distro of MinGW-W64. No joy -
    different errors than #1.

  3. Compile with MinGW-W32 (the 32bit targeted version of MinGW-W64).
    That worked cleanly.

So, I’m going to try to rebuild all the libs I depend upon with
MinGW-W32, as well as a test project or two. If all goes well, my plan
is to switch compilers and go on with life.

Unless we come up with a different solution, we should probably make
note on the wiki that MinGW32 will no longer build SDL 1.3 - MinGW-W32
is necessary.On Mon, Jan 17, 2011 at 19:27, Greg Jandl <@Greg_Jandl> wrote:

On Mon, Jan 17, 2011 at 19:00, Nathaniel J Fries wrote:

I also lack intrin.h
My MinGW installation is a recent one from the official sourceforge page.

Perhaps the solution here is to just always use the SDL library functions on
MinGW? Certainly not ideal, but…

Well, there are several options.


Do what you can, where you are, with what you have. - T. Roosevelt

Alternatively, I could just include intrin.h if we’re using Visual Studio…On Mon, Jan 17, 2011 at 8:20 PM, Greg Jandl <greg.jandl at gmail.com> wrote:

On Mon, Jan 17, 2011 at 19:27, Greg Jandl <greg.jandl at gmail.com> wrote:

On Mon, Jan 17, 2011 at 19:00, Nathaniel J Fries wrote:

I also lack intrin.h
My MinGW installation is a recent one from the official sourceforge
page.

Perhaps the solution here is to just always use the SDL library
functions on

MinGW? Certainly not ideal, but…

Well, there are several options.

So, I left one option off - gcc specific code using the gcc atomic
builtins. Haven’t worked with them, nor thought hard about how/if we
could use them to work around this issue. Perhaps someone else on the
list can pipe up if they can lend a clue.

Regarding the more “brute force” solutions to the missing intrin.h
issue, I tried the following:

  1. Just steal the intrin.h from MinGW-W32 or MinGW-W64 (TDM), and
    compile with my trusty MinGW32 install. I tried both. Both failed.

  2. Compile with the TDM-GCC bi-lib distro of MinGW-W64. No joy -
    different errors than #1.

  3. Compile with MinGW-W32 (the 32bit targeted version of MinGW-W64).
    That worked cleanly.

So, I’m going to try to rebuild all the libs I depend upon with
MinGW-W32, as well as a test project or two. If all goes well, my plan
is to switch compilers and go on with life.

Unless we come up with a different solution, we should probably make
note on the wiki that MinGW32 will no longer build SDL 1.3 - MinGW-W32
is necessary.


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Sam Lantinga wrote:

Alternatively, I could just include intrin.h if we’re using Visual Studio…

If you can detect that it’s using MinGW-W32/64 over normal old MinGW; I would recommend including it on those compilers too.

@Sindisil: I’m not sure if the GCC atomic intrinsics actually work on MinGW. Have you used them successfully before?------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

Sam Lantinga wrote:

Alternatively, I could just include intrin.h if we’re using Visual Studio…

If you can detect that it’s using MinGW-W32/64 over normal old MinGW; I would recommend including it on those compilers too.

That makes sense to me, as well.

As for how to test for MinGW-W64/W32 vs. MinGW32, at compile time you
can check for __MINGW64_VERSION_MAJOR and/or __MINGW64_VERSION_MINOR.
Both should be defined after including any standard header (or include
_mingw.h to be sure). That should be set for both W64 and W32. MinGW32
has _MINGW_VERSION*, but IIRC that’s set for MinGW-W64 based
distros, as well.

@Sindisil: I’m not sure if the GCC atomic intrinsics actually work on MinGW. Have you used them successfully before?

No, I have not, but I haven’t seen reference to anything that would
indicate that they do not work. Have you?

MinGW32 is currently on gcc 4.5.0, and MinGW-W64 (of which MinGW-W32
is simply a 32bit targeting build) is on 4.5.2. gcc atomic builtins
have been in since 4.1.2, right?

My understanding is that the support or non-support for atomic
builtins is a hardware platform issue. Well, except in that, if there
is no hardware support for a given builtin, gcc will attempt to call a
lib func to do the same, which may be an OS or overall platform issue,
I suppose.

Regardless, we should be able to check at least for basic CAS support
with the appropriately sized _GCC_HAVE_SYNC_COMPARE_AND_SWAP*
macros.On Tue, Jan 18, 2011 at 06:00, Nathaniel J Fries wrote:


Do what you can, where you are, with what you have. - T. Roosevelt

I just changed it so intrin.h is only used with Visual Studio. GCC compiled
code will just use the gcc builtin intrinsics. :)On Mon, Jan 17, 2011 at 10:47 PM, Sam Lantinga <@slouken> wrote:

Alternatively, I could just include intrin.h if we’re using Visual
Studio…

On Mon, Jan 17, 2011 at 8:20 PM, Greg Jandl <greg.jandl at gmail.com> wrote:

On Mon, Jan 17, 2011 at 19:27, Greg Jandl <greg.jandl at gmail.com> wrote:

On Mon, Jan 17, 2011 at 19:00, Nathaniel J Fries wrote:

I also lack intrin.h
My MinGW installation is a recent one from the official sourceforge
page.

Perhaps the solution here is to just always use the SDL library
functions on

MinGW? Certainly not ideal, but…

Well, there are several options.

So, I left one option off - gcc specific code using the gcc atomic
builtins. Haven’t worked with them, nor thought hard about how/if we
could use them to work around this issue. Perhaps someone else on the
list can pipe up if they can lend a clue.

Regarding the more “brute force” solutions to the missing intrin.h
issue, I tried the following:

  1. Just steal the intrin.h from MinGW-W32 or MinGW-W64 (TDM), and
    compile with my trusty MinGW32 install. I tried both. Both failed.

  2. Compile with the TDM-GCC bi-lib distro of MinGW-W64. No joy -
    different errors than #1.

  3. Compile with MinGW-W32 (the 32bit targeted version of MinGW-W64).
    That worked cleanly.

So, I’m going to try to rebuild all the libs I depend upon with
MinGW-W32, as well as a test project or two. If all goes well, my plan
is to switch compilers and go on with life.

Unless we come up with a different solution, we should probably make
note on the wiki that MinGW32 will no longer build SDL 1.3 - MinGW-W32
is necessary.


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Oops - you missed a couple. Patch below.

Also, default arch on i686-foo-bar (i686-pc-mingw, in this case) is
i386, for which there is no atomic built-in support. I had to specify
CFLAGS=-march=i686 on my configure command line.

Sadly, my autoconf-fu is weak - I’ve no clue how to nudge it into
nudging the default arch on i686 and up to -march=i686.

Anyway, with the patch below and the arch set to i686, testatomic
(also built with -march=i686, of course) seems to run correctly.

intrin patch:

diff -r 8c33dd30f6a6 src/atomic/SDL_spinlock.c
— a/src/atomic/SDL_spinlock.c Tue Jan 18 17:23:44 2011 -0800
+++ b/src/atomic/SDL_spinlock.c Tue Jan 18 22:30:15 2011 -0600
@@ -24,20 +24,12 @@
#include “SDL_atomic.h”
#include “SDL_timer.h”

-#if defined(WIN32)
-#include <intrin.h>-
-#elif defined(MACOSX)
-#include <libkern/OSAtomic.h>

-#endif

/* This function is where all the magic happens… */
SDL_bool
SDL_AtomicTryLock(SDL_SpinLock *lock)
{
-#if defined(WIN32)
+#if defined(_MSC_VER)
SDL_COMPILE_TIME_ASSERT(locksize, sizeof(lock) == sizeof(long));
return (_InterlockedExchange((long
)lock, 1) == 0);

On Tue, Jan 18, 2011 at 17:09, Sam Lantinga wrote:

I just changed it so intrin.h is only used with Visual Studio.? GCC compiled
code will just use the gcc builtin intrinsics. :slight_smile:

On Mon, Jan 17, 2011 at 10:47 PM, Sam Lantinga wrote:

Alternatively, I could just include intrin.h if we’re using Visual
Studio…

On Mon, Jan 17, 2011 at 8:20 PM, Greg Jandl <@Greg_Jandl> wrote:

On Mon, Jan 17, 2011 at 19:27, Greg Jandl <@Greg_Jandl> wrote:

On Mon, Jan 17, 2011 at 19:00, Nathaniel J Fries wrote:

I also lack intrin.h
My MinGW installation is a recent one from the official sourceforge
page.

Perhaps the solution here is to just always use the SDL library
functions on
MinGW? Certainly not ideal, but…

Well, there are several options.

So, I left one option off - gcc specific code using the gcc atomic
builtins. Haven’t worked with them, nor thought hard about how/if we
could use them to work around this issue. Perhaps someone else on the
list can pipe up if they can lend a clue.

Regarding the more “brute force” solutions to the missing intrin.h
issue, I tried the following:

  1. Just steal the intrin.h from MinGW-W32 or MinGW-W64 (TDM), and
    compile with my trusty MinGW32 install. I tried both. Both failed.

  2. Compile with the TDM-GCC bi-lib distro of MinGW-W64. No joy -
    different errors than #1.

  3. Compile with MinGW-W32 (the 32bit targeted version of MinGW-W64).
    That worked cleanly.

So, I’m going to try to rebuild all the libs I depend upon with
MinGW-W32, as well as a test project or two. If all goes well, my plan
is to switch compilers and go on with life.

Unless we come up with a different solution, we should probably make
note on the wiki that MinGW32 will no longer build SDL 1.3 - MinGW-W32
is necessary.


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt

Great, thanks!

I don’t think I’ll bump the default architecture. It’s definitely something
that people might want to do, but since it limits the processor they can run
on, it should be their decision. Plus, it doesn’t help much if SDL is built
with i686 code if the main application isn’t. :slight_smile:

See ya!On Tue, Jan 18, 2011 at 8:30 PM, Greg Jandl <greg.jandl at gmail.com> wrote:

Oops - you missed a couple. Patch below.

Also, default arch on i686-foo-bar (i686-pc-mingw, in this case) is
i386, for which there is no atomic built-in support. I had to specify
CFLAGS=-march=i686 on my configure command line.

Sadly, my autoconf-fu is weak - I’ve no clue how to nudge it into
nudging the default arch on i686 and up to -march=i686.

Anyway, with the patch below and the arch set to i686, testatomic
(also built with -march=i686, of course) seems to run correctly.

intrin patch:

diff -r 8c33dd30f6a6 src/atomic/SDL_spinlock.c
— a/src/atomic/SDL_spinlock.c Tue Jan 18 17:23:44 2011 -0800
+++ b/src/atomic/SDL_spinlock.c Tue Jan 18 22:30:15 2011 -0600
@@ -24,20 +24,12 @@
#include “SDL_atomic.h”
#include “SDL_timer.h”

-#if defined(WIN32)
-#include <intrin.h>

-#elif defined(MACOSX)
-#include <libkern/OSAtomic.h>

-#endif

/* This function is where all the magic happens… */
SDL_bool
SDL_AtomicTryLock(SDL_SpinLock *lock)
{
-#if defined(WIN32)
+#if defined(_MSC_VER)
SDL_COMPILE_TIME_ASSERT(locksize, sizeof(lock) == sizeof(long));
return (_InterlockedExchange((long
)lock, 1) == 0);

On Tue, Jan 18, 2011 at 17:09, Sam Lantinga <@slouken> wrote:

I just changed it so intrin.h is only used with Visual Studio. GCC
compiled
code will just use the gcc builtin intrinsics. :slight_smile:

On Mon, Jan 17, 2011 at 10:47 PM, Sam Lantinga <@slouken> wrote:

Alternatively, I could just include intrin.h if we’re using Visual
Studio…

On Mon, Jan 17, 2011 at 8:20 PM, Greg Jandl <greg.jandl at gmail.com> wrote:

On Mon, Jan 17, 2011 at 19:27, Greg Jandl <greg.jandl at gmail.com> wrote:

On Mon, Jan 17, 2011 at 19:00, Nathaniel J Fries <nfries88 at yahoo.com wrote:

I also lack intrin.h
My MinGW installation is a recent one from the official sourceforge
page.

Perhaps the solution here is to just always use the SDL library
functions on
MinGW? Certainly not ideal, but…

Well, there are several options.

So, I left one option off - gcc specific code using the gcc atomic
builtins. Haven’t worked with them, nor thought hard about how/if we
could use them to work around this issue. Perhaps someone else on the
list can pipe up if they can lend a clue.

Regarding the more “brute force” solutions to the missing intrin.h
issue, I tried the following:

  1. Just steal the intrin.h from MinGW-W32 or MinGW-W64 (TDM), and
    compile with my trusty MinGW32 install. I tried both. Both failed.

  2. Compile with the TDM-GCC bi-lib distro of MinGW-W64. No joy -
    different errors than #1.

  3. Compile with MinGW-W32 (the 32bit targeted version of MinGW-W64).
    That worked cleanly.

So, I’m going to try to rebuild all the libs I depend upon with
MinGW-W32, as well as a test project or two. If all goes well, my plan
is to switch compilers and go on with life.

Unless we come up with a different solution, we should probably make
note on the wiki that MinGW32 will no longer build SDL 1.3 - MinGW-W32
is necessary.


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Sure, though it means a failed build by default on i686-pc-mingw.

I did some digging, and I think I’ve found a better solution. By
including some additional .m4 macros in the acinclude directory
(http://www.gnu.org/software/autoconf-archive/ax_check_compiler_flags.html,
http://www.gnu.org/software/autoconf-archive/ax_gcc_archflag.html and
http://www.gnu.org/software/autoconf-archive/ax_gcc_x86_cpuid.html)
then using the patch below (same as previous patch + one line change
to configure.in), SDL will build correctly out of the box.

The arch can then be overridden by --with-gcc-arch= (most will
probably want to build with i686 there for general distribution) or
–without-gcc-arch, to disable setting the arch all together.

On my Atom netbook, I get -march=PentiumPro by default, which works
great, as does --with-gcc-arch=i686.

Personally, I’d prefer the works by default config, but it’s obviously
your call!

diff -r 8c33dd30f6a6 configure.in
— a/configure.in Tue Jan 18 17:23:44 2011 -0800
+++ b/configure.in Wed Jan 19 00:14:04 2011 -0600
@@ -48,6 +48,7 @@

dnl Detect the canonical build and host environments
dnl AC_CANONICAL_HOST
+AX_GCC_ARCHFLAG([no])

dnl Check for tools
AC_PROG_LIBTOOL
diff -r 8c33dd30f6a6 src/atomic/SDL_spinlock.c
— a/src/atomic/SDL_spinlock.c Tue Jan 18 17:23:44 2011 -0800
+++ b/src/atomic/SDL_spinlock.c Wed Jan 19 00:14:04 2011 -0600
@@ -24,20 +24,12 @@
#include “SDL_atomic.h”
#include “SDL_timer.h”

-#if defined(WIN32)
-#include <intrin.h>On Wed, Jan 19, 2011 at 00:13, Sam Lantinga wrote:

Great, thanks!

I don’t think I’ll bump the default architecture.? It’s definitely something
that people might want to do, but since it limits the processor they can run
on, it should be their decision.? Plus, it doesn’t help much if SDL is built
with i686 code if the main application isn’t. :slight_smile:

-#elif defined(MACOSX)
-#include <libkern/OSAtomic.h>

-#endif

/* This function is where all the magic happens… */
SDL_bool
SDL_AtomicTryLock(SDL_SpinLock *lock)
{
-#if defined(WIN32)
+#if defined(_MSC_VER)
SDL_COMPILE_TIME_ASSERT(locksize, sizeof(lock) == sizeof(long));
return (_InterlockedExchange((long
)lock, 1) == 0);

See ya!

On Tue, Jan 18, 2011 at 8:30 PM, Greg Jandl <@Greg_Jandl> wrote:

Oops - you missed a couple. Patch below.

Also, default arch on i686-foo-bar (i686-pc-mingw, in this case) is
i386, for which there is no atomic built-in support. I had to specify
CFLAGS=-march=i686 on my configure command line.

Sadly, my autoconf-fu is weak - I’ve no clue how to nudge it into
nudging the default arch on i686 and up to -march=i686.

Anyway, with the patch below and the arch set to i686, testatomic
(also built with -march=i686, of course) seems to run correctly.

intrin patch:

diff -r 8c33dd30f6a6 src/atomic/SDL_spinlock.c
— a/src/atomic/SDL_spinlock.c Tue Jan 18 17:23:44 2011 -0800
+++ b/src/atomic/SDL_spinlock.c Tue Jan 18 22:30:15 2011 -0600
@@ -24,20 +24,12 @@
?#include “SDL_atomic.h”
?#include “SDL_timer.h”

-#if defined(WIN32)
-#include <intrin.h>

-#elif defined(MACOSX)
-#include <libkern/OSAtomic.h>

-#endif

?/* This function is where all the magic happens… */
?SDL_bool
?SDL_AtomicTryLock(SDL_SpinLock *lock)
?{
-#if defined(WIN32)
+#if defined(_MSC_VER)
? ? SDL_COMPILE_TIME_ASSERT(locksize, sizeof(lock) == sizeof(long));
? ? return (_InterlockedExchange((long
)lock, 1) == 0);

On Tue, Jan 18, 2011 at 17:09, Sam Lantinga wrote:

I just changed it so intrin.h is only used with Visual Studio.? GCC
compiled
code will just use the gcc builtin intrinsics. :slight_smile:

On Mon, Jan 17, 2011 at 10:47 PM, Sam Lantinga wrote:

Alternatively, I could just include intrin.h if we’re using Visual
Studio…

On Mon, Jan 17, 2011 at 8:20 PM, Greg Jandl <@Greg_Jandl> wrote:

On Mon, Jan 17, 2011 at 19:27, Greg Jandl <@Greg_Jandl> wrote:

On Mon, Jan 17, 2011 at 19:00, Nathaniel J Fries wrote:

I also lack intrin.h
My MinGW installation is a recent one from the official sourceforge
page.

Perhaps the solution here is to just always use the SDL library
functions on
MinGW? Certainly not ideal, but…

Well, there are several options.

So, I left one option off - gcc specific code using the gcc atomic
builtins. Haven’t worked with them, nor thought hard about how/if we
could use them to work around this issue. Perhaps someone else on the
list can pipe up if they can lend a clue.

Regarding the more “brute force” solutions to the missing intrin.h
issue, I tried the following:

  1. Just steal the intrin.h from MinGW-W32 or MinGW-W64 (TDM), and
    compile with my trusty MinGW32 install. I tried both. Both failed.

  2. Compile with the TDM-GCC bi-lib distro of MinGW-W64. No joy -
    different errors than #1.

  3. Compile with MinGW-W32 (the 32bit targeted version of MinGW-W64).
    That worked cleanly.

So, I’m going to try to rebuild all the libs I depend upon with
MinGW-W32, as well as a test project or two. If all goes well, my plan
is to switch compilers and go on with life.

Unless we come up with a different solution, we should probably make
note on the wiki that MinGW32 will no longer build SDL 1.3 - MinGW-W32
is necessary.


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt

Okay, let’s try it! :)On Tue, Jan 18, 2011 at 10:25 PM, Greg Jandl <greg.jandl at gmail.com> wrote:

On Wed, Jan 19, 2011 at 00:13, Sam Lantinga <@slouken> wrote:

Great, thanks!

I don’t think I’ll bump the default architecture. It’s definitely
something
that people might want to do, but since it limits the processor they can
run
on, it should be their decision. Plus, it doesn’t help much if SDL is
built
with i686 code if the main application isn’t. :slight_smile:

Sure, though it means a failed build by default on i686-pc-mingw.

I did some digging, and I think I’ve found a better solution. By
including some additional .m4 macros in the acinclude directory
(http://www.gnu.org/software/autoconf-archive/ax_check_compiler_flags.html
,
http://www.gnu.org/software/autoconf-archive/ax_gcc_archflag.html and
http://www.gnu.org/software/autoconf-archive/ax_gcc_x86_cpuid.html)
then using the patch below (same as previous patch + one line change
to configure.in), SDL will build correctly out of the box.

The arch can then be overridden by --with-gcc-arch= (most will
probably want to build with i686 there for general distribution) or
–without-gcc-arch, to disable setting the arch all together.

On my Atom netbook, I get -march=PentiumPro by default, which works
great, as does --with-gcc-arch=i686.

Personally, I’d prefer the works by default config, but it’s obviously
your call!

diff -r 8c33dd30f6a6 configure.in
— a/configure.in Tue Jan 18 17:23:44 2011 -0800
+++ b/configure.in Wed Jan 19 00:14:04 2011 -0600
@@ -48,6 +48,7 @@

dnl Detect the canonical build and host environments
dnl AC_CANONICAL_HOST
+AX_GCC_ARCHFLAG([no])

dnl Check for tools
AC_PROG_LIBTOOL
diff -r 8c33dd30f6a6 src/atomic/SDL_spinlock.c
— a/src/atomic/SDL_spinlock.c Tue Jan 18 17:23:44 2011 -0800
+++ b/src/atomic/SDL_spinlock.c Wed Jan 19 00:14:04 2011 -0600
@@ -24,20 +24,12 @@
#include “SDL_atomic.h”
#include “SDL_timer.h”

-#if defined(WIN32)
-#include <intrin.h>

-#elif defined(MACOSX)
-#include <libkern/OSAtomic.h>

-#endif

/* This function is where all the magic happens… */
SDL_bool
SDL_AtomicTryLock(SDL_SpinLock *lock)
{
-#if defined(WIN32)
+#if defined(_MSC_VER)
SDL_COMPILE_TIME_ASSERT(locksize, sizeof(lock) == sizeof(long));
return (_InterlockedExchange((long
)lock, 1) == 0);

See ya!

On Tue, Jan 18, 2011 at 8:30 PM, Greg Jandl <greg.jandl at gmail.com> wrote:

Oops - you missed a couple. Patch below.

Also, default arch on i686-foo-bar (i686-pc-mingw, in this case) is
i386, for which there is no atomic built-in support. I had to specify
CFLAGS=-march=i686 on my configure command line.

Sadly, my autoconf-fu is weak - I’ve no clue how to nudge it into
nudging the default arch on i686 and up to -march=i686.

Anyway, with the patch below and the arch set to i686, testatomic
(also built with -march=i686, of course) seems to run correctly.

intrin patch:

diff -r 8c33dd30f6a6 src/atomic/SDL_spinlock.c
— a/src/atomic/SDL_spinlock.c Tue Jan 18 17:23:44 2011 -0800
+++ b/src/atomic/SDL_spinlock.c Tue Jan 18 22:30:15 2011 -0600
@@ -24,20 +24,12 @@
#include “SDL_atomic.h”
#include “SDL_timer.h”

-#if defined(WIN32)
-#include <intrin.h>

-#elif defined(MACOSX)
-#include <libkern/OSAtomic.h>

-#endif

/* This function is where all the magic happens… */
SDL_bool
SDL_AtomicTryLock(SDL_SpinLock *lock)
{
-#if defined(WIN32)
+#if defined(_MSC_VER)
SDL_COMPILE_TIME_ASSERT(locksize, sizeof(lock) == sizeof(long));
return (_InterlockedExchange((long
)lock, 1) == 0);

On Tue, Jan 18, 2011 at 17:09, Sam Lantinga <@slouken> wrote:

I just changed it so intrin.h is only used with Visual Studio. GCC
compiled
code will just use the gcc builtin intrinsics. :slight_smile:

On Mon, Jan 17, 2011 at 10:47 PM, Sam Lantinga <@slouken> wrote:

Alternatively, I could just include intrin.h if we’re using Visual
Studio…

On Mon, Jan 17, 2011 at 8:20 PM, Greg Jandl <greg.jandl at gmail.com> wrote:

On Mon, Jan 17, 2011 at 19:27, Greg Jandl <greg.jandl at gmail.com> wrote:

On Mon, Jan 17, 2011 at 19:00, Nathaniel J Fries wrote:

I also lack intrin.h
My MinGW installation is a recent one from the official
sourceforge

page.

Perhaps the solution here is to just always use the SDL library
functions on
MinGW? Certainly not ideal, but…

Well, there are several options.

So, I left one option off - gcc specific code using the gcc atomic
builtins. Haven’t worked with them, nor thought hard about how/if we
could use them to work around this issue. Perhaps someone else on
the

list can pipe up if they can lend a clue.

Regarding the more “brute force” solutions to the missing intrin.h
issue, I tried the following:

  1. Just steal the intrin.h from MinGW-W32 or MinGW-W64 (TDM), and
    compile with my trusty MinGW32 install. I tried both. Both failed.

  2. Compile with the TDM-GCC bi-lib distro of MinGW-W64. No joy -
    different errors than #1.

  3. Compile with MinGW-W32 (the 32bit targeted version of MinGW-W64).
    That worked cleanly.

So, I’m going to try to rebuild all the libs I depend upon with
MinGW-W32, as well as a test project or two. If all goes well, my
plan

is to switch compilers and go on with life.

Unless we come up with a different solution, we should probably make
note on the wiki that MinGW32 will no longer build SDL 1.3 -
MinGW-W32

is necessary.


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Okay, let’s try it! :slight_smile:

I jumped the gun on that previous patch - it doesn’t get the correct
flags into sdl-config.

I think the patch below works correctly: sdl-config gets the -march
flag and SDL builds fine. Perhaps there’s a better way to get the
-march flag into both CFLAGS and SDL_FLAGS w/o dragging along more
cruft, but adding it to BASE_CFLAGS seemed the best bet to my eyes.

Anyway, sorry for the fire drill - I should probably not be submitting
patches at this time of the morning. I hope this patch works well for
everyone.

—<patch against original configure.in, not my previous patch>—
diff -r 8c33dd30f6a6 configure.in
— a/configure.in Tue Jan 18 17:23:44 2011 -0800
+++ b/configure.in Wed Jan 19 01:25:01 2011 -0600
@@ -83,6 +83,7 @@
BASE_LDFLAGS=""
;;
esac
+AX_GCC_ARCHFLAG([no], [BASE_CFLAGS="$BASE_CFLAGS $ax_cv_gcc_archflag]")
BUILD_CFLAGS="$CFLAGS $CPPFLAGS"

The default optimization for SDL 1.3 is -O3 (Bug #31)

if test x$orig_CFLAGS = x; thenOn Wed, Jan 19, 2011 at 00:41, Sam Lantinga wrote:

On Tue, Jan 18, 2011 at 10:25 PM, Greg Jandl <@Greg_Jandl> wrote:

On Wed, Jan 19, 2011 at 00:13, Sam Lantinga wrote:

Great, thanks!

I don’t think I’ll bump the default architecture.? It’s definitely
something
that people might want to do, but since it limits the processor they can
run
on, it should be their decision.? Plus, it doesn’t help much if SDL is
built
with i686 code if the main application isn’t. :slight_smile:

Sure, though it means a failed build by default on i686-pc-mingw.

I did some digging, and I think I’ve found a better solution. By
including some additional .m4 macros in the acinclude directory

(http://www.gnu.org/software/autoconf-archive/ax_check_compiler_flags.html,
http://www.gnu.org/software/autoconf-archive/ax_gcc_archflag.html and
http://www.gnu.org/software/autoconf-archive/ax_gcc_x86_cpuid.html)
then using the patch below (same as previous patch + one line change
to configure.in), SDL will build correctly out of the box.

The arch can then be overridden by --with-gcc-arch= (most will
probably want to build with i686 there for general distribution) or
–without-gcc-arch, to disable setting the arch all together.

On my Atom netbook, I get -march=PentiumPro by default, which works
great, as does --with-gcc-arch=i686.

Personally, I’d prefer the works by default config, but it’s obviously
your call!

diff -r 8c33dd30f6a6 configure.in
— a/configure.in ? ? ?Tue Jan 18 17:23:44 2011 -0800
+++ b/configure.in ? ? ?Wed Jan 19 00:14:04 2011 -0600
@@ -48,6 +48,7 @@

?dnl Detect the canonical build and host environments
?dnl AC_CANONICAL_HOST
+AX_GCC_ARCHFLAG([no])

?dnl Check for tools
?AC_PROG_LIBTOOL
diff -r 8c33dd30f6a6 src/atomic/SDL_spinlock.c
— a/src/atomic/SDL_spinlock.c Tue Jan 18 17:23:44 2011 -0800
+++ b/src/atomic/SDL_spinlock.c Wed Jan 19 00:14:04 2011 -0600
@@ -24,20 +24,12 @@
?#include “SDL_atomic.h”
?#include “SDL_timer.h”

-#if defined(WIN32)
-#include <intrin.h>

-#elif defined(MACOSX)
-#include <libkern/OSAtomic.h>

-#endif

?/* This function is where all the magic happens… */
?SDL_bool
?SDL_AtomicTryLock(SDL_SpinLock *lock)
?{
-#if defined(WIN32)
+#if defined(_MSC_VER)
? ? SDL_COMPILE_TIME_ASSERT(locksize, sizeof(lock) == sizeof(long));
? ? return (_InterlockedExchange((long
)lock, 1) == 0);

See ya!

On Tue, Jan 18, 2011 at 8:30 PM, Greg Jandl <@Greg_Jandl> wrote:

Oops - you missed a couple. Patch below.

Also, default arch on i686-foo-bar (i686-pc-mingw, in this case) is
i386, for which there is no atomic built-in support. I had to specify
CFLAGS=-march=i686 on my configure command line.

Sadly, my autoconf-fu is weak - I’ve no clue how to nudge it into
nudging the default arch on i686 and up to -march=i686.

Anyway, with the patch below and the arch set to i686, testatomic
(also built with -march=i686, of course) seems to run correctly.

intrin patch:

diff -r 8c33dd30f6a6 src/atomic/SDL_spinlock.c
— a/src/atomic/SDL_spinlock.c Tue Jan 18 17:23:44 2011 -0800
+++ b/src/atomic/SDL_spinlock.c Tue Jan 18 22:30:15 2011 -0600
@@ -24,20 +24,12 @@
?#include “SDL_atomic.h”
?#include “SDL_timer.h”

-#if defined(WIN32)
-#include <intrin.h>

-#elif defined(MACOSX)
-#include <libkern/OSAtomic.h>

-#endif

?/* This function is where all the magic happens… */
?SDL_bool
?SDL_AtomicTryLock(SDL_SpinLock *lock)
?{
-#if defined(WIN32)
+#if defined(_MSC_VER)
? ? SDL_COMPILE_TIME_ASSERT(locksize, sizeof(lock) == sizeof(long));
? ? return (_InterlockedExchange((long
)lock, 1) == 0);

On Tue, Jan 18, 2011 at 17:09, Sam Lantinga wrote:

I just changed it so intrin.h is only used with Visual Studio.? GCC
compiled
code will just use the gcc builtin intrinsics. :slight_smile:

On Mon, Jan 17, 2011 at 10:47 PM, Sam Lantinga wrote:

Alternatively, I could just include intrin.h if we’re using Visual
Studio…

On Mon, Jan 17, 2011 at 8:20 PM, Greg Jandl <@Greg_Jandl> wrote:

On Mon, Jan 17, 2011 at 19:27, Greg Jandl <@Greg_Jandl> wrote:

On Mon, Jan 17, 2011 at 19:00, Nathaniel J Fries wrote:

I also lack intrin.h
My MinGW installation is a recent one from the official
sourceforge
page.

Perhaps the solution here is to just always use the SDL library
functions on
MinGW? Certainly not ideal, but…

Well, there are several options.

So, I left one option off - gcc specific code using the gcc atomic
builtins. Haven’t worked with them, nor thought hard about how/if
we
could use them to work around this issue. Perhaps someone else on
the
list can pipe up if they can lend a clue.

Regarding the more “brute force” solutions to the missing intrin.h
issue, I tried the following:

  1. Just steal the intrin.h from MinGW-W32 or MinGW-W64 (TDM), and
    compile with my trusty MinGW32 install. I tried both. Both failed.

  2. Compile with the TDM-GCC bi-lib distro of MinGW-W64. No joy -
    different errors than #1.

  3. Compile with MinGW-W32 (the 32bit targeted version of
    MinGW-W64).
    That worked cleanly.

So, I’m going to try to rebuild all the libs I depend upon with
MinGW-W32, as well as a test project or two. If all goes well, my
plan
is to switch compilers and go on with life.

Unless we come up with a different solution, we should probably
make
note on the wiki that MinGW32 will no longer build SDL 1.3 -
MinGW-W32
is necessary.


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt

Argh.

Just noticed the lack of snippage in my last several messages.
Sometimes when I’m tired I miss the tiny “show quoted text” link in
gmail.

Apologies to the list for the slip up!–
Do what you can, where you are, with what you have. - T. Roosevelt

The more I think about it, the more it seems like suddenly forcing a
specific architecture requirement is a bad idea. I checked in your
suggestion, but it’s commented out for now.

Let’s take this offline and figure out the best solution for your particular
problem.On Tue, Jan 18, 2011 at 11:41 PM, Greg Jandl <greg.jandl at gmail.com> wrote:

On Wed, Jan 19, 2011 at 00:41, Sam Lantinga <@slouken> wrote:

Okay, let’s try it! :slight_smile:

I jumped the gun on that previous patch - it doesn’t get the correct
flags into sdl-config.

I think the patch below works correctly: sdl-config gets the -march
flag and SDL builds fine. Perhaps there’s a better way to get the
-march flag into both CFLAGS and SDL_FLAGS w/o dragging along more
cruft, but adding it to BASE_CFLAGS seemed the best bet to my eyes.

Anyway, sorry for the fire drill - I should probably not be submitting
patches at this time of the morning. I hope this patch works well for
everyone.

—<patch against original configure.in, not my previous patch>—
diff -r 8c33dd30f6a6 configure.in
— a/configure.in Tue Jan 18 17:23:44 2011 -0800
+++ b/configure.in Wed Jan 19 01:25:01 2011 -0600
@@ -83,6 +83,7 @@
BASE_LDFLAGS=""
;;
esac
+AX_GCC_ARCHFLAG([no], [BASE_CFLAGS="$BASE_CFLAGS $ax_cv_gcc_archflag]")
BUILD_CFLAGS="$CFLAGS $CPPFLAGS"

The default optimization for SDL 1.3 is -O3 (Bug #31)

if test x$orig_CFLAGS = x; then

On Tue, Jan 18, 2011 at 10:25 PM, Greg Jandl <greg.jandl at gmail.com> wrote:

On Wed, Jan 19, 2011 at 00:13, Sam Lantinga <@slouken> wrote:

Great, thanks!

I don’t think I’ll bump the default architecture. It’s definitely
something
that people might want to do, but since it limits the processor they
can

run
on, it should be their decision. Plus, it doesn’t help much if SDL is
built
with i686 code if the main application isn’t. :slight_smile:

Sure, though it means a failed build by default on i686-pc-mingw.

I did some digging, and I think I’ve found a better solution. By
including some additional .m4 macros in the acinclude directory

(
http://www.gnu.org/software/autoconf-archive/ax_check_compiler_flags.html,

http://www.gnu.org/software/autoconf-archive/ax_gcc_archflag.html and
http://www.gnu.org/software/autoconf-archive/ax_gcc_x86_cpuid.html)
then using the patch below (same as previous patch + one line change
to configure.in), SDL will build correctly out of the box.

The arch can then be overridden by --with-gcc-arch= (most will
probably want to build with i686 there for general distribution) or
–without-gcc-arch, to disable setting the arch all together.

On my Atom netbook, I get -march=PentiumPro by default, which works
great, as does --with-gcc-arch=i686.

Personally, I’d prefer the works by default config, but it’s obviously
your call!

diff -r 8c33dd30f6a6 configure.in
— a/configure.in Tue Jan 18 17:23:44 2011 -0800
+++ b/configure.in Wed Jan 19 00:14:04 2011 -0600
@@ -48,6 +48,7 @@

dnl Detect the canonical build and host environments
dnl AC_CANONICAL_HOST
+AX_GCC_ARCHFLAG([no])

dnl Check for tools
AC_PROG_LIBTOOL
diff -r 8c33dd30f6a6 src/atomic/SDL_spinlock.c
— a/src/atomic/SDL_spinlock.c Tue Jan 18 17:23:44 2011 -0800
+++ b/src/atomic/SDL_spinlock.c Wed Jan 19 00:14:04 2011 -0600
@@ -24,20 +24,12 @@
#include “SDL_atomic.h”
#include “SDL_timer.h”

-#if defined(WIN32)
-#include <intrin.h>

-#elif defined(MACOSX)
-#include <libkern/OSAtomic.h>

-#endif

/* This function is where all the magic happens… */
SDL_bool
SDL_AtomicTryLock(SDL_SpinLock *lock)
{
-#if defined(WIN32)
+#if defined(_MSC_VER)
SDL_COMPILE_TIME_ASSERT(locksize, sizeof(lock) == sizeof(long));
return (_InterlockedExchange((long
)lock, 1) == 0);

See ya!

On Tue, Jan 18, 2011 at 8:30 PM, Greg Jandl <greg.jandl at gmail.com> wrote:

Oops - you missed a couple. Patch below.

Also, default arch on i686-foo-bar (i686-pc-mingw, in this case) is
i386, for which there is no atomic built-in support. I had to specify
CFLAGS=-march=i686 on my configure command line.

Sadly, my autoconf-fu is weak - I’ve no clue how to nudge it into
nudging the default arch on i686 and up to -march=i686.

Anyway, with the patch below and the arch set to i686, testatomic
(also built with -march=i686, of course) seems to run correctly.

intrin patch:

diff -r 8c33dd30f6a6 src/atomic/SDL_spinlock.c
— a/src/atomic/SDL_spinlock.c Tue Jan 18 17:23:44 2011 -0800
+++ b/src/atomic/SDL_spinlock.c Tue Jan 18 22:30:15 2011 -0600
@@ -24,20 +24,12 @@
#include “SDL_atomic.h”
#include “SDL_timer.h”

-#if defined(WIN32)
-#include <intrin.h>

-#elif defined(MACOSX)
-#include <libkern/OSAtomic.h>

-#endif

/* This function is where all the magic happens… */
SDL_bool
SDL_AtomicTryLock(SDL_SpinLock *lock)
{
-#if defined(WIN32)
+#if defined(_MSC_VER)
SDL_COMPILE_TIME_ASSERT(locksize, sizeof(lock) == sizeof(long));
return (_InterlockedExchange((long
)lock, 1) == 0);

On Tue, Jan 18, 2011 at 17:09, Sam Lantinga <@slouken> wrote:

I just changed it so intrin.h is only used with Visual Studio. GCC
compiled
code will just use the gcc builtin intrinsics. :slight_smile:

On Mon, Jan 17, 2011 at 10:47 PM, Sam Lantinga <@slouken wrote:

Alternatively, I could just include intrin.h if we’re using Visual
Studio…

On Mon, Jan 17, 2011 at 8:20 PM, Greg Jandl <greg.jandl at gmail.com wrote:

On Mon, Jan 17, 2011 at 19:27, Greg Jandl <greg.jandl at gmail.com> wrote:

On Mon, Jan 17, 2011 at 19:00, Nathaniel J Fries wrote:

I also lack intrin.h
My MinGW installation is a recent one from the official
sourceforge
page.

Perhaps the solution here is to just always use the SDL
library

functions on
MinGW? Certainly not ideal, but…

Well, there are several options.

So, I left one option off - gcc specific code using the gcc
atomic

builtins. Haven’t worked with them, nor thought hard about how/if
we
could use them to work around this issue. Perhaps someone else on
the
list can pipe up if they can lend a clue.

Regarding the more “brute force” solutions to the missing
intrin.h

issue, I tried the following:

  1. Just steal the intrin.h from MinGW-W32 or MinGW-W64 (TDM), and
    compile with my trusty MinGW32 install. I tried both. Both
    failed.
  1. Compile with the TDM-GCC bi-lib distro of MinGW-W64. No joy -
    different errors than #1.

  2. Compile with MinGW-W32 (the 32bit targeted version of
    MinGW-W64).
    That worked cleanly.

So, I’m going to try to rebuild all the libs I depend upon with
MinGW-W32, as well as a test project or two. If all goes well, my
plan
is to switch compilers and go on with life.

Unless we come up with a different solution, we should probably
make
note on the wiki that MinGW32 will no longer build SDL 1.3 -
MinGW-W32
is necessary.


Do what you can, where you are, with what you have. - T.
Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Do what you can, where you are, with what you have. - T. Roosevelt


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

That’s fine.

I persontally don’t have a problem - I know that, to build with
MinGW32, I need to pass CFLAGS=-mingw=i686 (or better) to configure.
I’m not sure how else the build will work on x86 with gcc any other
way, as the atomic built-ins that SDL_atomic depends upon are only
available for -march>= i686.

In fact, I’m wondering how x86 Linux can build w/o an -march flag set.On Wed, Jan 19, 2011 at 02:09, Sam Lantinga wrote:

The more I think about it, the more it seems like suddenly forcing a
specific architecture requirement is a bad idea.? I checked in your
suggestion, but it’s commented out for now

Let’s take this offline and figure out the best solution for your particular
problem.


Do what you can, where you are, with what you have. - T. Roosevelt