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
