From: "Mike Gorchak"
Subject: New QNX patches
Please apply patch qnx4.diff, which is attached. What has been done:
1)Added back OpenGL ES renderer for QNX target. Added few corrections to
OpenGL ES renderer to let it work under QNX. OpenGL ES renderer do not
support textures under QNX, so I think some additional work must be done.
2) Added GL_OES_query_matrix extension to SDL_opengles.h header file, which
required by OpenGL ES 1.1 specification.
3) Added attribute clearing at the entrance of function
SDL_GL_GetAttribure(). Added error checking into the function
SDL_GL_GetAttribure(), because some attributes can't be obtained in OpenGL
ES 1.0.
4) Porting testdyngles to OpenGL ES 1.0 (1.1 has glColor4ub() and
glColor4f() functions, but 1.0 has glColor4f() only).
5) Added error checking after obtaining attributes using
SDL_GL_GetAttribute() function to the testgl2 and testgles.
6) Small correction to testmultiaudio with printing errors.
7) Added software and accelerated OpenGL ES 1.0 support into the QNX GF
driver.
Please remove ./src/audio/nto directory - it will not be used anymore.
Please create ./src/audio/qsa directory and add content of the archive
qsa.tar.gz into this directory. I rewrote some sound code, added support for
multiple audio cards, enumeration, etc. Added initial support for capture.
As far as I can understand SDL 1.3 is not supporting audio capture right now
? Sam, Am I right ? Or audio capture must be supported through the
PlayDevice routine ?
And last, please put file SDL_gf_opengles.c to the ./src/video/qnxgf
directory. It is OpenGL ES 1.1 emulation layer for some functions, which are
not supported by OpenGL ES 1.0.
From: Stefan Klug
Subject: [SDL] SDL 1.3 WinCE backend
as promised, I've started to work on the WinCE backend of SDL 1.3
I've modified the win32 video backend and the gdi renderer, to work
properly in WinCE.
The results till now are great, but there is still some work to do.
Attached are two patches with my changes.
I would be happy if someone could review and propably commit them.
The first one (configure.in.patch) should be straight forward without
any side effects.
The second one does the necessary changes to the win32 backend. I was
really unhappy to start slicing this shiny new backend with
#ifdef/#endif but I saw no other option.
The most problematic issues are:
- WinCe has no GetDIBits, so its practically impossible to fill a
BITMAPINFO with correct values. I therefore removed the bmi member from
the GDI_RenderData in SDL_gdirender.c to prevent usage of a not or not
properly initialized bmi.
- In SDL_win32window.c I exchanged some ASCII function by their general
counterparts, (In CE only the Unicode versions are available). I don't
know if this has a negative effect when running in win32
Cheers
Stefan
From: "Mike Gorchak"
Subject: Re: About QNX support in SDL 1.3
Here is another batch of patches.
1) Makefile.in - added SDL_opengles.h header as header to install.
2) configure.in - Added special define to detect Common Lite OpenGL ES
library in case if Common library is not installed. Added check for
clock_gettime in libc (in QNX it is in libc).
3) SDL_config.h.in - Added SDL_VIDEO_RENDER_OPENGL_ES and
SDL_VIDEO_OPENGL_ES declarations for configure script autodetection.
4) SDL_opengles.h - Added GL_API definition if it is not defined. Added
extension GL_OES_draw_texture because OpenGL ES Renderer uses it without
declaration. Added GL_OES_vertex_buffer_object extension, which is supported
under QNX OpenGL ES. Added GL_OES_single_precision extension.
5) To the test directory I've added building OpenGL ES test applications
through the autotools suite. Was support for iPhone IDE building only.
From: "Mike Gorchak"
Subject: About QNX support in SDL 1.3
Right now I'm working on QNX SDL 1.3 drivers implementation and looks like a
lot of code must be completely reworked. But I'm ready for it :) Also I want
to add QNX Graphics Framework SDL driver, which is fullscreen graphics
framework, with support of hardware accelerated OpenGL ES implementations.
This Graphics Framework (called GF in QNX) could also use QNX Photon (window
manager GUI) as window manager.
In the attachment initial patch for QNX support in SDL 1.3
* Some math functions become intrinsic in release mode, so we need to
convert all the math functions into SDL math functions, like we did
with the stdlib functions.
* Constant initializers of 8-bit values become calls to memset() in
release mode, but memset() itself is an intrinsic when explicitly
called. So we'll just explicitly call memset() in those cases.
Subject: SDL. macos build problem
When I try to cross-build SDL1.3 r4362 it fails for macos. It seems there
is a typo in configure.in. Please, consider attached patch.
Mikle
From: Couriersud
Subject: SDL1.3 DirectFB patches
The attached contains the following directfb changes:
- Dynamic loading of libdirectfb.so. This may to turned off as well in configure
- Use linux-input by default. May be switched off by environment variable.
- Added some code which will use directfb's x11 backend when DISPLAY is set.
From: Couriersud
Subject: Fusionsound audio driver
attached is a diff containing a audio driver for the FusionSound
library. This sound library is closely related to DirectFB and uses the
same transport (fusion) as DirectFB when running applications "remote",
i.e. over the network. As such, it natively redirects sound where
DirectFB redirects video. This may be handy for everyone using SDL over
DirectFB.
One or two things got moved around, but largely this is hooked up correctly
in the Unix configure system now: it can be dynamically loaded and fallback
gracefully if not available, or libXi can be directly linked to libSDL.
XInput support can be --disable'd from the configure script, too (defaults to
enabled).
Please note that while the framework is in place to gracefully fallback, the
current state of the source requires XInput. We'll need to adjust a few
things still to correct this.
Many-mouse and tablet support
by Szymon Wilczek, mentored by Ryan C. Gordon
Everything concerning the project is noted on the wiki:
http://wilku.ravenlord.ws/doku.php?id=start
Prepping for using MMX and SSE intrinsics instead of inline assembly.
.. except for memcpy equivalents which only get faster if they can
exploit the parallelism of loading into multiple SIMD registers. :)
available and to keep people form having to install yet another library I have added the essential parts of Xmu in
src/video/extensions/XmuStdCmap and an include file in src/video/extensions. The support makes use of standard X11 mechanisms to
create color maps and make sure that an application uses the same color map for each window/visual combination. This should make it
possible for gamma support to be implemented based on a single color map per application.
Hurm... it looks like "make indent" modified a few extra files. Those are getting committed too.
Subject: ALLOCA Patch for SDL-1.2
Newsgroups: gmane.comp.lib.sdl
Date: 2006-10-24 00:31:16 GMT
Hello !
As alloca.h is not available on CYGWIN and MinGW32
it should not be checked there or it should be checked
with -mno-cygwin using.
I am a total configure.in newbie, but i found the way
that things are handled in configure.in pretty bad for the
case CYGWIN with MinGW Mode or not.
Maybe this is not possible but i would like to
have a way to detect at the start for example CYGWIN
and then add. ask if configure was called with --enable-cygwin
for example. --enable-cygwin should be optional and disabled
by default as we want to have MinGW Mode by default.
Only if the user wants it he should be able to use it.
Then the whole configure.in would get add. questions
okay the system is CYGWIN with or without MinGW Mode.
The alloca.h thing for example is only
available under CYGWIN ( without MinGW Mode ).
CU
Hi,
if "configure" is given an explicit --libdir, the sdl-config still contains
the default "${exec_prefix}/lib" for runtime linker path.
That should be changed to $libdir, as this is where the library goes to...
Regards,
Juergen
[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
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.
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
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
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.
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.
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.
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.
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.
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
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
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
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.
From: "alan buckley"
Subject: Re: Updating SDL for RISC OS
I've attached a zip file with three diffs to get SDL to build on RISC OS.
configure.in.diff and makedeps.sh.diff have been modified so that they
can build the assembler file in video/riscos. You may want to double
check these as I don't know a lot about unix shell programming.
(I've tested them cross-compiling on cygwin).
sdlsysthread.diff is the changes required to SDL_systhread.c for RISC
OS. As you suspected with these changes in place you can delete the
RISC OS specific threading code in thread/riscos.
I've also renamed SDL_riscosASM.s to SDL_riscosASM.S, but I'm never
quite sure how to rename files in CVS, so if you could to this it would
be appreciated.
From: Hayashi Naoyuki
Subject: Re: [SDL] CVS stable again, please update SDL ports
Some problems are caused on Tru64 UNIX.
If applying SDL12-osf1.path, these problems are fixed.
1. configure-script say "recursive mutexes... no" and "pthread
semaphores... no".
checking for pthreads... yes
checking for recursive mutexes... no
checking for pthread semaphores... no
This is because it compiled without pthread_cflags and pthread_lib when
checking recursive mutexes and pthread semaphores.
2. Compiling src/audio/mme/SDL_mmeaudio.c fails.
cc: Severe: ./src/audio/mme/SDL_mmeaudio.c, line 25: Cannot find file
<mme_api.h> specified in #include directive. (noinclfilef)
#include <mme_api.h>
-^
This is because BUILD_CFLAGS is wrong.
3. Compiling src/cdrom/osf/SDL_syscdrom.c fails.
cc: Warning: ./src/cdrom/osf/SDL_syscdrom.c, line 176: Too few actual
parameters in the invocation of the macro "SDL_stack_alloc". (toofewactuals)
cdpath = SDL_stack_alloc(len);
------------------------------------^
cc: Error: ./src/cdrom/osf/SDL_syscdrom.c, line 176: Invalid expression.
(badexpr)
cdpath = SDL_stack_alloc(len);
-----------------^
SDL_stack_alloc is defined in include/SDL_stdinc.h.
#define SDL_stack_alloc(type, count) (type*)alloca(sizeof(type)*count)
4. Linking fails if running configure with --enable-x11-shared=yes.
/usr/ccs/bin/ld:
Warning: Unresolved:
p_XData32
5. Compiling src/video/x11/SDL_x11dyn.c fails if running configure with
--enable-x11-shared=no.
cc: Error: ./src/video/x11/SDL_x11sym.h, line 149: In this statement,
"_SmtBufferOverflow" is not declared. (undeclared)
SDL_X11_SYM(1,void,_SmtBufferOverflow,(Display *dpy,register smtDisplayPtr))
^
cc: Error: ./src/video/x11/SDL_x11sym.h, line 150: In this statement,
"_SmtBufferOverflow" is not declared. (undeclared)
SDL_X11_SYM(1,void,_SmtBufferOverflow,(Display *dpy,register smtDisplayPtr))
^
cc: Error: ./src/video/x11/SDL_x11sym.h, line 150: In this statement,
"_SmtIpError" is not declared. (undeclared)
SDL_X11_SYM(1,void,_SmtIpError,(Display *dpy,register smtDisplayPtr, int))
^
changed in five years, and it's a small .c file that just calls into the X11
dependencies we already use elsewhere. Including it directly allows us to
make use of the dynamic X11 code.
Fixes Bugzilla #41.
--ryan.
From: Alberto Mardegan <mardy@users.sourceforge.net>
To: sdl@libsdl.org
Subject: [SDL] [PATCH] Touchscreen support to fbcon via tslib
Hi all!
I'm new to this list, I just subscribed. I've attached to this e-mail
a patch I've written in order to add Touchscreen support to SDL's fbcon
module via the tslib library.
Since it introduces a new dependency, I've also edited the the
configure.in file and added it as a compile-time option.
This patch is especially useful for handhelds (I've tested it in my
Zaurus).
Please consider applying it. :-)
--
Saluti,
Mardy
http://interlingua.altervista.org
From: Olivier Boudeville <olivier.boudeville@online.fr>
To: "A list for developers using the SDL library. \(includes SDL-announce\)" <sdl@libsdl.org>
Subject: [SDL] NetBSD build patch
Hi everybody,
apparently the SDL-1.2.9 source archive could not compile "as is" on
NetBSD 2.0_STABLE due to a pthread detection issue in the configure script.
I attached a small patch that can be applied to configure.in so that SDL
can be directly (i.e. without the NetBSD package manager) configured and
built successfully on NetBSD (at least on the one I tried !).
Hope this helps,
Olivier.
From: Staffan Ulfberg <staffan@ulfberg.se>
Date: 19 Nov 2005 01:00:48 +0100
Subject: [SDL] New driver for OpenBSD/wscons
Hello,
I've written an SDL driver for OpenBSD/wscons (console mode, somewhat
resembling the functionality of the svga driver for Linux). I use it
for playing MAME on my Sharp Zaurus. The alternative is to play under
X, which is slower.
I asked how to submit the driver a few days ago, and posted a link to
the patch in a follow-up, so maybe it was missed?
Anyway, the patch is on the web at:
http://multivac.fatburen.org/SDL-wscons.patch
Comments?
Staffan
--ryan.
Date: Sun, 19 Jun 2005 15:53:22 -0700
From: Joshua Oreman <oremanj@gmail.com>
To: sdl@libsdl.org
Subject: [SDL] [PATCH] iPod framebuffer video driver
Hi SDL-list,
I've been working on a port of SDL to iPodLinux
(http://www.ipodlinux.org). I've created a patch for both the
standard 2-bit iPod screen (using an unchangeable palette) and the
16-bit iPod photo. The patch is attached, against version 1.2.8.
I've created two pages on the iPodLinux wiki about this patch:
http://www.ipodlinux.org/Building_SDL and
http://www.ipodlinux.org/SDL_Programming. See those pages if you're
curious.
Comments? Questions? Is this something that might be able to get into SDL 1.2.9?
Thanks for your feedback!
-- Josh
--ryan.
From: Mike Frysinger <vapier@gentoo.org>
To: sdl@libsdl.org
Subject: Re: [SDL] sdl, sdl-mixer not compiling with uclibc
Date: Wed, 7 Sep 2005 19:17:49 -0400
in this case actually, the error is in libsdl
the configure check for dlvsym presence is pretty pointless, it currently
always detects it
AC_TRY_COMPILE([
#include <stdio.h>
#define __USE_GNU
#include <dlfcn.h>
],[
dlvsym(NULL,"","");
],[
use_dlvsym=yes
])
since it's merely compiling, the warning about dlvsym being implicitly
declared doesnt trigger a failure
find attached a patch to fix this
-mike
To: SDL Developers <sdl@libsdl.org>
From: =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb@algonet.se>
Date: Mon, 30 May 2005 23:29:04 +0200
Subject: [SDL] Mac OS X Video Drivers [patch]
I've updated/added the Carbon and X11 video drivers
to the Mac OS X port of SDL 1.2 (the CVS version),
and made the Cocoa driver and runtime *optional*.
The default is still Cocoa, and the "Quartz" driver.
But you can now also use "toolbox" for Carbon, and
"x11" for running with Apple's (or other) X11 server:
export SDL_VIDEODRIVER=x11
export SDL_VIDEO_GL_DRIVER=/usr/X11R6/lib/libGL.dylib
It also checks if the frameworks are available, by a:
#include <Carbon/Carbon.h> or #import <Cocoa/Cocoa.h>
(this should make it configure on plain Darwin as well?)
Here are the new configure targets:
--enable-video-cocoa use Cocoa/Quartz video driver default=yes
--enable-video-carbon use Carbon/QuickDraw video driver default=yes
--enable-video-x11 use X11 video driver default=no
./configure --enable-video-cocoa --enable-video-carbon
--enable-video-x11 \
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
The Carbon version is just an updated version of the old
SDL driver for Mac OS 9, and could probably be improved...
(but it does work, including the Carbon version of SDLmain)
If you disable cocoa, you can run with -framework Carbon only,
and the C version of SDL_main.c. And if you disable carbon too,
you can still use the X11 version which doesn't require SDLmain.
I updated the DrawSprocket version, but did not include it.
(no blitters or VRAM GWorlds etc. available on OS X anyway)
Besides for Mac OS 9, I don't think there's any use for it ?
And note that any performance on Mac OS X equals OpenGL anyway...
You can get "fair" software SDL results on captured CG displays,
but for decent frame rates you need to be using GL for rendering.
Finally, here is the patch itself:
http://www.algonet.se/~afb/SDL-12CVS-macvideo.patch
--anders
PS. It says "video", but as usual it applies to mouse/keyboard too.
------
To: A list for developers using the SDL library <sdl@libsdl.org>
From: =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb@algonet.se>
Date: Sun, 4 Sep 2005 10:02:15 +0200
Subject: [SDL] Updated Mac patch
Updated the previous Mac patch to disable Carbon by default.
Also "fixed" the SDL.spec again, so that it builds on Darwin.
http://www.algonet.se/~afb/SDL-1.2.9-mac.patch
Also applied fine to SDL12 CVS, when I tried it.
From: "Ryan C. Gordon"
Subject: [Fwd: SDL patch: make usage of rpath optional]
Here's a small patch against current SDL CVS that makes usage of rpath
optional, by passing --disable-rpath to configure. This comes in handy
when redistributing SDL -- the rpath setting prevents the lib being
loaded if it's not in the rpath, which makes redistributing in packages
to be installed by non-root users pretty much useless.
From: Johannes Schmidt
Subject: [PATCH] Re: [SDL] SDL 1.2.8 Prerelease
On Saturday 18 December 2004 13:59, Stephane Marchesin wrote:
> >#error "The kernel sources in /usr/src/linux are not yet configured."
> >#error "Please run 'make cloneconfig && make dep' in /usr/src/linux/"
> >#error "to get a kernel that is configured like the running kernel."
> >#error "Alternatively, you can copy one of the config files"
> >#error "arch/$ARCH/defconfig.* to .config, and run"
> >#error "'make oldconfig && make dep' to configure the kernel"
> >#error "for that configuration."
> >-
>
> That's the Suse kernel sources...
> I think the only way out is to add a test in ./configure
Attached is a patch (it works for me[TM]) which adds a CheckLinuxVersion() to
configure.in and a check for HAVE_LINUX_VERSION_H to
src/cdrom/linux/SDL_syscdrom.c.
From: Peter Naulls
Subject: RISC OS SDL Patches
Sam, I've attached a diff of the latest changes to libSDL for RISC OS
support. These changes are by Alan Buckley and myself.
The most significant of these are:
Optimised assembler blit rountines - I've attached the file
src/video/riscos/SDL_riscosASM.s which is needed for this.
Move to using /dev/dsp instead of its own audio implementation.
This means that src/audio/riscos/SDL_drenderer.c should be removed
Typo fixes. Mainly correct spelling of "RISC OS", but some from elsewhere
too.
From: Hayashi Naoyuki
Subject: SDL patch for Tru64 UNIX 4.0X
SDL-1.2.8 support only Tru64 5.X.
This patch is for Tru64 UNIX 4.X.(tested on Tru64 UNIX 4.0G and 5.1B)
SDL-1.2.8/configure.in:
ld doesn't accept -pthread option.
cc -pthread has same effect as -D_REENTRANT when compiling,
and has same effect as -lpthread -lexc when linking.
SDL-1.2.8/include/begin_code.h:
Old Compaq C Compiler accept not inline but __inline.
SDL-1.2.8/src/audio/SDL_mixer_MMX.c:
SDL-1.2.8/src/audio/SDL_mixer_MMX.h:
Old Compaq C Compiler doesn't accept //.
SDL-1.2.8/src/cdrom/osf/SDL_syscdrom.c:
When becoming Tru64 v5.0 from Tru64 v4.0,
the arrangement of the cd-rom device was changed.
From: "alan buckley"
Subject: Modification for RISC OS version of SDL
Ive attached a zip file with the changes to this email, it contains the
following:
The file sdldiff.txt is the output from cvs diff u. .
The directory thread/riscos contains all the new files to support threading.
Readme.riscos is a new readme file to add.
From: Martin_Storsj
Subject: Update for dynamic loading of ALSA
I sent you a patch a few months ago which enables SDL to load ALSA
dynamically. Now I've finally got time to tweak this yet some more. I've
added code from alsa.m4 (from alsa's dev package) to acinclude.m4, and
made the detection of the alsa library name a bit better. I've also
fixed up the loading versioned symbols with dlvsym, so that it falls
back to dlsym.
I wouldn't say the configure script is complete yet, but this is how far
I've come this time, and I'm no expert at those things.
