SDL and osx library bundles

Hi all,

I’m currently trying to port a software project from linux to osx. Part
of of projects consists of a shared library which does SDL specific
stuff and which is going to be imported into python. So far I have
failed miserably to get this library to work on osx because of the
_NSAutoreleaseNoPool and NSInternalInconsistencyException issues which
have already been discussed in this mailing list. I’m more or less
aware of all the proposed solutions which apply to code which is going
to be compiled as application. In my situation, I don’t want to compile
an application but a coca shared library bundle. How do I deal with the
main function remapping in case of a library which will be imported
into python?

During a rather lengthy discussion in the ogre3D forum the following
potential solution has emerged so far:

  1. Recompile python interpreter with SDL_main.h included. This is
    inconvenient, to say the least.

  2. Call SDL’s main() (not SDL_main) manually. You could compile the
    SDL_main.m into a shared lib, with the main() function renamed to, for
    example, start_SDL. Then, before OGRE is initialized, call that
    start_SDL stub function to setup the environment as needed for SDL.
    You’ll have to get rid of the call to SDL_main from the start_SDL
    function, but you might have to replace it somehow.

Since these recommendations are a tad to hacky for my taste I wonder
whether anybody has a better solution to the very general problem of
getting python to like sdl on osx.

Thanks in advance!

I’m currently trying to port a software project from linux to osx.
Part of of projects consists of a shared library which does SDL
specific stuff and which is going to be imported into python. So far I
have failed miserably to get this library to work on osx because of
the _NSAutoreleaseNoPool and NSInternalInconsistencyException issues
which have already been discussed in this mailing list. I’m more or
less aware of all the proposed solutions which apply to code which is
going to be compiled as application. In my situation, I don’t want to
compile an application but a coca shared library bundle. How do I deal
with the main function remapping in case of a library which will be
imported into python?

For pygame, I require PyObjC (which every Python user on OS X should
really install anyway) and have some initialization code that makes
sure the NSApplication and such is setup correctly upon pygame.init().
See pygame CVS. To handle the case where the user wants to handle
their own menus or what have you with custom PyObjC/ObjC code, [the OS
X specific part of] the initialization code is essentially a no-op if
the NSApplication instance already exists (NSApp() will return
something other than None).

Let me know when you get something working, so I can add it to my
PackageManager database (and play with it myself, of course).

-bob
-------------- next part --------------
A non-text attachment was scrubbed…
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040607/e6483f02/attachment.binOn Jun 7, 2004, at 11:42 AM, Daniel Bisig wrote:

Hi,

I’m currently trying to port a software project from linux to osx.
Part of of projects consists of a shared library which does SDL
specific stuff and which is going to be imported into python. So far
I have failed miserably to get this library to work on osx because of
the _NSAutoreleaseNoPool and NSInternalInconsistencyException issues
which have already been discussed in this mailing list. I’m more or
less aware of all the proposed solutions which apply to code which is
going to be compiled as application. In my situation, I don’t want to
compile an application but a coca shared library bundle. How do I
deal with the main function remapping in case of a library which will
be imported into python?

For pygame, I require PyObjC (which every Python user on OS X should
really install anyway) and have some initialization code that makes
sure the NSApplication and such is setup correctly upon pygame.init().
See pygame CVS. To handle the case where the user wants to handle
their own menus or what have you with custom PyObjC/ObjC code, [the OS
X specific part of] the initialization code is essentially a no-op if
the NSApplication instance already exists (NSApp() will return
something other than None).

thanks very much for your reply.

We are not using pygame at all but rather employ swig in order to
create a wrapper for our classes.

regards

    Daniel

Hi,

I’m currently trying to port a software project from linux to osx.
Part of of projects consists of a shared library which does SDL
specific stuff and which is going to be imported into python. So far
I have failed miserably to get this library to work on osx because
of the _NSAutoreleaseNoPool and NSInternalInconsistencyException
issues which have already been discussed in this mailing list. I’m
more or less aware of all the proposed solutions which apply to code
which is going to be compiled as application. In my situation, I
don’t want to compile an application but a coca shared library
bundle. How do I deal with the main function remapping in case of a
library which will be imported into python?

For pygame, I require PyObjC (which every Python user on OS X should
really install anyway) and have some initialization code that makes
sure the NSApplication and such is setup correctly upon
pygame.init(). See pygame CVS. To handle the case where the user
wants to handle their own menus or what have you with custom
PyObjC/ObjC code, [the OS X specific part of] the initialization code
is essentially a no-op if the NSApplication instance already exists
(NSApp() will return something other than None).

thanks very much for your reply.

We are not using pygame at all but rather employ swig in order to
create a wrapper for our classes.

Yeah, I understand that. But you are using SDL, and the initialization
code in pygame that I am referring to is specific to making SDL happy
on OS X, not pygame.

The source code I’m talking about is in pygame, it’s not code that
uses pygame.

-bob

-------------- next part --------------
A non-text attachment was scrubbed…
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040607/f0d364b5/attachment.binOn Jun 7, 2004, at 2:02 PM, Daniel Bisig wrote:

Hi Bob,

We are not using pygame at all but rather employ swig in order to
create a wrapper for our classes.

Yeah, I understand that. But you are using SDL, and the
initialization code in pygame that I am referring to is specific to
making SDL happy on OS X, not pygame.

The source code I’m talking about is in pygame, it’s not code that
uses pygame.

I indeed managed to get our library to work after calling the
initialization code of pygame. I simply added the following two lines
to our startup.py file:

import pygame
pygame.init()

I don’t really understand how pygame manages to make SDL happy. I think
I will check the pygame mailing list concerning this topic.

Thank you very much for your advice!!

Best regards

  Daniel