[pulseaudio-discuss] PulseAudio support on Solaris

[Brian Cameron]

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>