Juha Niemimä
On AmigaOS 4 platform with Newlib 'C' library, there is a problem with failing fseeko64. This seemed to be caused by using fopen instead of fopen64.
Ozkan Sezer
(In reply to Ryan C. Gordon from comment #9)
> I've put this patch in as https://hg.libsdl.org/SDL/rev/117d4ce1390e ...can
> you verify this works on the latest MinGW?
>
> Thanks,
> --ryan.
This patch is wrong: the structure in question has nothing to do with any
gcc version in use. I suggest reverting this adding a conigury check for
it, instead. Something like the following should do it: (configure needs
regenerating.)
http://jackaudio.org/
Fixes Bugzilla #2163.
(with several more commits following to improve this code.)
--HG--
extra : rebase_source : 5d0d44fcca077c41c56381575a45184bdc050003
Apparently this is no longer a generic BSD audio target, and hasn't been for
years, so rename it for NetBSD.
--HG--
rename : src/audio/bsd/SDL_bsdaudio.c => src/audio/netbsd/SDL_netbsdaudio.c
rename : src/audio/bsd/SDL_bsdaudio.h => src/audio/netbsd/SDL_netbsdaudio.h
Joshua Bodine
I'm going to reopen this because configure should still accurately report whether libudev will be used. Right now it just tests whether it's enabled as an argument, not whether configure was successful in finding it.
Kai Sterker
SDL2 on Haiku so far uses Haiku-specific APIs for loading dynamic objects as add-ons, instead of using dlopen to load them as libraries. This, for example, leads to SDL_mixer not being able to load its audio backends, when compiled with standard settings.
As discussed at https://www.freelists.org/post/haikuports/SDL2-mixer-ogg-music-not-playing-and-other-stuff,2 , the best way to deal with this would be using dlopen instead of load_add_on. The following patch implements this change by dropping the Haiku-specific bits and using dlopen instead.
Weitian Leung
Just moved ibus direct call to SDL_IME_* related functions, and adds fcitx IME support (uses DBus, too),
enable with env: SDL_IM_MODULE=fcitx (ibus still the default one)
Generate the C protocol files from the protocol XML files installed by
wayland-protocols, and use them to implement support for relative pointer
motions and pointer locking.
Note that at the time, the protocol is unstable and may change in the future.
Any future breaking changes will, however, fail gracefully and result in no
regressions compared to before this patch.
Since we are loading shared objects dynamically, build our own version of the
core protocol symbols, so that we in the future can include protocol
extensions.
This will help catch things that'll cause issues on C89 compilers before we
send them on to fail on Buildbot.
--HG--
extra : amend_source : 2a21da040338a9f796b8baf7038cf866ce54b595
