2011/10/15 Brian Cameron <brian.cameron at oracle.com>: > > PulseAudio Team: > > 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. Indeed, exciting. > 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). In general: yes, we would like to have portability fixes submitted upstream. Thank you for collaborating. I'm looking forward to the first pulse release that works unpatched on solaris. Patches that you just want to submit for inclusion upstream (especially simple things like #4 below) can be just send to the mailing list directly. We generally prefer that to a bug report. I'll start a new thread for the first three. > 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 > > ? A proposed patch in this bug shows how we fix this problem on > ? Solaris. ?This changes the PulseAudio pkg-config files so that they > ? also specify that client needs to link against libpulsecommon and > ? libpulsecore, since these now contain symbols needed by client > ? programs. > > ? The responses to this bug suggest that this is not desirable since > ? these PulseAudio libraries may be updated in future versions and it > ? is not desirable to make programs relink on Linux when these > ? libraries change. > > ? Wouldn't a better solution be to just drop the version numbers from > ? these libraries, or to only update their version numbers when you > ? really want people to need to relink? ?Why embed version numbers in > ? library names when you want them to work across multiple versions? > > 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. > > 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. > > 4) Some straightforward compile issues that seem appropriate to fix for > ? building on Solaris is in the patch in this bug: > > ? https://bugs.freedesktop.org/show_bug.cgi?id=41538 This one looks good, see also my comment attached to the patch. Maarten
