[pulseaudio-discuss] PulseAudio support on Solaris

2011-10-15 Thread 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.

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-16 Thread Maarten Bosmans 
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

2011-10-16 Thread Lennart Poettering 
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

2011-10-17 Thread Colin Guthrie 
'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

2011-10-17 Thread Lennart Poettering 
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

2011-10-17 Thread Brian Cameron 


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 Thread Maarten Bosmans 
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

2011-10-17 Thread Colin Guthrie 
'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-18 Thread Maarten Bosmans 
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-19 Thread Maarten Bosmans 
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

2011-10-19 Thread Brian Cameron 


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

2011-10-19 Thread Brian Cameron 


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 Thread Maarten Bosmans 
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

2011-10-19 Thread Brian Cameron 


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