Subject: OpenGL context sharing


I got a question to a rather weird problem I came across. We are developing an entire software suite in a set of shared libraries which are linked together with some type of Bootloader to an application. One library contains stuff related to IO, one contains rendering stuff and so on. I have to note here that this works well on Linux and Windows, and now I've tried to port that to OSX. I've tried to do achieve the same behaviour as on Linux and on Windows as follows:

In the IO library I created an interface for opening a nib file called WinControl which contains the outlets. The nib file itself only contains a NSOpenGLView which is embedded in an NSWindow. In principle this works quite well if I set the File Owner of the nib file to be of the class WinControl and do something like

/* snip */
WinControl * control = [[WinControl alloc] init];
[NSBundle loadNibNamed:@"MyNibFile" owner:control];
/* snip */

Note that this loading-of-nibs stuff is all contained in library A, and it seems that all drawing code also contained in library A works as expected.

Now, in our case library B contains the real important rendering stuff, also including code to compile shaders. The real problem I have here is:

If I create an application linking to A and B, the code in library B is not able to make use of the OpenGL context which is obviously created through library A (simply by loading a nib file with an embedded NSOpenGLView). After trying a lot of different things I'm pretty sure that this has to do with the question of "owning" the context. If I call drawing code contained in A from a function contained in B everything works, but if I include the drawing code directly in B it does not work (crashing with EXC_BAD_ACCESS).

Does someone have an idea what I can do about that? I'm a more-or-less beginner in Cocoa programming, and I'd really appreciate if someone could explain to me how to circumvent this problem...

without changing the overall structure of the software suite (i.e. the modularization into separate libraries for different tasks).



Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)

Help/Unsubscribe/Update your Subscription:

This email sent to maillists@xxxxxxxxx