Bug #1712
closed
pulseaudio fails to build due to mlockall missed in libc
Added by dennis.melentyev over 14 years ago.
Updated over 14 years ago.
Description
Hi,
I tried to build pulseaudio from pkgsrc and it failed because of
mlockall() is not in libc.
As far as I understand, that part is not critical and I modified
patch-ab as attached.
Another thing is: we do have mlockall syscall in mman.h AND some code
in kernel sources about this.
Shouldn't we put relevant bits into libc? Sorry, I'm not going to address this.
The system:
dennis@dfly (xterm-color) > gcc -v
Using built-in specs.
Target: i386-pc-dragonflybsd
Configured with: DragonFly/i386 system compiler
Thread model: posix
gcc version 4.1.2 (DragonFly)
dennis@dfly (xterm-color) > uname -a
DragonFly dfly.melent.local 2.5.1-DEVELOPMENT DragonFly
v2.5.1.1031.g8ded21-DEVELOPMENT #1: Wed Mar 24 01:41:57 EET 2010
root@dfly.melent.local:/usr/obj/usr/src/sys/GENERIC i386
Files
On Wed, March 31, 2010 7:15 pm, Dennis Melentyev wrote:
Hi,
I tried to build pulseaudio from pkgsrc and it failed because of
mlockall() is not in libc.
As far as I understand, that part is not critical and I modified
patch-ab as attached.
Have you sent this in for pkgsrc via NetBSD's bug reporting page? I had
very quick results yesterday asking for sun-jdk6/sun-jre6 to be unmasked
for DragonFly.
Hi,
Any update on this? I've just tested the build today again and it
stills fails so I guess the patch hasn't been submitted in a PR.
Cheers,
Antonio Huete
2010/4/1 Justin C. Sherrill <justin@shiningsilence.com>:
On Wed, March 31, 2010 7:15 pm, Dennis Melentyev wrote:
Hi,
I tried to build pulseaudio from pkgsrc and it failed because of
mlockall() is not in libc.
As far as I understand, that part is not critical and I modified
patch-ab as attached.
Have you sent this in for pkgsrc via NetBSD's bug reporting page? I had
very quick results yesterday asking for sun-jdk6/sun-jre6 to be unmasked
for DragonFly.
So mlockall/munlockall is a no-op in the kernel, but the syscall handler is
there. We should probably still expose it from libc and have the kernel return
ENOSYS, right?
Hi,
That sounds like a good idea to me, +1.
Cheers,
Antonio Huete
On 04/11/10 18:00, Venkatesh Srinivas (via DragonFly issue tracker) wrote:
Venkatesh Srinivas <me@acm.jhu.edu> added the comment:
So mlockall/munlockall is a no-op in the kernel, but the syscall handler is
there. We should probably still expose it from libc and have the kernel return
ENOSYS, right?
_____________________________________________
DragonFly issue tracker <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue1712>
_____________________________________________
Hi,
Committed in 5b6d478465a99af56589ef42d9f7a5d90d9adce4
This should fix the build for audio/pulseaudio.
Thanks Venkatesh!
Regards,
Antonio Huete
Perhaps its time to close this bug report?
Also available in: Atom
PDF