On Sat, 15.10.11 16:29, Brian Cameron (brian.cameron at oracle.com) wrote: Heya, > The decision was made recently to integrate PulseAudio into Solaris, so > that is pretty exciting. I am not exactly sure when it will integrate. > At the moment, I am just working to get it building and working okay. > > I have encountered a few build issues, and I am wondering if PulseAudio > could be updated to make it more portable and to build more easily on > Solaris. There are only about 3 changes that need to be made (issue #2 > below is a more general issue). On which backend? OSS? Note that OSS support in PA never came close in any way to what the ALSA backend provides. > > 1) The Solaris linker does not allow lazy linking, so client programs > must link against all libraries that contain symbols used by the > program. So I filed this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=41539 This sounds wrong. clients should never link to libpulsecore as that library is not API stable. Note that all of PA is LGPL. Only if you link against libsamplerate it effectively becomes GPL (due to the famous viral nature of GPL). But since libsamplerate is option this is generally not a problem. > 2) Bug #41822 highlights that there may be licensing issues with > PulseAudio. It says anything that links against libpulsecore is > GPL'ed. Now that libpulsecommon and libpulse and the GStreamer Pulse > plugin now link against libpulsecore, this raises concern that any > program linking against PulseAudio is GPL, such as anything using > the GStreamer PulseAudio plugin. Now that the speex resampler is > available, maybe it is time to drop libsamplerate as a dependency? > > https://bugs.freedesktop.org/show_bug.cgi?id=41822 > > At any rate, on Solaris, we are disabling building with libsamplerate > for this reason. It seems a bit ugly that libsamplerate is enabled > by default by the PulseAudio configure script if it is available if > there are these sorts of concerns. Just out of curiosity, why does Solaris care about having no GPL in the PA process? (And yupp, here too this sounds like a bug if clients ever end up linking against libpulsecore. That library is not API stable, and things will end in desaster if this happens). > 3) On Solaris, the PulseAudio GConf module does not compile since the > "module_info" structure defined in the PulseAudio code conflicts > with a structure with the same name in /usr/include/sys/stream.h. > Could the PulseAudio code be updated to use a more unique PulseAudio > specific name as suggested in the patch in this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=41823 > > Note that sys/stream.h is included by sys/types.h on Solaris, and > sys/types.h is included in the src/modules/gconf/modules-gconf.c > PulseAudio file. The GConf code probably should go away anyway, and be replaced by dconf/gsettings. Lennart -- Lennart Poettering - Red Hat, Inc.
