[pulseaudio-discuss] PulseAudio support on Solaris
Maarten Bosmans
mkbosmans at gmail.com
Wed Oct 19 12:02:29 PDT 2011
2011/10/19 Brian Cameron <brian.cameron at oracle.com>:
> 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.
Thanks for trying this workaround and confirming that this is indeed
the problem.
(core-cache.h includes core.h, sink.h and others, which define objects
using PA_DECLARE_PUBLIC_CLASS, that cause trouble when not linked in.
I'm wondering why this is no problem on Linux)
> 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.
Did you check that other users of PA_SCACHE_ENTRY_SIZE_MAX can find
the macro in the new location?
The problem with the workaround is obviously that something about the
scache does not belong in memchunk.h conceptually.
> 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 needs to go in a separate 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:
In general, either the ML or bugzilla is fine.
Maarten
More information about the pulseaudio-discuss
mailing list