When building SDL_sound, we get the SDL libraries we link to from calling "sdl-config --libs" somwhere in the configure script.

On Mac OS X, where SDLmain exists, this gives us:

   -L/usr/local/lib -lSDLmain -lSDL -Wl,-framework,Cocoa

So SDL_sound, the dynamic library, links to SDLmain.

Apps using SDL_sound, such as the included playsound app, link against SDL_sound and SDL and SDLmain.

However, it appears that Mac OS X's dynamic loader is choosing the wrong copy of SDL_main, the end result being that we eventually get to playsound's actual main(), but we ended up writing to the wrong gArgc/gArgv, so we end up getting called with argc==0 and argv==NULL.

And to frustrate things more, gdb looks at the wrong set of symbols when setting breakpoints.  :)

I believe this is new behaviour in Tiger or gcc4...we've probably been linking against SDLmain inadvertently forever on Mac OS X, but the order symbols resolve is different now.

I wouldn't be surprised if SDL_mixer, etc has this same problem, and no one noticed because most people don't use command lines on the Mac and they might just skip cmdline processing when argc==0 in their for-loop. I only noticed because playsound assumes that argv[0] is always valid.

Basically, the solution is not to link libraries against SDLmain, just apps that have real mainlines, but there isn't a way to get this information from sdl-config. Would it be possible to add a --libs_no_sdlmain option to sdl-config?

--ryan.