Porting to SDL3, SDL_image.h hets error unknown type name SDL_IOStream

SDL Development
1

Hi SDL3 Devs! :slight_smile:

I just spent many hours updating my project from SDL2x and SDL 3.2. But there is one issue I have been unable to solve: when I include SDL_image.h (the SDL3 version), the compiler claims SDL_IOStream is undefined. I confirmed that SDL_Image.h is including <SDL3/SDL.h>, and that this header is version 3.2.4. But I can’t see that anything is including <SDL3/SDL_iostream.h>.

Is this no longer included by default?
Update: Even if I explicitly include <SDL3/SDL_iostream.h> before <SDL3_iamge/SDL_image.h>, it does not fix the error.

Thanks for the help.

  • Jeff
2

Hi everyone. Spent several more hours converting everything from SDL2->SDL3. Sadly, the python script was of no use, because it required additional source code I didn’t have.

The good news: The SDL_IOStream error went away! :slight_smile:
The bad news? my XCode project refuses to dynamically load the SDL3 libraries, saying " not valid for use in process: library load disallowed by system policy". In the signing and capabilities, I have checked Automatically manage signing and for MacOS, for signing certificate, I have Sign to Run Locally.

I know this is strictly a MacOS / XCode issue, but any advice would be appreciated from MacOS users. Clearly, the previous project worked. Hmmm.

I am currently using MacOS Sonoma (14.7). In Googling online it hints that Mac Security is such that loading SDL3 as a shared library is akin to trying to run a program from an unidentified developer, and can only be done by reducing my entire system’s security.

Does the SDL3 community have a “signed” version of their libraries? I know modern MacOS is tightening the screws to prevent sideloading in the future. It stores with the files info that it has been downloaded from the internet.

3

As an alternative, is it possible to create a static library for SDL3 and SDL3/Image? Has anyone done this for MacOS? (I’m guessing it should be allowable to link with a static library, but I’m not sure.)

4

Another update - I managed to use cmake and the source code to create a static library version of SDL3 - unfortunately, the .a file seems to be missing all the Apple libraries needed to actually work. I get a ton of link errors for core Apple library functions like CGContextDrawImage. So I am suspecting it’s only making the Linux version of the library?

BUT - The good news is I’ve confirmed I’m allowed to link it to my code this way, so I’m VERY INTERESTED if anyone has an idea as to how to make a MacOS static library version.

Thank you very much to the developers for their help on this.

5

So, a couple of things:

  1. What do you mean by dynamically loading the SDL libraries? Are you trying to load them yourself? You can absolutely, 100% use SDL3 as a shared library.

  2. How is your Xcode project set up to link to SDL?

  3. How is your Xcode project set up overall? It’s set up to build a Cocoa app, right?

  4. If you build SDL as a static library, the reason you’re (probably) getting linker errors is because now you have to link to the system frameworks SDL depends on, like CoreGraphics (which your app should have been automatically set up to link to by Xcode, assuming you set your project up as a Cocoa app).

  5. Any libraries you ship with your app have to be code signed the same as your app. It’s gonna be way easier if you set code signing to Automatic.

I took SDL3.framework straight out of the official latest release and it worked fine. Xcode automatically code signed it and put it in my app bundle, and the app runs fine.

6

Thank you so, so much for the assist, sjr. :slight_smile:

#1. I’m not explicitly loading the SDL3 library - it’s just part of my XCode project (see answers to question two). I could actually try loading them explicitly, but I suspect I’d run up against the same capabilities issue. Worth a shot, though. Currently, SDL is my only method of displaying anything on my Mac.

Initially, it was getting a runtime error saying it couldn’t find the SDL3 library - it was looking for a copy in its build directory. It appeared to just not be copying the SDL3 library into the build directory. So I hand copied it there - and the result was the error that it’s not allowed to load it. Which I am inferring is why it didn’t copy it in.

#2. I experimented a bit here. The normal route was I would just drag the framework into my XCode project. Here was one new difference - instead of dragging in the new ueber format for all Apple devices, I just dragged in the Mac specific framework - as this is how the project worked before. I also experimented with adding it in the link settings - which was the same - and even just dragging in only the library, but the effects were identical. Everything compiled fine, but it refused to load the library with that error message about policies.

#3. Maybe this is the issue? It’s set up to build a “command line tool”. I’m not sure how to set it up to build a Cocoa App. But command line tool worked previously. Could you give some details there? Remember, this is a Mac App.

#4. That makes a ton of sense! :slight_smile: My App is definitely not linking against CoreGraphics. Would it be feasible to list the required Apple libraries, or would the list be too long?

#5. I completely understand - in this case, I’m not planning on shipping this as a product. I just want to run it locally on my laptop. Which normally doesn’t require any signing, which is why this is all so odd. For this use case I check Automatically manage signing, Team None, Bundle Identifier blank, Provisioning file none required, Signing Certificate Sign to Run Locally. Do you think building the dynamic library locally would help here, since then at least it wouldn’t be flagged as “downloaded from the internet?”

I am so grateful for your advice, sjr. I’m open to any ideas you have. It sounds like one approach is to build as a Cocoa App - but I’m not sure how, because I don’t see that as an option for MacOS.

7

So by “Cocoa” app, I mean just create a regular Mac app (there used to be two different Mac app frameworks, Cocoa and Carbon, but these days only Cocoa remains, so Apple doesn’t label it “Cocoa” in recent Xcode versions).

You should set your code signing to Personal Team if you’re just making something to run on your own computer.

I have a write up of the method I use to create SDL2 apps in Xcode here. This also works for SDL3, just change SDL2.framework to SDL3.framework (and obviously the code will have to change if you’re trying to use the sample code)

Following this method you get:

  • A full-blown Mac app
  • Xcode automatically puts SDL3.framework in your app bundle and code signs it for you
  • Because you’re creating a full-blown Mac app, you’re already linking to the libraries SDL is expecting your app to link to (Cocoa, CoreGraphics, etc) should you want to statically link to SDL instead for some reason.
8

Thank you so very much, sjr. :slight_smile: :slight_smile: :slight_smile:
I’m going to give this a try and see how I do.

As I mentioned, I was using a command line App, but I never had this problem linking to SDL2 before upgrading to Sonoma - the same project that had worked failed. So I’m not completely sure what’s causing this issue.

And thank you so much for creating that github example - you do us all a great service. :slight_smile: