Bug #1780
closed
pulseaudio build
Added by justin over 14 years ago. Updated about 14 years ago.
0%
Description
pulseaudio stopped building on 2.6/i386/pkgsrc-2010Q1 - here's the error:
http://avalon.dragonflybsd.org/reports/i386/2.6/20100612.1126/pulseaudio-0.9.21nb2/build.log
Can anyone else build it successfully? I haven't seen it as a problem
(yet) in the other builds, which makes me suspicious.
Files
| pulse-audio-dragonfly-patch (485 Bytes) pulse-audio-dragonfly-patch | c.turner, 06/15/2010 09:35 AM |
Updated by ahuete.devel over 14 years ago
Hi Justin,
Which DF version is that? We have a stub mlockall() in master but I
think it is not MFC'ed to 2.6.
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/5b6d478465a99af56589ef42d9f7a5d90d9adce4
With master:
mlockall: Function not implemented
Cheers,
Antonio Huete
2010/6/12 Justin C. Sherrill <justin@shiningsilence.com>:
pulseaudio stopped building on 2.6/i386/pkgsrc-2010Q1 - here's the error:
http://avalon.dragonflybsd.org/reports/i386/2.6/20100612.1126/pulseaudio-0.9.21nb2/build.log
Can anyone else build it successfully? I haven't seen it as a problem
(yet) in the other builds, which makes me suspicious.
Updated by justin over 14 years ago
On Sat, June 12, 2010 5:11 pm, Antonio Huete Jimenez wrote:
Hi Justin,
Which DF version is that? We have a stub mlockall() in master but I
think it is not MFC'ed to 2.6.
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/5b6d478465a99af56589ef42d9f7a5d90d9adce4With master:
./t_ml
mlockall: Function not implemented
Is it worth MFC'ing? I have a vague feeling I had talked to someone about
this before, but I can't find evidence of it.
Updated by dillon over 14 years ago
:>> ./t_ml
:> mlockall: Function not implemented
:
:Is it worth MFC'ing? I have a vague feeling I had talked to someone about
:this before, but I can't find evidence of it.
What direction are we talking about? Making it return ENOSYS or
making it return success but otherwise be a NOP ?-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by ahuete.devel over 14 years ago
Hi,
As it is not really implemented I think ENOSYS is more appropiate. But
definitely the best thing at all is to implemented it :P
Cheers,
Antonio Huete
2010/6/13 Matthew Dillon <dillon@apollo.backplane.com>:
:>> ./t_ml
:> mlockall: Function not implemented
:
:Is it worth MFC'ing? I have a vague feeling I had talked to someone about
:this before, but I can't find evidence of it.What direction are we talking about? Making it return ENOSYS or
making it return success but otherwise be a NOP ?-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by justin over 14 years ago
On Sun, June 13, 2010 12:41 am, Matthew Dillon wrote:
:>> ./t_ml
:> mlockall: Function not implemented
:
:Is it worth MFC'ing? I have a vague feeling I had talked to someone
about
:this before, but I can't find evidence of it.What direction are we talking about? Making it return ENOSYS or
making it return success but otherwise be a NOP ?
Whichever makes it build on 2.6. I don't know which that is. I'm a bit
suspicious, because I don't remember pulseaudio breaking on 2.6/x86_64.
Updated by sjg over 14 years ago
On Sun, Jun 13, 2010 at 3:50 AM, Antonio Huete Jimenez
<ahuete.devel@gmail.com> wrote:
Hi,
As it is not really implemented I think ENOSYS is more appropiate. But
definitely the best thing at all is to implemented it :PCheers,
Antonio Huete2010/6/13 Matthew Dillon <dillon@apollo.backplane.com>:
:>> ./t_ml
:> mlockall: Function not implemented
:
:Is it worth MFC'ing? I have a vague feeling I had talked to someone about
:this before, but I can't find evidence of it.What direction are we talking about? Making it return ENOSYS or
making it return success but otherwise be a NOP ?-Matt
Matthew Dillon
<dillon@backplane.com>--
Cheers,
Antonio Huete
Returning ENOSYS is correct as per the specification.
The mlockall() and munlockall() functions will fail if:
[ENOSYS]
The implementation does not support this memory locking interface.
See: http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html
Sam
Updated by swildner over 14 years ago
On 6/13/2010 15:52, Samuel J. Greear wrote:
On Sun, Jun 13, 2010 at 3:50 AM, Antonio Huete Jimenez
<ahuete.devel@gmail.com> wrote:Hi,
As it is not really implemented I think ENOSYS is more appropiate. But
definitely the best thing at all is to implemented it :PCheers,
Antonio Huete2010/6/13 Matthew Dillon<dillon@apollo.backplane.com>:
:>> ./t_ml
:> mlockall: Function not implemented
:
:Is it worth MFC'ing? I have a vague feeling I had talked to someone about
:this before, but I can't find evidence of it.What direction are we talking about? Making it return ENOSYS or
making it return success but otherwise be a NOP ?-Matt
Matthew Dillon
<dillon@backplane.com>--
Cheers,
Antonio HueteReturning ENOSYS is correct as per the specification.
The mlockall() and munlockall() functions will fail if:
[ENOSYS]
The implementation does not support this memory locking interface.See: http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html
Yeah, well, that's SUSv2...
However, see the change history here:
http://www.opengroup.org/onlinepubs/9699919799/functions/mlockall.html
Sascha
Updated by c.turner over 14 years ago
Justin C. Sherrill wrote:
Can anyone else build it successfully? I haven't seen it as a problem
(yet) in the other builds, which makes me suspicious.
you can ifdef out this portion within pulseaudio..
I'm waay late on those patches I promised.. but yeah..
am staying online to get them done before world cuppage
GOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL!
Updated by c.turner over 14 years ago
Chris Turner wrote:
you can ifdef out this portion within pulseaudio..
Broken patch attached - Couldn't quite figgure out the correct
preprocessor macros to make this 'clean' - my actual build
used '#ifdef notyet' like some other things in main.c
In any event, we now have a 'mlockall' on head -
so probably need to see if this is even necessary
moving forward before trying to get it upstream,
unless anyone wants to get fancy with their 'ifdef's
and make it version specific
Updated by swildner over 14 years ago
On 6/15/2010 11:32, Chris Turner wrote:
Chris Turner wrote:
you can ifdef out this portion within pulseaudio..
Broken patch attached - Couldn't quite figgure out the correct
preprocessor macros to make this 'clean' - my actual build
used '#ifdef notyet' like some other things in main.cIn any event, we now have a 'mlockall' on head -
so probably need to see if this is even necessary
moving forward before trying to get it upstream,
unless anyone wants to get fancy with their 'ifdef's
and make it version specific
Actually, the proper fix would be to make pulseaudio check with
sysconf(3) for _SC_MEMLOCK, to see if the implementation supports it. In
our case, it would then quickly see that we don't, as we return -1.
Regards,
Sascha
Updated by tuxillo over 14 years ago
Hi all,
The problem here seems that despite pulseaudio checks it correctly or not, it
won't change the fact that we need stubs to avoid the 'unresolved symbols' at ld
time. After investigating this a bit I think it's okay by now to leave our stubs
returning ENOSYS so any call to the functions will simply fail.
BTW, we have utilities now in base using (cryptsetup) referencing
mlockall/munlockall.
In the mean time the fix has been MFC'ed so pulseaudio will likely build in 2.6
RELEASE also. We'll see in the next round of bulk builds.
Cheers,
Antonio Huete
Updated by sjg about 14 years ago
We have stubs everywhere now, correct? So this can be closed?
Updated by justin about 14 years ago
On Thu, September 9, 2010 10:18 pm, Samuel J. Greear \(via DragonFly issue
tracker\) wrote:
Samuel J. Greear <sjg@evilcode.net> added the comment:
We have stubs everywhere now, correct? So this can be closed?
I think so - it builds on i386/2.7. It failed in my most recent
x86_64/2.7 build but that was an indirect failure because of m4.