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
