Simple window no longer appears

SDL Development
1

This minimal SDL2 test program used to run correctly, displaying a yellow window. Now it runs, waiting the requisite 10 seconds, and then terminates. But the window doesn’t actually appear. SDL2.Framework in /Library is dated March 1, 2025.

I’m just wondering – what sort of breakage would prevent the window from appearing? (It makes no difference if I put actual numbers instead of SDL_WINDOWPOS_UNDEFINED.)

Building on Mac OS 14.2.1, clang 15.

#include <SDL2/SDL.h>

int main(int argc, char *argv[])
{
    SDL_Init(SDL_INIT_VIDEO);

    SDL_Window *window = SDL_CreateWindow(
            “SDL2Test”,
            SDL_WINDOWPOS_UNDEFINED,
            SDL_WINDOWPOS_UNDEFINED,
            640,  480,
            0
    );

    SDL_Renderer *renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_SOFTWARE);
    SDL_SetRenderDrawColor(renderer, 255, 255, 0, SDL_ALPHA_OPAQUE);
    SDL_RenderClear(renderer);
    SDL_RenderPresent(renderer);

    SDL_Delay(10000);
    SDL_DestroyWindow(window);
    SDL_Quit();

    return 0;
}

The following messages appear in the console. They look like they might be relevant. Normally the window goes to my large external monitor, but if I unplug it and try again nothing much changes except that it says display 1 instead of display 5.

Launching: '/Users/ken/prog24/Drawbox/TestCase/build/TestProgram'
Working directory: '/Users/ken/prog24/Drawbox/TestCase'
1 arguments:
argv[0] = '/Users/ken/prog24/Drawbox/TestCase/build/TestProgram'
2025-07-03 14:32:27.677658-0400 TestProgram[28836:1232226] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=28836
2025-07-03 14:32:27.678179-0400 TestProgram[28836:1232226] SecTaskCopyDebugDescription: TestProgram[28836]/0#-1 LF=0
2025-07-03 14:32:29.230861-0400 TestProgram[28836:1232226] [] CurrentVBLDelta returned 400000 for display 5 -- ignoring unreasonable value
2025-07-03 14:32:29.230896-0400 TestProgram[28836:1232226] [] [0x7fcae8808220] Bad CurrentVBLDelta for display 5 is zero. defaulting to 60Hz.
2025-07-03 14:32:29.621851-0400 TestProgram[28836:1232226] Errors found! Invalidating cache...
Process exited with status 0
logout

Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]

I’m suspicious of my build, although that may not be relevant. So here is CMakeLists.txt:

cmake_minimum_required(VERSION 3.28)
set(CMAKE_OSX_ARCHITECTURES "x86_64" CACHE STRING "” FORCE)
set(CMAKE_FIND_FRAMEWORK ONLY)

project(my-project)

set (TEST MinimalSDLtest.cpp)

set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/“)
find_package(SDL2 REQUIRED COMPONENTS SDL2)  # recommended in Readme

message( STATUS SDL2_INCLUDE_DIRS=${SDL2_INCLUDE_DIRS} )
message( STATUS SDL2_LIBRARIES=${SDL2_LIBRARIES} )

include_directories(${SDL2_INCLUDE_DIRS} .)
link_directories(${SDL2_LIBRARY_DIRS})

add_executable(TestProgram ${TEST}) 

target_compile_options(TestProgram PRIVATE 
        -Wno-switch -Wno-deprecated-declarations -Wno-writable-strings)

target_link_libraries(TestProgram ${SDL2_LIBRARIES})

Here’s the output from the CMake configure:

[main] Configuring project: TestCase

[proc] Executing command: /opt/homebrew/bin/cmake -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/clang -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/clang++ -Wno-dev --no-warn-unused-cli -S/Users/ken/prog24/Drawbox/TestCase -B/Users/ken/prog24/Drawbox/TestCase/build -G "Unix Makefiles”

[cmake] Not searching for unused variables given on the command line.

[cmake] -- SDL2_INCLUDE_DIRS=/Library/Frameworks/SDL2.framework/Headers/Library/Frameworks/SDL2.framework

[cmake] -- SDL2_LIBRARIES=SDL2::SDL2

[cmake] -- Configuring done (0.0s)

[cmake] -- Generating done (0.0s)

[cmake] -- Build files have been written to: /Users/ken/prog24/Drawbox/TestCase/build
2

are you sure renderer isn’t NULL?

3

Debugging shows that it is not NULL.

4

Incidentally, I tried building under SDL3 (with slight changes to the call syntax for SDL_CreateWindow) and there is still no window.

5

Try with calling SDL_SyncWindow before SDL_Delay. Or simply implement a basic event processing loop to give the window a chance to actually show on the screen.

1 Like
6

You need to process events for the window to appear.

Add this after you create the renderer, but before you clear it:

SDL_Event event;
while(SDL_PollEvent(&event)) {
}

Also you really don’t want to install the SDL framework into a system location.

2 Likes
7

What??? Why do you say that? All advice I have seen anywhere says that /Library/Frameworks is the right place. For example:

8

SDL_PollEvent worked. Perfectly sensible. I just wonder why this code ever worked without it!

SyncWindow as an alternative also works.

9

How do you handle version conflicts?

How do you ship your application to users?

It’s better to put the SDL framework in your app bundle (which is kinda the whole point of app bundles: they contain all the non-system resources, frameworks, etc., your app needs). Basically, follow the instructions here but replace SDL2.framework with SDL3.framework

edit: I don’t know it offhand, but there’s an option to tell CMake to tell Xcode to add SDL3.framework to your app bundle and link against that when CMake generates the Xcode project file. You’ll still want SDL3.framework to be somewhere in your project directory rather than /Library/Frameworks or ~/Library/Frameworks.

edit 2: the link you provided has you basically do the same thing as the one I posted when it comes to adding SDL2.framework to your Xcode project and having Xcode embed it in your app bundle, but has Xcode copy it from /Library/Frameworks and then set the runtime linker to look for it there instead of in your app bundle, which is bonkers.

The part where it tells you to have CMake link to the libraries etc inside the framework instead of just linking to the framework is also… not the way I’d recommend.

10

Of course, but I still install the SDL framework in /Library/Frameworks and use it there for testing etc. It’s only when I come to build a distributable app that I copy the framework into the bundle and use install_name_tool to point to that. Is that not the recommended way to do it?

11

I put SDL3.framework (or SDL2) somewhere in my project folder and then set up the Xcode project to embed and sign that framework.

Since Xcode does it when the app is built, I’m testing with the framework in the bundle that will ship to users.

12

I don’t (explicitly) use Xcode - it’s a command-line build using a makefile. In that environment creating and signing an app bundle is quite slow, so I wouldn’t want to do it on each iteration during testing.

I do of course test the final bundle before shipping, but not routinely during development. If there’s a potential problem with that approach I haven’t noticed it.

13

There’s always xcodebuild if you want to compile an Xcode project from the command line.

14

Yes, I know, but it’s a cross-platform product and I use a virtually identical makefile in Windows, Linux, MacOS and Emscripten - even to the extent that in MacOS the compiler is invoked with gcc even though I know that’s not really what is being used!

Of course I don’t have to do that (and I can’t in Android or iOS - I wish I could!), but it seems the most elegant and straightforward solution and it works well.