PulseAudio support on Solaris

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux