with their private symbols hidden. If that isn't the case, and someone
tries to enable it anyway, spit out a warning and don't let them do it.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401884
[patch tweaked to handle older nasm, which doesn't support :function syntax]
------- Comment #5 From Mike Frysinger 2006-05-22 01:24 [reply] -------
Created an attachment (id=132) [edit]
libsdl-hidden-nasm.patch
here's the patch i posted here:
http://www.libsdl.org/pipermail/sdl/2006-March/073618.html
this will hide the symbols dynamically if the build nasm/yasm supports the
hidden stuff ... in other words, this patch should be safe with both older and
new versions of nasm/yasm
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401873
Added DirectInput joystick code, contributed by Glenn Maynard.
This fixes a problem with the Windows Multimedia joystick driver
not showing all 6 axes on a GameCube controller converter, which
was donated by Jacob Kolding.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401820
I'm guessing we probably should, but I don't remember why this
was added in the first place. I'm disabling it for now...
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401783
From: Mike Frysinger
Subject: [SDL] [patch] teach configure about uClinux
the current configure script doesnt know about the uclinux target so this
patch fixes that
-mike
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401781
Disable screensaver and DPMS blanking while SDL app is running.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401742
From: Mike Frysinger
Subject: [SDL] [patch] touchup configure --help output
the current output includes a lot of "default=yes" stuff in it ... except that
it lacks the [] around it
patch attached to fix the situation
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401644
The SDL platform header shouldn't dictate the OS target API for other
applications. The build system should define the target API for building
SDL internally.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401635
The attached patch is mostly cosmetic: Currently, we always add both -framework
OpenGL and -framework AGL for Mac OS X command line builds.
However, the former is only used for the Cocoa video driver, and the latter
only for the Carbon video driver (as far as I can tell, at least). Hence the
attached patch modifies configure.in so that each only gets added to the list
of frameworks if the corresponding video driver is enabled.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401632
The change made to sdl-config.in on March 18 (rev 11, see
http://www.libsdl.org/cgi/cvsweb.cgi/SDL12/sdl-config.in), broke static linking
under Mac OS X for unix style build systems. In other words, "sdl-config
--static-libs" no longer produces the correct output, as it is missing the
required -framework switches.
The attached patch fixes this.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401631
The proper name of Apple's operating system is "Mac OS X" not "MacOS X", as can
bee seen in many places, for example http://www.apple.com/macosx/). This
contrasts the naming of the old operating system, which was called "MacOS" and
today is often refered to as "MacOS Classic".
The attached patches fixes the misuse of the name "MacOS X" in both the SDL12
and sdlweb CVS modules.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401628
The attached patch changes configure.in to use "-framework FOO" instead of
"-Wl,-framework,FOO".
This avoid some issues with certain versions of libtool that do not handle
-framework properly.
Some versions of libtool will try to reorder the two parts of the option, or
render the 2nd part of the argument to the relative path of a non-existent
library.
Note: It is not enough if SDL uses a version of libtool that does this
correctly, because these -framework options show up in "sdl-config --libs".
Hence, some 3rd party apps which still ship with an old libtool have troubles
compiling under Mac OS X.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401618
The configure script parses the value of $X_LIBS when looking at the
--enable-x11-shared, which is getting set on Ubuntu 5.10 to "-L/usr/X11R6/lib"
... however, Ubuntu stores all the Xlib stuff in /usr/lib.
The end result in SDL is that the dynamic X11 stuff gets disabled by default,
unless you override like this:
./configure --x-libraries=/usr/lib
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401573
Integrated most of the NetBSD and DragonFly patches at:
ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/SDL/patches/
Thanks to Thomas Klausner for defailed information on the patches
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401569
Date: Sun, 23 Oct 2005 16:39:03 +0200
From: "A. Schmid" <sahib@phreaker.net>
Subject: [SDL] no software surfaces with svgalib driver?
Hi,
I noticed that the SDL (1.2.9) svgalib driver only makes use of linear
addressable (framebuffer) video modes. On older systems (like one of
mine), linear addressable modes are often not available.
Especially for cards with VESA VBE < 2.0 the svgalib vesa driver is
unusable, since VESA only supports framebuffering for VBE 2.0 and later.
The changes necessary to add support for software surfaces seem to be
relatively small. I only had to hack src/video/svga/SDL_svgavideo.c (see
attached patch). The code worked fine for me, but it is no more than a
proof of concept and should be reviewed (probably has a memory leak when
switching modes). It also uses the vgagl library (included in the
svgalib package) and needs to be linked against it.
-Alex
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401559
From the autoconf obsolete macros documentation:
Macro: AC_CANONICAL_SYSTEM
Determine the system type and set output variables to the names of the canonical system types. See section Getting the Canonical System Type, for details about the variables this macro sets.
The user is encouraged to use either AC_CANONICAL_BUILD, or AC_CANONICAL_HOST, or AC_CANONICAL_TARGET, depending on the needs. Using AC_CANONICAL_TARGET is enough to run the two other macros.
From the documentation for the canonical environments:
case $target in
i386-*-mach* | i386-*-gnu*)
obj_format=aout emulation=mach bfd_gas=yes ;;
i960-*-bout) obj_format=bout ;;
esac
Note that the above example uses $target because it's taken from a tool which can be built on some architecture ($build), run on another ($host), but yet handle data for a third architecture ($target). Such tools are usually part of a compiler suite, they generate code for a specific $target.
However $target should be meaningless for most packages. If you want to base a decision on the system where your program will be run, make sure you use the $host variable.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401554
SDL_LIBS are the linker flags and libraries needed to build SDL applications.
SDL_STATIC_LIBS is set to SDL_LIBS by default.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401552
