openal-soft @1.15.1: complains about pulseaudio (@5.0) not being built with capabilities support

[cooljeanius (Eric Gallager)]

I am working on a program that makes some calls to OpenAL, and I am having it dlopen() the libopenal.dylib that the openal-soft port provides. When debugging and it hits a function that tries to open a sound device via OpenAL, it prints a message like this:

W: [] caps.c: [1mNormally all extra capabilities would be dropped now, but that's impossible because PulseAudio was built without capabilities support.[0m
AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"

I cannot find any such message in the code of the program that I am working on, so I must assume that the message is coming from OpenAL. I am not sure why OpenAL is trying to use PulseAudio, as I found no mention of it in the Portfile for openal-soft, and otool -L reports no linkages against it... maybe it is being dlopen()-ed as well? There was a configure check for pulseaudio in openal-soft's CMakeLists.txt, at least... Anyways, back to the error message... I checked pulseaudio's configure script for any flags that might be relevant, and noticed that the pulseaudio Portfile added the following to its configure.args:

--without-caps

Why is this flag necessary? Could it be removed? If so, would that be the right approach to enabling capabilities support in PulseAudio?

[ryandesign (Ryan Carsten Schmidt)]

Replying to egall@…:

I am not sure why OpenAL is trying to use PulseAudio, as I found no mention of it in the Portfile for openal-soft, and otool -L reports no linkages against it... maybe it is being dlopen()-ed as well? There was a configure check for pulseaudio in openal-soft's CMakeLists.txt, at least...

Yes, I see dlopen() is used in openal-soft-1.15.1/Alc/helpers.c. Apparently I should add a pulseaudio dependency to openal-soft, and one for portaudio as well. Done in r118122.

Anyways, back to the error message... I checked pulseaudio's configure script for any flags that might be relevant, and noticed that the pulseaudio Portfile added the following to its configure.args:

--without-caps

Why is this flag necessary? Could it be removed? If so, would that be the right approach to enabling capabilities support in PulseAudio?

Sounds reasonable. Please try rebuilding pulseaudio without the --without-caps flag and see if that resolves the issue; if so, we can make that change in the portfile.

[lubodiakov@…]

Replying to ryandesign@…:

Replying to egall@…:

I am not sure why OpenAL is trying to use PulseAudio, as I found no mention of it in the Portfile for openal-soft, and otool -L reports no linkages against it... maybe it is being dlopen()-ed as well? There was a configure check for pulseaudio in openal-soft's CMakeLists.txt, at least...

Yes, I see dlopen() is used in openal-soft-1.15.1/Alc/helpers.c. Apparently I should add a pulseaudio dependency to openal-soft, and one for portaudio as well. Done in r118122.

Adding dependencies for portaudio and pulseaudio has the nasty side effect that with those, something close to 20 other ports, mostly to do with Xorg get pulled in as well.

udo port install openal-soft +universal -portaudio -pulseaudio
--->  Computing dependencies for openal-soft
--->  Dependencies to be installed: portaudio pulseaudio dbus fftw-3-single fftw-3 glib2 libffi libxml2 gtk3 at-spi2-atk at-spi2-core dbus-glib gobject-introspection cairo fontconfig freetype libpng libpixman xorg-libXext xorg-libX11 xorg-bigreqsproto xorg-inputproto xorg-kbproto xorg-libXau xorg-xproto xorg-libXdmcp xorg-libxcb xorg-libpthread-stubs xorg-xcb-proto xorg-util-macros xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto xorg-xtrans xorg-xcb-util xrender xorg-renderproto intltool gnome-common p5.16-getopt-long p5.16-pathtools p5.16-scalar-list-utils p5.16-xml-parser xorg-libXevie xorg-evieproto xorg-libXi xorg-libXfixes xorg-fixesproto xorg-libXtst xorg-recordproto xorg-libice xorg-libsm atk dbus-python27 gdk-pixbuf2 jasper jpeg tiff hicolor-icon-theme pango Xft2 harfbuzz graphite2 shared-mime-info xorg-libXcomposite xorg-compositeproto xorg-libXcursor xorg-libXdamage xorg-damageproto xorg-libXinerama xorg-xineramaproto xorg-libXrandr xorg-randrproto json-c libatomic_ops libsamplerate libsndfile flac libogg libvorbis orc speex
--->  Configuring portaudio
--->  Building portaudio
^C

I was trying to build openal-soft ONLY, for use inside OS X, with no (or as few as possible) dependencies on Xorg! I commented out the lines in the portfile for those two dependencies in my local port file, and it builds. Haven't tested if I can link something to the dylib, but it looks good in otool, lipo, etc. so it should. Might I suggest reverting the change, or at least making it mandatory only on newer versions of Mac OS X? 10.5 here, and it works better for me without portaudio or pulseaudio.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

Replying to egall@…:

Why is this flag necessary? Could it be removed? If so, would that be the right approach to enabling capabilities support in PulseAudio?

Sounds reasonable. Please try rebuilding pulseaudio without the --without-caps flag and see if that resolves the issue; if so, we can make that change in the portfile.

Eric: were you able to rebuild the port without this flag? If so, did that fix the problem you were experiencing? Or, can you tell me how to reproduce the problem myself?

[ryandesign (Ryan Carsten Schmidt)]

Replying to lubodiakov@…:

Adding dependencies for portaudio and pulseaudio has the nasty side effect that with those, something close to 20 other ports, mostly to do with Xorg get pulled in as well.
[snip]
I was trying to build openal-soft ONLY, for use inside OS X, with no (or as few as possible) dependencies on Xorg! I commented out the lines in the portfile for those two dependencies in my local port file, and it builds. Haven't tested if I can link something to the dylib, but it looks good in otool, lipo, etc. so it should. Might I suggest reverting the change, or at least making it mandatory only on newer versions of Mac OS X? 10.5 here, and it works better for me without portaudio or pulseaudio.

Lubo: usually we try to make ports as full-featured as possible. We would rather some users install some ports they don't need at the moment, than have other users who need a capability not have it and wonder how to get it.

portaudio has no dependencies, so that's not a problem. pulseaudio does depend on gtk3, which depends on lots of ports including several xorg ports.

If pulseaudio support is not thought to be essential to openal-soft, it could be made a variant. I would still tend to err on the side of caution and enable it by default, but you could disable it if you wanted to avoid those dependencies and you don't need the functionality they provide.

[lubodiakov@…]

Replying to ryandesign@…:

Replying to lubodiakov@…:

Adding dependencies for portaudio and pulseaudio has the nasty side

...cut for the sake of brevity

If pulseaudio support is not thought to be essential to openal-soft, it could be made a variant. I would still tend to err on the side of caution and enable it by default, but you could disable it if you wanted to avoid those dependencies and you don't need the functionality they provide.

Again thanks for the response.

I do in general agree with the idea that it's better to include some component that might not be absolutely necessary, rather than leaving out something useful, especially if there are variants with and without said dependency.

I'll have to look into how to create a variant without pulseaudio since it is what depends on Xorg and submit it so it is available later straight from the repo. Short of making a variant which does not yet exist, is there a way to build openal-soft with no pulseaudio now other than commenting out the local portfile crudely like I did?

[ryandesign (Ryan Carsten Schmidt)]

Right now, pulseaudio is an unconditional dependency in the port.

[cooljeanius (Eric Gallager)]

Replying to ryandesign@…:

Replying to ryandesign@…:

Replying to egall@…:

Why is this flag necessary? Could it be removed? If so, would that be the right approach to enabling capabilities support in PulseAudio?

Sounds reasonable. Please try rebuilding pulseaudio without the --without-caps flag and see if that resolves the issue; if so, we can make that change in the portfile.

Eric: were you able to rebuild the port without this flag? If so, did that fix the problem you were experiencing? Or, can you tell me how to reproduce the problem myself?

Right, kind of forgot about this, although coincidentally it actually came up again for me today in a different context; apparently VLC-devel also uses pulseaudio, so it was printing similar warnings in its log messages:

9/25/14 9:15:04 AM	[0x0-0xa76a76].org.videolan.vlc[66585]	W: [] caps.c: Normally all extra capabilities would be dropped now, but that's impossible because PulseAudio was built without capabilities support.

Anyways, copying the pulseaudio Portfile over to my local Portfile repo now, and at least making the s/--without-caps/--with-caps/g change for testing next...

Replying to ryandesign@…:

If pulseaudio support is not thought to be essential to openal-soft, it could be made a variant.

I think I'd kind of actually prefer this, too. I'd still enable it, but it would be nice to be able to disable it just in case.

[cooljeanius (Eric Gallager)]

Well, building pulseaudio with the --with-caps flag seems to work, and it passes its testsuite with it (after adding a testsuite to the Portfile), but the log message continues to show up... here it is with some more context:

9/25/14 10:48:32 PM	[0x0-0xb5bb5b].org.videolan.vlc[40727]	W: [] caps.c: Normally all extra capabilities would be dropped now, but that's impossible because PulseAudio was built without capabilities support.
9/25/14 10:48:35 PM	pulseaudio[40915]	[] module.c: module-detect is deprecated: Please use module-udev-detect instead of module-detect!
9/25/14 10:48:35 PM	pulseaudio[40915]	[] module-detect.c: failed to detect any sound hardware.
9/25/14 10:48:35 PM	pulseaudio[40915]	[] module.c: Failed to load module "module-detect" (argument: ""): initialization failed.
9/25/14 10:48:35 PM	pulseaudio[40915]	[] main.c: Module load failed.
9/25/14 10:48:35 PM	pulseaudio[40915]	[] main.c: Failed to initialize daemon.
9/25/14 10:48:35 PM	pulseaudio[40912]	[] main.c: Daemon startup failed.
9/25/14 10:48:35 PM	[0x0-0xb5bb5b].org.videolan.vlc[40727]	[0x101846c60] pulse audio output error: PulseAudio server connection failure: Connection refused

I suppose this is kind of an upstream issue for pulseaudio though...

[lubodiakov@…]

Cc Me!

[lubodiakov@…]

Proposed new Portfile, which adds a new variant "no_pulseaudio". Tested locally by me, works. No other changes.

Also, the diff between it and the original.

[ryandesign (Ryan Carsten Schmidt)]

We don't use variants whose names begin with negative words like "no" anymore. Instead we would have a "pulseaudio" variant and enable it by default, allowing the user to disable it if desired. Simply removing a dependency is also insufficient. You need to ensure that if the user does not request pulseaudio support in openal-soft (or rather, requests that pulseaudio support not be provided), that pulseaudio support is not provided, even if the pulseaudio port is already installed. This is typically accomplished via a configure argument, though it can vary by build system.

[lubodiakov@…]

Replying to ryandesign@…:

We don't use variants whose names begin with negative words like "no" anymore. Instead we would have a "pulseaudio" variant and enable it by default, allowing the user to disable it if desired.

OK, I have made the changes for this to the Portfile. I was just trying to keep the changes minimal, this way changes more of it, but no problem.

Simply removing a dependency is also insufficient. You need to ensure that if the user does not request pulseaudio support in openal-soft (or rather, requests that pulseaudio support not be provided), that pulseaudio support is not provided, even if the pulseaudio port is already installed. This is typically accomplished via a configure argument, though it can vary by build system.

CMakeLists.txt inside the source tarball checks which backend is available automatically, and only links to it. The author of openal-soft designed it that way.

[lubodiakov@…]

Portfile with new "pulseaudio" variant, on by default but can be disabled

[lubodiakov@…]

Diff from original portfile to new one with variant "pulseaudio"

[mkae (Marko Käning)]

Cc Me!

[dbevans (David B. Evans)]

CC current pulseaudio maintainer

[ryandesign (Ryan Carsten Schmidt)]

Replying to lubodiakov@…:

Simply removing a dependency is also insufficient. You need to ensure that if the user does not request pulseaudio support in openal-soft (or rather, requests that pulseaudio support not be provided), that pulseaudio support is not provided, even if the pulseaudio port is already installed. This is typically accomplished via a configure argument, though it can vary by build system.

CMakeLists.txt inside the source tarball checks which backend is available automatically, and only links to those available. The author of openal-soft designed it that way. Nothing for me to alter, it already works. I have no pulseaudio, so for me it only links to CoreAudio, AudioUnit, AudioToolbox, etc. no pulseaudio at all:

That is not sufficient for use in MacPorts. If a user already has pulseaudio installed, but requests to install the openal-soft port without the pulseaudio variant, openal-soft must not link with pulseaudio.

[Ionic (Mihai Moldovan)]

I'll have to look through this thread to find out why capabilities support was disabled.

I'm generally in favor of re-enabling this, if supported on OS X. (There's a chance it's not...)

[Ionic (Mihai Moldovan)]

I did re-enable capabilities support, but this didn't change anythings. Capabilities are plainly not supported on OS X.

[dbevans (David B. Evans)]

Replying to ionic@…:

I did re-enable capabilities support, but this didn't change anythings. Capabilities are plainly not supported on OS X.

Indeed. libcap is required for pulseaudio to enable this feature regardless of the --with/without-caps option.

From a recent build log

checking for library containing cap_init... no
checking sys/capability.h usability... no
checking sys/capability.h presence... no
checking for sys/capability.h... no

AFAIK libcap is currently only available on Linux platforms where the following requirements must be met:

• A recent linux kernel (2.6.24+) built with POSIX Capabilities enabled
• A file system that supports extended attributes such as ext3
• the libcap2 user space package

That given, doesn't seem like something that you'll see on Mac OS X any time soon.

I suggest that about the only practical thing to do is to track down and disable the obnoxious message which is really out of place here.

For a good run down on what it's all about see ​http://www.friedhoff.org/posixfilecaps.html

[Ionic (Mihai Moldovan)]

Be careful. Capabilities does not refer to FS capabilities support only. It also refers to running "arbitrary" functions/programs with elevated privileges. Those are mostly granted via setting capabilities on binaries, but I guess there are other ways, too.

CAP_NET_ADMIN is widely used to let users change network interfaces.

PulseaAudio is probably interested in CAP_SYS_NICE or CAP_SYS_RESOURCE for real-time support.

[dbevans (David B. Evans)]

I think here pulseaudio wants to drop unnecessary privileges if it can as a security issue. However, since libcap isn't implemented on Darwin, it's a moot issue in any case.

[cooljeanius (Eric Gallager)]

Replying to dbevans:

For a good run down on what it's all about see ​http://www.friedhoff.org/posixfilecaps.html

Have to go back to February in archive dot org for that link to work: ​http://web.archive.org/web/20190225184922/http://www.friedhoff.org/posixfilecaps.html