Re: [gtk-osx-users] Error: jhbuild build fails to parse gtk-osx.modules




On Mar 4, 2013, at 1:29 PM, Nick M <nmgeneric gmail com> wrote:

Hello,

When I run

$ jhbuild build meta-gtk-osk-bootstrap

I get the following error:

jhbuild build: failed to parse http://git.gnome.org/browse/gtk-osx/plain/modulesets-stable/gtk-osx.modules: not well-formed (invalid token): line 57, column 6

I am running OSX 10.6.8.

I have tried some sleuthing on my own but as far as I can tell the gtk-osx.modules document is well-formed. I am not very familiar with how jhbuild or GTK work (I am just trying to follow these instructions, as a means to an end).

For a bit of background, incase it is relevant, I am trying to get a simulator program for my robotics course to run on my Mac. It uses this Python module, which requires GTK Python libraries. I have libraries installed already but when I run the module's test script I get errors that look like this:
... __NSAutoreleaseNoPool(): Object 0x1026669e0 of class NSCalibratedWhiteColor autoreleased with no pool in place - just leaking
... attempt to pop an unknown autorelease pool (0x100a07a00)
and the program stops responding (with a blank window open). These are apparently Cocoa errors to do with threading but I have yet to find out much more than that. My assumption has been that my GTK libraries were bad. But I have never worked with GTK, Cocoa, or even Python before yesterday so I am not sure if I am on the right track.

Any help to get me moving again would be greatly appreciated.

Please subscribe to the list.

Jhbuild isn't very good at reporting errors. The actual problem was in gtk-osx-random.modules. It's fixed now, thanks for the report.
It appears from a cursory look that the threading is AFU. One doesn't wrap the gtk_main() call in gtk_threads_enter()/gtk_threads_leave(). That accomplishes nothing. One uses threads_enter()/threads_leave() in callbacks
(except callbacks for gtk signals, which have already done that).

There's also a compatibility bust baked in: While it's OK to run the eventloop on a secondary thread in Linux, it's not anywhere
else. In Quartz only the primary thread is able to receive events, which is probably why it locks up on you.

The autorelease issues are probably also caused by the g_main_loop running in the wrong thread. The autoreleasepools are
set up by Gdk, but they don't cross thread boundaries so Quartz can't use them. Hence the leaks. This is going to take some work
from someone who understands threading and memory management at a fairly deep level, and will require some changes to the module. You'll need to work with the project's developers on that.

Regards,
John Ralls




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]