sdl12-compat VS rust-bindgen

I'm just glad so many of the SDL 1.2.x-era games dynamically linked SDL so I can use sdl12-compat to stick them on top of SDL 2.x's non-modesetting fullscreening and PulseAudio support.

Thankfully, most people don't statically link SDL 1.2, so it's possible to use sdl12compat to rebase them on top of SDL 2.x's non-modesetting fullscreening support, among other things.

There have been some efforts to keep them working: http://www.improbability.net/loki/ https://github.com/libsdl-org/sdl12-compat/

I've been determined to get the only system not on the device working in some way. The biggest issue to the Apple II systems not being present is that all the emulators are not written in SDL2 and the only Apple II emulator written in SDL2 (shamusworld) is far from perfect. So I tried my hand at something: What if I could wrap SDL1.2 to SDL2 against linapple? My brother showed me on github sdl12-compat https://github.com/libsdl-org/sdl12-compat. Amazingly enough, we have results. Now it's not going to be as functional this way like having RetroArch to configure things, but I have over twenty Apple II games pre-configured with controls thus far.

You need this compatibility library and you can drop it into the "lib" folder in the game files.

Here's the only useful link from the article: https://github.com/libsdl-org/sdl12-compat/releases/tag/release-1.2.52

It looks like the multiple monitor issue was known and theoretically fixed? https://github.com/libsdl-org/sdl12-compat/issues/38

Really old Linux games based on SDL1 can also work on Wayland by using the SDL1 on SDL2 wrapper in combination with a recent SDL2 build (I've been successful with Psychonauts this way, and it even solved some weird windowing problems with the game)

Rust supports two kinds of FFI: calling into Rust from another language; and calling into another language from Rust. Most of the thought and tooling that exists right now is organized around the second kind. For example, bindgen is a popular tool that generates useful Rust wrappers from a C or C++ header file.

I have looked into bindgen, but found that it would not be feasible due to OMPL not having a C API, just C++.

Yes! Are you running LLVM version 16.0.0 or newer, by any chance? I believe this is an issue with some builds of bindgen with newer versions of LLVM. See https://github.com/rust-lang/rust-bindgen/issues/2488

On native, you have to define a C API, probably using a header file. Even if both sides are implemented in Rust, they have to speak that C API (documentation).

Bindgen has some functionality for direct talk to C++ https://github.com/rust-lang/rust-bindgen

I am trying to use rust-bindgen (https://github.com/rust-lang/rust-bindgen) to link a static C library (say `libexample.a`) which is compiled in a separate project with CMake. The `libexample.a` depends on other libraries (for example `libcurl.a`) installed on the system.

It looks like the guy you're replying too was kind of an ass, but I do want to point out for anyone else reading that that's not actually that much of a technical limitation: rust code can natively call C code. The main thing you need is a translation of the C library's header file so rustc knows what C functions and structs exist, and that can be automatically generated with bindgen.

It's quite the different approach, but you could consider using bindgen instead.

Use bindgen or CXX to create Rust bindings for the C or C++ libraries.