Help initialising OSX SnowL

SDL Development
1

Hi, I’m running recent tarball of SDL 1.3 on Snow Leopard and having a few problems.

(1) The worst is probably not SDL’s fault (probably Apple screw up): dynamic library
trying to run SDL, stuff more or less works, printf() works, but C++ stream I/O
has all sorts of fun, strings output, integers don’t, sometime the output only happens
once then dies. Seems like something to do with static init. Note: I do this all the
time with C++ built libraries, no problem. Note model:

fixed-driver-exe --dlopen–> user.dylib — autoload–> support.dylib

(2) Maybe related to next problem: I am not initialising cocoa pool thing.
Many video ops don’t work right, eg full screen shows black.
Resize shows expanded simple objects but textures all gone.

I can’t find SDL_main.m in the tarball. I can NOT “rename” main and
I can NOT support SDL calling my code. All calls have to be to SDL.

I can: (1) hack in some initialisation code into the the top level driver,
but it would be better if it we just a routine to call from the user
application. Why not SDL_init??

So what’s the right way to initialise SDL on SnowLeopard?
[Anyone like to suggest just going to X11?? :]–
john skaller
@john_skaller

2

a friend of mine ‘upgraded’ to snow leppard and then spent a week messing
about then spent 50 grand changing his workstations to windows, go apple

3

sorry this is probably not the droids you were looking for :wink: it’s 0430 uk
time and i have more JD to drink.

4

a friend of mine ‘upgraded’ to snow leppard and then spent a week messing about then spent 50 grand changing his workstations to windows, go apple

Lol.On 09/02/2011, at 3:24 PM, Neil White wrote:

john skaller
@john_skaller

5

sorry this is probably not the droids you were looking for :wink: it’s 0430 uk time and i have more JD to drink.

Email me some of that JD … :)On 09/02/2011, at 3:26 PM, Neil White wrote:

–
john skaller
@john_skaller

6

Hi, I’m running recent tarball of SDL 1.3 on Snow Leopard and having a few problems.

(2) Maybe related to next problem: I am not initialising cocoa pool thing.
Many video ops don’t work right, eg full screen shows black.
Resize shows expanded simple objects but textures all gone.

Well StackOverflow was more help … apparently this is a known bug.

On resizing, sometimes it works and sometimes segfaults.

When relaunching (without console) it works more often, and the
display resizes correctly (but not to full screen), but still segfaults
occasionally.

most of the code is using the compatibility layer (haven’t upgraded
to multiple window support, that’s the main reason I want to use 1.3 though)

[Sorry for confused messages but I actually have 6 demo apps and they all
exhibit different faults :]

I get this on console on exit after full screen in one app:

2011-02-10 02:01:18.331 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x1004825d0 of class NSCFArray autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.335 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x10180d3c0 of class NSCFNumber autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.335 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x101821790 of class NSConcreteValue autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.343 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x101808730 of class NSCFNumber autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.343 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x100486170 of class NSConcreteValue autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.344 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x1004483b0 of class NSCFDictionary autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.353 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x100411ea0 of class NSCFNumber autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.354 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x1004862d0 of class NSTrackingArea autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.356 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x100486410 of class NSCFNumber autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.357 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x100443e00 of class NSConcreteValue autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.357 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x101808730 of class NSCFNumber autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.357 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x10044e0c0 of class NSConcreteValue autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.358 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x10041cee0 of class NSCFDictionary autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.359 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x100486cd0 of class NSConcreteMutableData autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.360 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x7fff7022a518 of class NSCFString autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.360 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x7fff7022a518 of class NSCFString autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.362 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x100452100 of class NSConcreteMutableData autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.363 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x10180b430 of class NSConcreteMutableData autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.363 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x10185ca30 of class NSConcreteMutableData autoreleased with no pool in place - just leaking
2011-02-10 02:01:18.364 sdl-1.01.06-0[517:903] *** __NSAutoreleaseNoPool(): Object 0x101815030 of class NSConcreteMutableData autoreleased with no pool in place - just leaking
86 frames in 5.022 seconds = 17.1247 FPSOn 09/02/2011, at 2:24 PM, john skaller wrote:

–
john skaller
@john_skaller

7

[]

This template:

template
string str(T const &t) {
std::ostringstream x;
x << t;
return x.str();
}

works fine with both static and dynamic linkage of many applications and libraries,
including SDL 1.3 linked statically, but fails when SDL is linked dynamically to
a manually loaded dylib.On 10/02/2011, at 2:05 AM, john skaller wrote:

–
john skaller
@john_skaller

8

std::ostringstream x;

works fine with both static and dynamic linkage of many applications and
libraries,
including SDL 1.3 linked statically, but fails when SDL is linked
dynamically to
a manually loaded dylib.

My opinion is that you are linking different version of runtime (libSystem,
libz…) in SDL and your application (in osx this is a big problem since
every release they change a lot).

This will cause problems for sure (a typical problem is to free() a region
of memory that has been allocated by a shared library or to pass a not POD
object like an std::string through the “gate” library <-> application).

Try to inspect with “otool -L” the dependencies of every actor (app, dylib
and SDL).–
Bye,
Gabry

9

There is this, I suppose:
http://www.sandroid.org/imcross

http://www.sandroid.org/imcrossI’ve never tried it. Be warned. You’ll
probably need some way to test the binaries.
Jonny D

10

Oops, wrong thread…On Thu, Feb 10, 2011 at 6:24 AM, Jonathan Dearborn <@Jonathan_Dearborn>wrote:

There is this, I suppose:
http://www.sandroid.org/imcross

http://www.sandroid.org/imcrossI’ve never tried it. Be warned. You’ll
probably need some way to test the binaries.
Jonny D

11

std::ostringstream x;

works fine with both static and dynamic linkage of many applications and libraries,
including SDL 1.3 linked statically, but fails when SDL is linked dynamically to
a manually loaded dylib.

My opinion is that you are linking different version of runtime (libSystem, libz…) in SDL and your application (in osx this is a big problem since every release they change a lot).

That makes sense, but how is this possible?

ARGGG…

/Library/Frameworks/SDL.framework

/usr/local/lib/libSDL-1.3.0.dylib

Two copies of SDL. I thought i got rid of them (there were more, lol!)

Question is … if I delete the /Library one … will Starcraft still work??
[Only game I have that actually runs on the Mac … ]On 10/02/2011, at 9:42 PM, Gabriele Greco wrote:

–
john skaller
@john_skaller

12

std::ostringstream x;

works fine with both static and dynamic linkage of many applications and libraries,
including SDL 1.3 linked statically, but fails when SDL is linked dynamically to
a manually loaded dylib.

My opinion is that you are linking different version of runtime (libSystem, libz…) in SDL and your application (in osx this is a big problem since every release they change a lot).

This will cause problems for sure (a typical problem is to free() a region of memory that has been allocated by a shared library or to pass a not POD object like an std::string through the “gate” library <-> application).

Try to inspect with “otool -L” the dependencies of every actor (app, dylib and SDL).

~/felix>otool -L demos/sdl/sdl-1.01.03-0.dylib
demos/sdl/sdl-1.01.03-0.dylib:
demos/sdl/sdl-1.01.03-0.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libdemux_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libflx_pthread_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libflx_gc_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libjudy_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libfaio_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libSDL-1.3.0.dylib (compatibility version 1.0.0, current version 1.0.0)
build/release/lib/rtl/libflx_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libflx_exceptions_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.15.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)
~/felix>otool -L /usr/local/lib/libSDL-1.3.0.dylib
/usr/local/lib/libSDL-1.3.0.dylib:
/usr/local/lib/libSDL-1.3.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ForceFeedback.framework/Versions/A/ForceFeedback (compatibility version 1.0.0, current version 1.0.2)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 44.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.19.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.21.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1038.29.0)
build/release/bin/flx_arun:
build/release/lib/rtl/libflx_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libflx_gc_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libflx_pthread_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libflx_exceptions_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libjudy_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libflx_async_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libdemux_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libfaio_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)

flx_arun is the mainline. Note it does NOT use any SDL_main.* stuff. In 1.3 there doesn’t seem to
be anything specific to do.

The only difference here between SDL an some other libs we use is that SDL
contains Objective-C code. That at least causes some problems with NSPool things
(leaks due to not registering stiff in an autorelease pool ?)

In 1.2 we HAD to have some startup code in the mainline.On 10/02/2011, at 9:42 PM, Gabriele Greco wrote:

–
john skaller
@john_skaller