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