[pulseaudio-discuss] PulseAudio support on Solaris
PulseAudio Team: The decision was made recently to integrate PulseAudio into Solaris, so that is pretty exciting. I am not exactly sure when it will integrate. At the moment, I am just working to get it building and working okay. I have encountered a few build issues, and I am wondering if PulseAudio could be updated to make it more portable and to build more easily on Solaris. There are only about 3 changes that need to be made (issue #2 below is a more general issue). 1) The Solaris linker does not allow lazy linking, so client programs must link against all libraries that contain symbols used by the program. So I filed this bug: https://bugs.freedesktop.org/show_bug.cgi?id=41539 A proposed patch in this bug shows how we fix this problem on Solaris. This changes the PulseAudio pkg-config files so that they also specify that client needs to link against libpulsecommon and libpulsecore, since these now contain symbols needed by client programs. The responses to this bug suggest that this is not desirable since these PulseAudio libraries may be updated in future versions and it is not desirable to make programs relink on Linux when these libraries change. Wouldn't a better solution be to just drop the version numbers from these libraries, or to only update their version numbers when you really want people to need to relink? Why embed version numbers in library names when you want them to work across multiple versions? 2) Bug #41822 highlights that there may be licensing issues with PulseAudio. It says anything that links against libpulsecore is GPL'ed. Now that libpulsecommon and libpulse and the GStreamer Pulse plugin now link against libpulsecore, this raises concern that any program linking against PulseAudio is GPL, such as anything using the GStreamer PulseAudio plugin. Now that the speex resampler is available, maybe it is time to drop libsamplerate as a dependency? https://bugs.freedesktop.org/show_bug.cgi?id=41822 At any rate, on Solaris, we are disabling building with libsamplerate for this reason. It seems a bit ugly that libsamplerate is enabled by default by the PulseAudio configure script if it is available if there are these sorts of concerns. 3) On Solaris, the PulseAudio GConf module does not compile since the "module_info" structure defined in the PulseAudio code conflicts with a structure with the same name in /usr/include/sys/stream.h. Could the PulseAudio code be updated to use a more unique PulseAudio specific name as suggested in the patch in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=41823 Note that sys/stream.h is included by sys/types.h on Solaris, and sys/types.h is included in the src/modules/gconf/modules-gconf.c PulseAudio file. 4) Some straightforward compile issues that seem appropriate to fix for building on Solaris is in the patch in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=41538 Thanks, Brian ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
2011/10/15 Brian Cameron : > > PulseAudio Team: > > The decision was made recently to integrate PulseAudio into Solaris, so > that is pretty exciting. I am not exactly sure when it will integrate. > At the moment, I am just working to get it building and working okay. Indeed, exciting. > I have encountered a few build issues, and I am wondering if PulseAudio > could be updated to make it more portable and to build more easily on > Solaris. There are only about 3 changes that need to be made (issue #2 > below is a more general issue). In general: yes, we would like to have portability fixes submitted upstream. Thank you for collaborating. I'm looking forward to the first pulse release that works unpatched on solaris. Patches that you just want to submit for inclusion upstream (especially simple things like #4 below) can be just send to the mailing list directly. We generally prefer that to a bug report. I'll start a new thread for the first three. > 1) The Solaris linker does not allow lazy linking, so client programs > must link against all libraries that contain symbols used by the > program. So I filed this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=41539 > > A proposed patch in this bug shows how we fix this problem on > Solaris. This changes the PulseAudio pkg-config files so that they > also specify that client needs to link against libpulsecommon and > libpulsecore, since these now contain symbols needed by client > programs. > > The responses to this bug suggest that this is not desirable since > these PulseAudio libraries may be updated in future versions and it > is not desirable to make programs relink on Linux when these > libraries change. > > Wouldn't a better solution be to just drop the version numbers from > these libraries, or to only update their version numbers when you > really want people to need to relink? Why embed version numbers in > library names when you want them to work across multiple versions? > > 2) Bug #41822 highlights that there may be licensing issues with > PulseAudio. It says anything that links against libpulsecore is > GPL'ed. Now that libpulsecommon and libpulse and the GStreamer Pulse > plugin now link against libpulsecore, this raises concern that any > program linking against PulseAudio is GPL, such as anything using > the GStreamer PulseAudio plugin. Now that the speex resampler is > available, maybe it is time to drop libsamplerate as a dependency? > > https://bugs.freedesktop.org/show_bug.cgi?id=41822 > > At any rate, on Solaris, we are disabling building with libsamplerate > for this reason. It seems a bit ugly that libsamplerate is enabled > by default by the PulseAudio configure script if it is available if > there are these sorts of concerns. > > 3) On Solaris, the PulseAudio GConf module does not compile since the > "module_info" structure defined in the PulseAudio code conflicts > with a structure with the same name in /usr/include/sys/stream.h. > Could the PulseAudio code be updated to use a more unique PulseAudio > specific name as suggested in the patch in this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=41823 > > Note that sys/stream.h is included by sys/types.h on Solaris, and > sys/types.h is included in the src/modules/gconf/modules-gconf.c > PulseAudio file. > > 4) Some straightforward compile issues that seem appropriate to fix for > building on Solaris is in the patch in this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=41538 This one looks good, see also my comment attached to the patch. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
On Sat, 15.10.11 16:29, Brian Cameron (brian.came...@oracle.com) wrote: Heya, > The decision was made recently to integrate PulseAudio into Solaris, so > that is pretty exciting. I am not exactly sure when it will integrate. > At the moment, I am just working to get it building and working okay. > > I have encountered a few build issues, and I am wondering if PulseAudio > could be updated to make it more portable and to build more easily on > Solaris. There are only about 3 changes that need to be made (issue #2 > below is a more general issue). On which backend? OSS? Note that OSS support in PA never came close in any way to what the ALSA backend provides. > > 1) The Solaris linker does not allow lazy linking, so client programs >must link against all libraries that contain symbols used by the >program. So I filed this bug: > >https://bugs.freedesktop.org/show_bug.cgi?id=41539 This sounds wrong. clients should never link to libpulsecore as that library is not API stable. Note that all of PA is LGPL. Only if you link against libsamplerate it effectively becomes GPL (due to the famous viral nature of GPL). But since libsamplerate is option this is generally not a problem. > 2) Bug #41822 highlights that there may be licensing issues with >PulseAudio. It says anything that links against libpulsecore is >GPL'ed. Now that libpulsecommon and libpulse and the GStreamer Pulse >plugin now link against libpulsecore, this raises concern that any >program linking against PulseAudio is GPL, such as anything using >the GStreamer PulseAudio plugin. Now that the speex resampler is >available, maybe it is time to drop libsamplerate as a dependency? > >https://bugs.freedesktop.org/show_bug.cgi?id=41822 > >At any rate, on Solaris, we are disabling building with libsamplerate >for this reason. It seems a bit ugly that libsamplerate is enabled >by default by the PulseAudio configure script if it is available if >there are these sorts of concerns. Just out of curiosity, why does Solaris care about having no GPL in the PA process? (And yupp, here too this sounds like a bug if clients ever end up linking against libpulsecore. That library is not API stable, and things will end in desaster if this happens). > 3) On Solaris, the PulseAudio GConf module does not compile since the >"module_info" structure defined in the PulseAudio code conflicts >with a structure with the same name in /usr/include/sys/stream.h. >Could the PulseAudio code be updated to use a more unique PulseAudio >specific name as suggested in the patch in this bug: > >https://bugs.freedesktop.org/show_bug.cgi?id=41823 > >Note that sys/stream.h is included by sys/types.h on Solaris, and >sys/types.h is included in the src/modules/gconf/modules-gconf.c >PulseAudio file. The GConf code probably should go away anyway, and be replaced by dconf/gsettings. Lennart -- Lennart Poettering - Red Hat, Inc. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
'Twas brillig, and Lennart Poettering at 17/10/11 02:48 did gyre and gimble: >> 3) On Solaris, the PulseAudio GConf module does not compile since the >>"module_info" structure defined in the PulseAudio code conflicts >>with a structure with the same name in /usr/include/sys/stream.h. >>Could the PulseAudio code be updated to use a more unique PulseAudio >>specific name as suggested in the patch in this bug: >> >>https://bugs.freedesktop.org/show_bug.cgi?id=41823 >> >>Note that sys/stream.h is included by sys/types.h on Solaris, and >>sys/types.h is included in the src/modules/gconf/modules-gconf.c >>PulseAudio file. > > The GConf code probably should go away anyway, and be replaced by > dconf/gsettings. While dconf/gsettings is an option, I'd be more in favour personally of using whatever pa_database* stuff we use (this was my intension in this area with module-loader). I'm certainly not against dconf or whatever, but if we do migrate module-gocnf to it, then I'd prefer to see dconf as a universal database provider in PA like gdb, tdb, plaintext etc. Having two different mechanisms of writing data to disk doesn't seem like the wises plan overall. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
On Mon, 17.10.11 10:33, Colin Guthrie (gm...@colin.guthr.ie) wrote: > > 'Twas brillig, and Lennart Poettering at 17/10/11 02:48 did gyre and gimble: > >> 3) On Solaris, the PulseAudio GConf module does not compile since the > >>"module_info" structure defined in the PulseAudio code conflicts > >>with a structure with the same name in /usr/include/sys/stream.h. > >>Could the PulseAudio code be updated to use a more unique PulseAudio > >>specific name as suggested in the patch in this bug: > >> > >>https://bugs.freedesktop.org/show_bug.cgi?id=41823 > >> > >>Note that sys/stream.h is included by sys/types.h on Solaris, and > >>sys/types.h is included in the src/modules/gconf/modules-gconf.c > >>PulseAudio file. > > > > The GConf code probably should go away anyway, and be replaced by > > dconf/gsettings. > > While dconf/gsettings is an option, I'd be more in favour personally of > using whatever pa_database* stuff we use (this was my intension in this > area with module-loader). Well, private database do not have change notificiation, which makes them a pretty useless replacement. > I'm certainly not against dconf or whatever, but if we do migrate > module-gocnf to it, then I'd prefer to see dconf as a universal database > provider in PA like gdb, tdb, plaintext etc. Having two different > mechanisms of writing data to disk doesn't seem like the wises plan overall. Nah, I don't really agree. Configuration is configuration. Remembering state or learned rules is remembering state or learned rules. The former is something you might want to share with other apps, the latter something that is private to you. The former is something you need to have a clear schema for, so that external code can interfere with it, but this isn't needed that much for the latter. Lennart -- Lennart Poettering - Red Hat, Inc. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
Lennart: The decision was made recently to integrate PulseAudio into Solaris, so that is pretty exciting. I am not exactly sure when it will integrate. At the moment, I am just working to get it building and working okay. On which backend? OSS? Note that OSS support in PA never came close in any way to what the ALSA backend provides. Yes, on Solaris we use the OSS backend. Yes, I know that PA with OSS does not support all the features it supports with ALSA (e.g. glitch free features). This was one reason why adoption of PA on Solaris has been slow. The value-add that tipped things over the edge was the fact that the Sun Ray team discovered that PA makes audio work a lot better for Sun Ray setups and they requested that PA be added to Solaris. 1) The Solaris linker does not allow lazy linking, so client programs must link against all libraries that contain symbols used by the program. So I filed this bug: https://bugs.freedesktop.org/show_bug.cgi?id=41539 This sounds wrong. clients should never link to libpulsecore as that library is not API stable. 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. Note that all of PA is LGPL. Only if you link against libsamplerate it effectively becomes GPL (due to the famous viral nature of GPL). But since libsamplerate is option this is generally not a problem. It seems that there is also a bug in PA with clients linking against libsamplerate that Arun Raghavan noticed yesterday and fixed. So, it seems this was an issue as well. Just out of curiosity, why does Solaris care about having no GPL in the PA process? If libsamplerate is only used in the PA server, then this is no real problem. However, after building PA and various PA clients (such as the GStreamer PulseAudio backend), I was finding that clients needed to link against libpulsecore and libsamplerate. It is undesirable to make all PA clients GPL obviously. (And yupp, here too this sounds like a bug if clients ever end up linking against libpulsecore. That library is not API stable, and things will end in desaster if this happens). Now that I am looking at this more closely, I suspect that my attached patch to address the above linking issue is wrong, and I need to find a better way to get clients to link properly without linking in libpulsecore. The GConf code probably should go away anyway, and be replaced by dconf/gsettings. This is regarding bug #41823. Sure, but in the meantime, it would be nice if this minor issue could be fixed. Simply renaming the GConf module_info variable to something less generic should do it. Brian --- pulseaudio-0.99.2/src/Makefile.am-orig 2011-09-19 12:36:47.979760924 -0500 +++ pulseaudio-0.99.2/src/Makefile.am 2011-09-19 12:46:09.319041727 -0500 @@ -186,28 +186,28 @@ bin_SCRIPTS += start-pulseaudio-x11 star endif pacat_SOURCES = utils/pacat.c -pacat_LDADD = $(AM_LDADD) libp
Re: [pulseaudio-discuss] PulseAudio support on Solaris
2011/10/17 Brian Cameron : >> (And yupp, here too this sounds like a bug if clients ever end up >> linking against libpulsecore. That library is not API stable, and things >> will end in desaster if this happens). > > Now that I am looking at this more closely, I suspect that my attached > patch to address the above linking issue is wrong, and I need to find a > better way to get clients to link properly without linking in > libpulsecore. Lennart meant 3rd party applications that use libpulse to access PulseAudio functionality. The clients in the pulse tree (src/utils and src/tests) are can link against libpulsecore, if needed. They are special because if the API of pulsecore changes, those will also be changed to match. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
'Twas brillig, and Lennart Poettering at 17/10/11 12:30 did gyre and gimble: > On Mon, 17.10.11 10:33, Colin Guthrie (gm...@colin.guthr.ie) wrote: > >> >> 'Twas brillig, and Lennart Poettering at 17/10/11 02:48 did gyre and gimble: 3) On Solaris, the PulseAudio GConf module does not compile since the "module_info" structure defined in the PulseAudio code conflicts with a structure with the same name in /usr/include/sys/stream.h. Could the PulseAudio code be updated to use a more unique PulseAudio specific name as suggested in the patch in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=41823 Note that sys/stream.h is included by sys/types.h on Solaris, and sys/types.h is included in the src/modules/gconf/modules-gconf.c PulseAudio file. >>> >>> The GConf code probably should go away anyway, and be replaced by >>> dconf/gsettings. >> >> While dconf/gsettings is an option, I'd be more in favour personally of >> using whatever pa_database* stuff we use (this was my intension in this >> area with module-loader). > > Well, private database do not have change notificiation, which makes > them a pretty useless replacement. Depends how they are hooked up - see below. >> I'm certainly not against dconf or whatever, but if we do migrate >> module-gocnf to it, then I'd prefer to see dconf as a universal database >> provider in PA like gdb, tdb, plaintext etc. Having two different >> mechanisms of writing data to disk doesn't seem like the wises plan overall. > > Nah, I don't really agree. Configuration is configuration. Remembering > state or learned rules is remembering state or learned rules. The former > is something you might want to share with other apps, the latter > something that is private to you. The former is something you need to > have a clear schema for, so that external code can interfere with it, > but this isn't needed that much for the latter. Well the general plan was to provide a protocol extension to allow for modules to be defined. This would obviously be accessible via the protocol and thus the whole subscription system is available. This provides more than enough structure for "change notification" That said, I'm not specifically against using dconf, but the semantics for module loading will become more complex and thus any client implementing it will have to implement that logic accordingly. Looking at it in as detached a way as I can allow myself, neither argument is particularly strong (i.e. the internal storage using gconf or module info using built in databases). Having a defined schema for the internal data is not necessarily a bad thing and likewise allowing external apps to fiddle with it could be useful. And similarly, providing define ways to configure module loading with certain useful features (like a trigger sink and/or trigger source - e.g. only load module-loopback when both $sink and $source are available) is something can could be pretty easily defined with API extensions like how stream-restore works. The latter has both pros and cons - pro being that it may be useful for setups where dconf might not be available, and cons, it's more API to write, document and keep working into the future. Anyway, we can argue the toss over this next week sometime :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
2011/10/17 Brian Cameron : > 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. I audited the utils and tests and the following programs where your patch adds libpulsecore only use functionality from libpulse and libpulsecommon: pacat, pactl, pasuspender, pacmd, pax11publish, mainloop-test, voltest libpulsecore should not be added for these, because they don't use functionality from that library. Your output log from above suggests that something in libpulsecommon uses functionality from pulsecore/object.[ch], so those files should probably be moved to from libpulsecore to libpulsecommon. Does that fix linking on Solaris? The rest of the utils only use public libpulse headers, so for these libpulsecommon should even be removed from the linker line. get-binary-name, pacat-simple, parec-simple, extended-test, channelmap-test, sync-playback, gtk-test, connect-stress Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
2011/10/17 Brian Cameron : > 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
Maarten: I updated the patch as attached to address your comments. This has "#ifdef __sun" used more properly and a comment. Also note that I added a comment to the bug to answer your question that LOG_INFO and LOG_WARNING are defined in the system syslog.h header, not in PulseAudio. Brian On 10/16/11 08:01 AM, Maarten Bosmans wrote: 2011/10/15 Brian Cameron: 4) Some straightforward compile issues that seem appropriate to fix for building on Solaris is in the patch in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=41538 This one looks good, see also my comment attached to the patch. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss --- pulseaudio-0.9.22/src/pulsecore/socket-server.c-orig2011-06-09 16:43:59.167250309 -0500 +++ pulseaudio-0.9.22/src/pulsecore/socket-server.c 2011-06-09 16:59:12.482110908 -0500 @@ -45,6 +45,14 @@ #ifdef HAVE_LIBWRAP #include +/* Solaris requires that the allow_severity and deny_severity variables be + * defined in the client program. + */ +#ifdef __sun +#include +int allow_severity = LOG_INFO; +int deny_severity = LOG_WARNING; +#endif #endif #include --- pulseaudio-0.99.2/src/modules/module-solaris.c-orig 2011-09-15 17:52:00.424449438 -0500 +++ pulseaudio-0.99.2/src/modules/module-solaris.c 2011-09-15 17:54:32.023880146 -0500 @@ -526,7 +526,7 @@ static void source_set_volume(pa_source if (u->fd >= 0) { AUDIO_INITINFO(&info); -info.play.gain = pa_cvolume_max(&s->volume) * AUDIO_MAX_GAIN / PA_VOLUME_NORM; +info.play.gain = pa_cvolume_max(&s->real_volume) * AUDIO_MAX_GAIN / PA_VOLUME_NORM; assert(info.play.gain <= AUDIO_MAX_GAIN); if (ioctl(u->fd, AUDIO_SETINFO, &info) < 0) { @@ -548,7 +548,7 @@ static void source_get_volume(pa_source if (ioctl(u->fd, AUDIO_GETINFO, &info) < 0) pa_log("AUDIO_SETINFO: %s", pa_cstrerror(errno)); else -pa_cvolume_set(&s->volume, s->sample_spec.channels, info.play.gain * PA_VOLUME_NORM / AUDIO_MAX_GAIN); +pa_cvolume_set(&s->real_volume, s->sample_spec.channels, info.play.gain * PA_VOLUME_NORM / AUDIO_MAX_GAIN); } } ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
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: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss --- pulseaudio-1.0/src/pulsecore/core-scache.h-orig 2011-10-19 09:56:30.443291065 -0500 +++ pulseaudio-1.0/src/pulsecore/core-scache.h 2011-10-19 09:57:15.863329411 -0500 @@ -27,8 +27,6 @@ #include #include -#define PA_SCACHE_ENTRY_SIZE_MAX (1024*1024*16) - typedef struct pa_scache_entry { uint32_t index; pa_core *core; --- pulseaudio-1.0/src/pulsecore/memchunk.h-orig2011-10-19 09:56:45.049056686 -0500 +++ pulseaudio-1.0/src/pulsecore/memchunk.h 2011-10-19 09:56:59.243495913 -0500 @@ -53,4 +53,6 @@ pa_memchunk* pa_memchunk_memcpy(pa_memch /* Return TRUE if any field is set != 0 */ pa_bool_t pa_m
Re: [pulseaudio-discuss] PulseAudio support on Solaris
2011/10/19 Brian Cameron : > 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio support on Solaris
Maarten: 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) Probably because these functions are actually unused by any clients, and the lazy linker used on Linux doesn't care, wheras Solaris linker is more strict. You could probably make the Linux linker more strict with the right arguments. 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? Since core-scache.h includes memchunk.h anyway, it will always be available to anything that previously included core-scache.h. As I said PulseAudio builds okay with this change, no issues with other things not finding it. The problem with the workaround is obviously that something about the scache does not belong in memchunk.h conceptually. As I said in my comments, I do not really care how the headers are organized. If creating a new separate header file with only the #define that can be included from core-scache.h and pstream.c, that would obviously also be fine. There are probably a million ways to fix this sort of issue. If you instruct me how you would prefer this to be organized, I can create a new patch. 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. Sure. Do you need me to split this file into two patches for you? Brian ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss