Lennart: >> 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. > > On which backend? OSS? Note that OSS support in PA never came close in > any way to what the ALSA backend provides. Yes, on Solaris we use the OSS backend. Yes, I know that PA with OSS does not support all the features it supports with ALSA (e.g. glitch free features). This was one reason why adoption of PA on Solaris has been slow. The value-add that tipped things over the edge was the fact that the Sun Ray team discovered that PA makes audio work a lot better for Sun Ray setups and they requested that PA be added to Solaris. >> 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. I found this issue when I try to build PA clients. For example, when PulseAudio tries to build pactl, I see these errors. I see similar errors trying to build any PA client: Undefined first referenced symbol in file pa_object_unref /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so pa_sink_input_type_id /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so pa_object_type_id /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so pa_msgobject_type_id /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so pa_source_output_type_id /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so pa_object_ref /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so pa_sink_type_id /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so pa_source_type_id /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so pa_core_type_id /home/brianca/packages/BUILD/SUNWpulseaudio-1.0/amd64/pulseaudio-1.0/src/.libs/libpulsecommon-1.0.so ld: fatal: symbol referencing errors. No output written to .libs/pacat I found that using the attached patch which causes PA clients to link against libpulsecore fixes this problem. Now that I am looking at this more closely, I suspect the problem is that PA clients are including header files that define functions that are not included in the clients. Since the Solaris linker does not support lazy linking and requires all symbols to be resolved at link time, this causes a problem. Perhaps this is not an issue on Linux because these functions are unused by clients and the linker does not care if the symbols are not resolved? At any rate, if people have any suggestions about how the code could be modified to avoid this problem, then that would be much appreciated. > 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. It seems that there is also a bug in PA with clients linking against libsamplerate that Arun Raghavan noticed yesterday and fixed. So, it seems this was an issue as well. > Just out of curiosity, why does Solaris care about having no GPL in the > PA process? If libsamplerate is only used in the PA server, then this is no real problem. However, after building PA and various PA clients (such as the GStreamer PulseAudio backend), I was finding that clients needed to link against libpulsecore and libsamplerate. It is undesirable to make all PA clients GPL obviously. > (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). Now that I am looking at this more closely, I suspect that my attached patch to address the above linking issue is wrong, and I need to find a better way to get clients to link properly without linking in libpulsecore. > The GConf code probably should go away anyway, and be replaced by dconf/gsettings. This is regarding bug #41823. Sure, but in the meantime, it would be nice if this minor issue could be fixed. Simply renaming the GConf module_info variable to something less generic should do it. Brian -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pulseaudio-02-solaris.diff URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111017/8e2a8030/attachment.ksh>
