[pulseaudio-discuss] PulseAudio support on Solaris

[Brian Cameron]

Maarten:

Thanks for the pointers, you helped me figure out how to get PulseAudio
building on Solaris without libpulsecommon needing to link against
libpulsecore.

The issue seems to be caused by the fact that libpulsecommon includes
pulsecore/pstream.c, which includes pulsecore/core-scache.h to gain 
access to the PA_SCACHE_ENTRY_SIZE_MAX #define.

Moving this #define so it is in pulsecore/memchunk.h (a header already 
associated with libpulsecommon and also included by pulsecore/scache.h) 
and fixing pstream.c to include memchunk.h fixes this issue.

I am not sure if this is the best way to fix this issue.  If the 
PulseAudio maintainers want to rearrange the header files in some other 
way to avoid the libpulsecommon pstream.c file needing to include 
pulsecore/core-scache.h, that is obviously okay.

I also notice that src/Makefile needs to be updated so connect_stress 
links with libpulsecore, so this is also fixed in this patch.

This patch is pretty simple, and it makes PulseAudio link properly on 
Solaris so libpulsecore does not need to be linked into libpulsecommon. 
  Can this go upstream?

I updated the bug with the patch and the above comment:

   https://bugs.freedesktop.org/show_bug.cgi?id=41539

Brian

On 10/19/11 07:18 AM, Maarten Bosmans wrote:
> 2011/10/17 Brian Cameron<brian.cameron at oracle.com>:
>> 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.
>
> I think I found the source of the problem.
> Some source files from libpulse or libpulsecommon include header files
> from libpulsecore.
>
> pulse/volume.c ->  pulsecore/sample-util.h
> pulse/channelmap.c ->  pulsecore/sample-util.h
> pulsecore/core-util.c ->  pulsecore/cpu-x86.h
> pulsecore/pstream.c ->  pulsecore/core-scache.h
>
> This is not how it supposed to be, but as they only use macros from
> those headers and no typedefs, functions, etc. it is sorta OK.
> Apparantly somehow Solaris gets upset by this and Linux does not.
>
> Brian, can you verify my assumption by compiling pulseaudio without
> your patches, but with the mentioned includes disabled? (and the
> necessary #defines copied from the header files to the source files)
>
> Maarten
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pulseaudio-04-fixlink.diff
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111019/c8896654/attachment-0001.asc>