Bug #1780

pulseaudio build

Added by justin over 4 years ago. Updated about 4 years ago.

Status:ClosedStart date:
Priority:LowDue date:
Assignee:tuxillo% Done:

0%

Category:-
Target version:-

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.

pulse-audio-dragonfly-patch (485 Bytes) c.turner, 06/15/2010 09:35 AM

History

#1 Updated by ahuete.devel over 4 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 <>:
>
> 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.
>
>
>
>

#2 Updated by justin over 4 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/5b6d478465a99af56589ef42d9f7a5d90d9adce4
>
> With 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.

#3 Updated by dillon over 4 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
<>

#4 Updated by ahuete.devel over 4 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 <>:
> :>> ./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
>                                        <>
>

#5 Updated by justin over 4 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.

#6 Updated by sjg over 4 years ago

On Sun, Jun 13, 2010 at 3:50 AM, Antonio Huete Jimenez
<> 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 :P
>
> Cheers,
> Antonio Huete
>
> 2010/6/13 Matthew Dillon <>:
>> :>> ./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
>>                                        <>
>>
>
>
>
> --
> 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

#7 Updated by swildner over 4 years ago

On 6/13/2010 15:52, Samuel J. Greear wrote:
> On Sun, Jun 13, 2010 at 3:50 AM, Antonio Huete Jimenez
> <> 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 :P
>>
>> Cheers,
>> Antonio Huete
>>
>> 2010/6/13 Matthew Dillon<>:
>>> :>> ./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
>>> <>
>>>
>>
>>
>>
>> --
>> 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

Yeah, well, that's SUSv2...

However, see the change history here:

http://www.opengroup.org/onlinepubs/9699919799/functions/mlockall.html

Sascha

#8 Updated by c.turner over 4 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!

#9 Updated by c.turner over 4 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

#10 Updated by swildner over 4 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.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
>

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

#11 Updated by tuxillo over 4 years ago

Okay, I'm grabbing this.

#12 Updated by tuxillo about 4 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

#13 Updated by sjg about 4 years ago

We have stubs everywhere now, correct? So this can be closed?

#14 Updated by justin about 4 years ago

On Thu, September 9, 2010 10:18 pm, Samuel J. Greear \(via DragonFly issue
tracker\) wrote:
>
> Samuel J. Greear <> 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.

Also available in: Atom PDF