On Sun, Jul 19, 2009 at 12:13:05PM +0100, Colin Guthrie wrote: > 'Twas brillig, and Daniel Mack at 18/07/09 13:05 did gyre and gimble: >> I've put some pieces together now and what I got is >> >> - a kernel module that loads and unloads fine and offers a virtual >> stereo soundcard which can be selected by any CoreAudio application. >> - a user space interface to share the ring buffers with application so >> that audio can be transported in and out. >> - a skeleton for an >> application that connects to that interface and maps the shared memory >> buffers. >> - a PreferencePane which has no function yet but can be used later to >> control setting for the virtual audio device and the local sound server. >> >> Sounds like a lot, but there's still a long way to go until we'll hear >> anything. > > That's still a million times further on than last week! Awesome work :D For those interested, I've put my tree online: http://github.com/zonque/PulseAudioOSX/tree/master >> So it seams that libglib2 is missing in the linker list. Haven't >> debugged any further, hoping that someone has a solution already :) > > Hmmm. This is some sort of over/under linking issue I think. The place > where this is defined is based on a weak reference, which means that if > it doesn't exist, it should allow the app to continue. > > I suspect that the clue to fixing this would be in the PA_GCC_WEAKREF > macro. I suspect this is simply not working on OSX. Ah, so you're saying PA doesn't need glib2 at all? > It's probably quite a trivial patch in src/pulsecore/proplist-util.c > > It checks for and defines _g_get_application_name, but if the > PA_GCC_WEAKREF macro is not defined we don't do anything... I'd imagine > a simple #else and a dummy implementation of _g_get_application_name() > that returns NULL. > > Now interestingly, pulse does check for it via "if > (_g_get_application_name)" so it should handle this already... Hmmm. I > guess the dynamic linker isn't loading the library needed for the > weakref for you. I'm not really sure now I've gone through this :s > > Check first if the PA_GCC_WEAKREF macro is defined and tyr and get some > more info and follow it through is my recommendation for now. > > Whatever you do, you may have to do the same for > _gtk_window_get_default_icon_name and _gdk_display... Hmm. Maybe someone can come up with a patch :) Thanks, Daniel