Setting the tag type will let libtool work even when it cannot infer
the type of the code being built. One way libtool may fail to infer
the tag type is if one uses a mock compiler (such as for static
analysis).
The D3D11 renderer is now slightly faster than D3D9 on my Windows 8 machine (testsprite2 runs at 3400 FPS vs 3100 FPS)
This will need tweaking to fix the Windows RT build.
configure wraps this C code in a main() function, so you can't declare a
function body in there. Besides, I'm not sure why we declared a function
that's part of the multitouch API anyhow.
Now we just reference a type that only exists if the headers have multitouch
support and call it a day.
Brian Minton
When building static or shared libraries on cygwin 1.7.25 on Windows 7 (32-bit), I get the following link errors:
build/.libs/SDL_windowskeyboard.o: In function `UIElementSink_QueryInterface@12':
/home/c-bminton/src/SDL/src/video/windows/SDL_windowskeyboard.c:995: undefined reference to `IID_IUnknown'
build/.libs/SDL_windowskeyboard.o: In function `IPPASink_QueryInterface@12':
/home/c-bminton/src/SDL/src/video/windows/SDL_windowskeyboard.c:1101: undefined reference to `IID_IUnknown'
collect2: error: ld returned 1 exit status
Makefile:126: recipe for target 'build/libSDL2.la' failed
make: *** [build/libSDL2.la] Error 1
--
The libuuid from e2fsprogs is completely unrelated to the w32api UUID.DLL implib. FWIW, any *NIX software that I've seen obviously wants the e2fsprogs version, but if libuuid-devel is installed (in /usr/lib) then you can't link against the w32api implib with a simple -luuid.
We'll flip the default back to enabled right after 2.0.2 is finalized, and
try to declare them stable and ready by 2.0.3.
Those that have an interest in supporting them in 2.0.2 can manually enable
them in the configure script with --enable-video-wayland and/or
--enable-video-mir.
Based on the original port to Wayland by: Joel Teichroeb, Benjamin Franzke, Scott Moreau, et al.
Additional changes in this commit, done by me:
* Wayland uses the common EGL framework
* EGL can now create a desktop OpenGL context
* testgl2 loads GL functions dynamically, no need to link to libGL anymore
* Assorted fixes to the Wayland backend
Tested on the Weston Compositor (v1.0.5) that ships with Ubuntu 13.10,
running Weston under X. Tests ran: testrendercopyex (all backends), testgl2, testgles2,testintersections
Haiku uses most of the standard pthread API, with a few #ifdefs where we
still need to fallback onto the old BeOS APIs.
BeOS, however, does not support pthreads (or maybe doesn't support it well),
so I'm unplugging support for the platform with this changeset. Be Inc went
out of business in 2001.
Joseph Carter
There's a whole set of configure tests for BSD's libusbhid, and they only matter on BSD. However, if you have the library on Linux, it gets pulled in as library bloat. And it's bloat of the highest order since not a single function call to the library is ever made unless you're on a *BSD.
Andreas
With the patch applied, make is not able to find the rule for Makefile.in anymore. Removing the patch resolves the issue.
The path is in fact correct (in my case: /c/external/SDL64/SDL). But it seems the windows build of GNU Make doesn't work well with pathnames in rules. Both the dependencies in "$(srcdir)/configure: $(srcdir)/configure.in" and "Makefile: $(srcdir)/Makefile.in" will cause rules not to be found when srcdir is defined.
The same problem occurs if the patch is removed and I supply configure with a srcdir manually.
The configure script was still overwriting SIZEOF_VOIDP so both ended up as either 4 or 8 depending on the arch. This simply removes the check from configure.in
This #errors if you're using an SDK or deployment target that is less
than 10.6 and 10.5, respectively, and cleans up uses of
MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED according
to those requirements.
Unexplicable computer sciences phenomenon: Instead of returning an empty set,
*.c in an folder with no .c files produces the "*.c" string to be added as
a source. I'm sorry future generations, we are doing the best we can :)
Axel Dörfler
Currently, the default install target for Haiku is /boot/develop/tools/gnupro. However, this is not the expected install place. Instead, /boot/common should be used.
leighmanthegreat@hotmail.com
I downloaded SDL2 from hg source.
I built to a ./build directory.
I downloaded SDL_image 2 hg and attempted to build.
When it cannot find a sdl2-config the SDL_image configure correctly suggests setting SDL_CONFIG variable.
Setting this the configure still fails with 'Permission denied' on the call to sdl2-config.
Setting execute permission solves the problem.
If possible, sdl2-config should have executable bit set when it is created.
tomaszewski.p
Recent changes in SDL_sysrenderer.h and SDL_sysvideo.h had no impact on directfb backend.
Attached patch:
- updates interface,
- resolves uninitialized variable reading,
- changes logging tio use SDL_Log API,
- updates configure to use DIRECTFBCONFIG variable instead direct call to directfb-config.
This uses libudev for hotplug, but it's optional, so we'll just try to find
some reasonable defaults without it (maybe an older Linux box or under
FreeBSD's Linux emulation?).
The OpenBSD case is puzzling - it's complaining about symbols in the C library. Do we need to explicitly link with -lc for shared libraries on OpenBSD?
The BeOS case is legitimate, it's calling back into the application code to initialize BeApp if it isn't already initialized.
It's a long-dead platform, and we don't have any way to build for, test, or
maintain it, so there's no sense in doing acrobatics to support it.
If you need Windows CE support, use SDL 1.2. If you need Windows Phone support,
send SDL 2.0 patches for the newer Windows Mobile platform.
Brad Smith 2012-07-19 11:39:09 PDT
I noticed this error from the OpenBSD/amd64 buildbot log..
../configure[15018]: test: -O2: unexpected operator/operand
The attached patch fixes the issue.
2.Replaced XKeycodeToKeysym with XkbKeycodeToKeysym since XKeycodeToKeysym is deprecated in newer X11 version
3.Rewrote testime.c since it was disabled after SDL_compat.c removal
4.Take into account common arguments also in testrelative.c
1.initial work on XInput2 support
2.Implemented relative mouse motion when XInput2 is enabled
3.Created a test app to test relative mouse motion
4.Fixed Bug #1498
It was very confusing to have configure generate an SDL_config.h and then not have it be used when building on Mac OS X or Windows. I'll just have to remember to use SDL_config_windows.h when building official releases that are supposed to be ABI compatible with Visual Studio.
Scott Percival 2011-07-03 06:41:51 PDT
This submission is aimed at making life easier for OpenGL ES capable devices
running a X11 stack (e.g. Maemo, Meego, TrimSlice, other ARM SoC boards not
running Android). SDL's Pandora support already has the neccesary GLES-to-X11
glue code, however it's all ghetto'd off in Makefile.pandora and not very
flexible.
The patch:
- adds an awesome --enable-video-opengles option to configure
- re-modifies the opengles and opengles2 SDL_renderers to use function pointers
- no idea why this was removed?
- for SDL_Renderers, links in libGLESv1_CM, libGLES_CM (for PowerVR fans) or
libGLESv2 at runtime
- links in libEGL.so at runtime - the old code made an assumption that
eglFunctions could be pulled from the active GLES library, PowerVR for one
doesn't let you do that with their libGLESv2
- allows you to pick which of GLES v1 or v2 to load via
SDL_GL_CONTEXT_MAJOR_VERSION
So far I've tested this on a Nokia N900 (OMAP 3430/SGX 530 running Maemo 5) and
a Toshiba AC100 (Tegra 2 running Ubuntu 10.10). I haven't tested it on... well,
everything that isn't those two, such as a Pandora, iOS or Android device. The
Pandora specific code should be kept intact (fingers crossed), and nothing
painfully drastic has been added to the SDL_renderers. The library loading
sequence in SDL_x11opengles has been updated to accomodate both NVIDIA's
propensity to let developers get away with murder and PowerVR's alternative of
punishing every missed step.
The test apps work okay with GLES or GLES2 as the renderer. For some reason
alpha blending doesn't seem to work on the Tegra 2; last week NVIDIA pushed out
a new set of X11 GLES drivers, so I'll try and investigate once I upgrade
those. Also, this patch adds things to configure.in, include/SDL_config.h.in
and test/configure.in. I didn't know what the policy was re. committing
generated spaghetti from autotools, so ./autogen.sh has to be run again. Sorry.
I think that's about everything, let me know if there's anything I've
overlooked.
t.grundner@goto3d.de 2011-09-01 03:59:17 PDT
I figured out what is going on. GCC 4.5.2 assumes the stack is 16 byte aligned
by default. Therefore there are no AND alignment corrections necessary if we
wish to align a stack variable to a 16 byte boundary. That is bad if your OS
ABI is not 16 byte aligned. Windows 32 bit stacks are 4 byte aligned. This
results in the above mentioned SIGSEGV. This is also no problem if I compile
both SDL.dll and my app with MingW because MinGW/GCC inserts a
andl $-16, %esp
instruction right in the beginning of the main function. So at least the stack
of the thread calling the main function is 16 byte aligned. But as soon as I
start to use the SDL.dll from an application not compiled by MinGW there is no
ANDL safing my app.
However there is a GCC option that can change the default stack alignment:
-mpreferred-stack-boundary=num
Setting num=2 assumes a the stack is aligned to a 4 byte boundary. This results
in GCC inserting the necessary
andl $-16, %esp
into SDL_FillRect. Rebuilding SDL with
./configure "CFLAGS=-mpreferred-stack-boundary=2 -g -O3"
solved the problem.
IMHO this should also be a problem on Solaris.
The following links contain further information:
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Optionshttp://www.agner.org/optimize/calling_conventions.pdf
attached is a working directfb driver diff which works with the current
changes. There are a number of changes around it as well, e.g.
configure.in.
The directfb renderdriver right now still depends on a some "includes"
from src/video/directfb. That's why it is not yet moved to the new
render folder.
when .cc files are used due to bad sed substitution on multiple passes:
$(objects)/SDL_BeApp.lo:
$(objects)/SDL_BeApp.lo: ./src/main/beos/SDL_BeApp.c
$(LIBTOOL) --mode=compile $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -c $< -o $@c
$(LIBTOOL) --mode=compile $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -c $< -o $@
Signed-off-by: François Revol
The configure script was breaking the substitutions into multiple fragments, breaking them across the substitution for the build rules. This of course totally hosed the process.
I switched to using a more modern usage of AC_OUTPUT and added a post-process step that appends the build rules to the Makefile.
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.
Changed the CAS return value to bool, so it's efficient with OSAtomicCompareAndSwap32Barrier()
Added an atomic test adapted from code by Michael Davidsaver
(1) SDL_atomic dummy version in SDL 1.3 is not used.
Because src/atomic/dummy/*.c are not used.
(2) Typo in src/joystick/bsd/SDL_sysjoystick.c.
Thanks,
IWATSUKI Hiroyuki
I made a video driver GAPI/RAW for WinCE (SDL-1.3).
RAW mode has a priority, and also, GAPI mode works with environment
"SDL_VIDEO_RENDERER=gapi" and for RAW mode "SDL_VIDEO_RENDERER=raw".
I checked the work on the screens of VGA, WVGA, QVGA, WQVGA, HVGA,
+ tested all modes with WindowsMobile Emulator.
Also, correctly draws the pointer position and the scale of the pointer
for VGA/WVGA modes,
correctly draws top left position for DM orientation screen, and
portrait/landscape/square geometry the screen also correct.
Also, I added a small fix for GDI fullscreen mode.
Patch for latest revision SDL-1.3 in an attachment.
Also added small path for mingw32ce build.
Ozkan Sezer 2010-02-06 12:31:06 PST
Hi:
Here are some small fixes for compiling SDL against mingw-w64.
(see http://mingw-w64.sourceforge.net/ . Despite the name, it
supports both win32 and win64.)
src/audio/windx5/directx.h and src/video/windx5/directx.h (both
SDL-1.2 and SDL-1.3.) I get compilation errors about some union
not having a member named u1 and alike, because of other system
headers being included before this one and them already defining
DUMMYUNIONNAME and stuff. This header probably assumes that those
stuff are defined in windef.h, but mingw-w64 headers define them
in _mingw.h. Easily fixed by moving NONAMELESSUNION definition to
the top of the file.
src/thread/win32/SDL_systhread.c (both SDL-1.2 and SDL-1.3.) :
The __GNUC__ case for pfnSDL_CurrentBeginThread is 32-bit centric
because _beginthreadex returns uintptr_t, not unsigned long which
is 32 bits in win64. Changing the return type to uintptr_t fixes
it.
video/SDL_blit.h (and configure.in) (SDL-1.3-only) : MinGW-w64
uses msvcrt version of _aligned_malloc and _aligned_free and
they are defined in intrin.h (similar to VC). Adding proper
ifdefs fixes it. (Notes about macros to check: __MINGW32__ is
defined for both mingw.org and for mingw-w64 for both win32 and
win64, __MINGW64__ is only defined for _WIN64, so __MINGW64__
can't be used to detect mingw-w64: including _mingw.h and then
checking for __MINGW64_VERSION_MAJOR does the trick.)
SDL_win32video.h (SDL-1.3-only) : Tweaked the VINWER definition
and location in order to avoid multiple redefinition warnings.
Hope these are useful. Thanks.
Patrice Mandin
Hello,
I originally added pth support for threads in SDL 1.2 because on the Atari
platform we did not have any thread library.
I think pth support could be removed from SDL 1.3 for two reasons:
- Atari platform removed
- pth does not provides real (preemptive) threads, because it is user space,
and expect the application to call one of its function to give CPU to another
thread. So it is not exactly useful for applications, that expect threads to
run simultaneously.
GNU-isms should be avoided wherever possible for portability, please avoid the use of GNU-isms in your code, this may be problematic when using this library in projects which use non-GNU-compliant compilers.
Jack Jansen 2009-11-05 14:20:22 PST
I'm building "fat" SDL 1.3 libraries for MacOSX, but now I am running into the
issue that audio does not work on PowerPC macintoshes if you build the library
on an Intel.
The problem is that configure hard-codes the byteorder, which is then stored in
SDL_config.h
