[Buildroot] broken alsa-lib

[Buildroot] broken alsa-lib

[Daniel Mack]

Hi,

as pointed out in two threads on the alsa-dev ML, there seems to be
general problem with ALSA libraries built by buildroot:

	http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/014999.html
	http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/015005.html

Any hints, anyone?

Daniel

[Buildroot] broken alsa-lib

[Peter Korsgaard]

>>>>> "Daniel" == Daniel Mack <daniel@caiaq.de> writes:

 Daniel> Hi,
 Daniel> as pointed out in two threads on the alsa-dev ML, there seems to be
 Daniel> general problem with ALSA libraries built by buildroot:

 Daniel> 	http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/014999.html
 Daniel> 	http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/015005.html

Alsa-lib had an issue with !LARGEFILE support that we fixed recently
and pushed upstream, but other than that I don't remember any
bugreports.

You mentioned something about 1.0.19, but buildroot is still using
1.0.18, are you using some local changes?

-- 
Bye, Peter Korsgaard

[Buildroot] broken alsa-lib

[Daniel Mack]

On Mon, Feb 23, 2009 at 12:16:56AM +0100, Peter Korsgaard wrote:
>  Daniel> as pointed out in two threads on the alsa-dev ML, there seems to be
>  Daniel> general problem with ALSA libraries built by buildroot:
> 
>  Daniel> 	http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/014999.html
>  Daniel> 	http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/015005.html
> 
> Alsa-lib had an issue with !LARGEFILE support that we fixed recently
> and pushed upstream, but other than that I don't remember any
> bugreports.

Hmm, what I see is certainly not a LARGEFILE issue.

> You mentioned something about 1.0.19, but buildroot is still using
> 1.0.18, are you using some local changes?

Yes, true, forgot to mention that. We locally patched to use 1.0.19 but
that was merely because I hoped to fix the problem by that - the same
problem exists with 1.0.18. And I got this problem since a long time and
always patched my way around it (by overriding the value with some
hard-coded constant) as I thought it is a minor issue that will be fixed
sooner or later. But as it turns out, the problem seems to be bigger and
might also have other impact than just that single failing function
call.

I'll build alsa-lib and alsa-utils with OE tomorrow and see whether that
makes any difference.

Daniel

[Buildroot] broken alsa-lib

[Peter Korsgaard]

>>>>> "Daniel" == Daniel Mack <daniel@caiaq.de> writes:

Hi,

 >> Alsa-lib had an issue with !LARGEFILE support that we fixed recently
 >> and pushed upstream, but other than that I don't remember any
 >> bugreports.

 Daniel> Hmm, what I see is certainly not a LARGEFILE issue.

Probably not, just mentioning the only bugs we've found in alsa lib
recently.

 >> You mentioned something about 1.0.19, but buildroot is still using
 >> 1.0.18, are you using some local changes?

 Daniel> Yes, true, forgot to mention that. We locally patched to use
 Daniel> 1.0.19 but that was merely because I hoped to fix the problem
 Daniel> by that - the same problem exists with 1.0.18. And I got this
 Daniel> problem since a long time and always patched my way around it
 Daniel> (by overriding the value with some hard-coded constant) as I
 Daniel> thought it is a minor issue that will be fixed sooner or
 Daniel> later. But as it turns out, the problem seems to be bigger
 Daniel> and might also have other impact than just that single
 Daniel> failing function call.

Please report those kind of problems to us so we have a chance to fix
them. This is the first I hear of it.

 Daniel> I'll build alsa-lib and alsa-utils with OE tomorrow and see
 Daniel> whether that makes any difference.

Great, Please send us the config.log from OE and BR if it works under
OE.

-- 
Bye, Peter Korsgaard

[Buildroot] broken alsa-lib

[Will Wagner]

Daniel Mack wrote:
> Hi,
> 
> as pointed out in two threads on the alsa-dev ML, there seems to be
> general problem with ALSA libraries built by buildroot:
> 
> 	http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/014999.html
> 	http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/015005.html
> 
> Any hints, anyone?

Not sure if this is the same as a problem I was seeing with alsa-lib. It was a while ago 
so not entirely sure. However I found my problem was to do with the complicated alsa 
versioning API meaning that the wrong version of the function was called. I fixed it by 
adding --with-versioned="no" to the alsa-lib configure (I also moved to 1.0.19 as that had 
a number of bug fixes for other things I needed).

Hope that helps,

Will

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] broken alsa-lib

[Peter Korsgaard]

>>>>> "Will" == Will Wagner <will_wagner@carallon.com> writes:

Hi,

 Will> Not sure if this is the same as a problem I was seeing with
 Will> alsa-lib. It was a while ago so not entirely sure. However I found my
 Will> problem was to do with the complicated alsa versioning API meaning
 Will> that the wrong version of the function was called. I fixed it by
 Will> adding --with-versioned="no" to the alsa-lib configure (I also moved
 Will> to 1.0.19 as that had a number of bug fixes for other things I
 Will> needed).

 Will> Hope that helps,

Care to send a patch for both?

-- 
Bye, Peter Korsgaard

[Buildroot] broken alsa-lib

[Daniel Mack]

On Mon, Feb 23, 2009 at 09:14:29AM +0000, Will Wagner wrote:
>> as pointed out in two threads on the alsa-dev ML, there seems to be
>> general problem with ALSA libraries built by buildroot:
>>
>> 	http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/014999.html
>> 	http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/015005.html
>>
>> Any hints, anyone?
>
> Not sure if this is the same as a problem I was seeing with alsa-lib. It 
> was a while ago so not entirely sure. However I found my problem was to 
> do with the complicated alsa versioning API meaning that the wrong 
> version of the function was called. I fixed it by adding 
> --with-versioned="no" to the alsa-lib configure (I also moved to 1.0.19 
> as that had a number of bug fixes for other things I needed).

Aha, that fixed it for me, too. Thanks :)

Daniel

[Buildroot] broken alsa-lib

[Will Wagner]

> 
> Care to send a patch for both?
> 

I will, might take me a while to get it into shape as we have made a number of changes.

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] broken alsa-lib

[Daniel Mack]

On Mon, Feb 23, 2009 at 10:22:34AM +0100, Peter Korsgaard wrote:
>  Will> Not sure if this is the same as a problem I was seeing with
>  Will> alsa-lib. It was a while ago so not entirely sure. However I found my
>  Will> problem was to do with the complicated alsa versioning API meaning
>  Will> that the wrong version of the function was called. I fixed it by
>  Will> adding --with-versioned="no" to the alsa-lib configure (I also moved
>  Will> to 1.0.19 as that had a number of bug fixes for other things I
>  Will> needed).
> 
>  Will> Hope that helps,
> 
> Care to send a patch for both?

We'd need to find out if the avr-inline patch is still needed for 1.0.19
or if that's been fixed upstream now. Apart from that, I rebased the
fix-ott_t-patch.

Can anyone with a AVR32 environment try to build and use 1.0.19 without
that patch?

Daniel

[Buildroot] broken alsa-lib

[Peter Korsgaard]

>>>>> "Will" == Will Wagner <will_wagner@carallon.com> writes:

 >> 
 >> Care to send a patch for both?
 >> 

 Will> I will, might take me a while to get it into shape as we have made a number of changes.

Ok, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] broken alsa-lib

[Peter Korsgaard]

>>>>> "Daniel" == Daniel Mack <daniel@caiaq.de> writes:

Hi,

 Daniel> We'd need to find out if the avr-inline patch is still needed
 Daniel> for 1.0.19 or if that's been fixed upstream now. Apart from
 Daniel> that, I rebased the fix-ott_t-patch.

That was afaik committed upstream - Didn't it make it for 1.0.19?

 Daniel> Can anyone with a AVR32 environment try to build and use
 Daniel> 1.0.19 without that patch?

Yes please.

-- 
Bye, Peter Korsgaard

[Buildroot] broken alsa-lib

[Will Wagner]

>  Daniel> We'd need to find out if the avr-inline patch is still needed
>  Daniel> for 1.0.19 or if that's been fixed upstream now. Apart from
>  Daniel> that, I rebased the fix-ott_t-patch.
> 
> That was afaik committed upstream - Didn't it make it for 1.0.19?
> 

I don't believe it made it for 1.0.19. I also submitted a couple of others things that 
waiting on 1.0.20
-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] broken alsa-lib

[Daniel Mack]

On Mon, Feb 23, 2009 at 09:44:24AM +0100, Peter Korsgaard wrote:
>  Daniel> Yes, true, forgot to mention that. We locally patched to use
>  Daniel> 1.0.19 but that was merely because I hoped to fix the problem
>  Daniel> by that - the same problem exists with 1.0.18. And I got this
>  Daniel> problem since a long time and always patched my way around it
>  Daniel> (by overriding the value with some hard-coded constant) as I
>  Daniel> thought it is a minor issue that will be fixed sooner or
>  Daniel> later. But as it turns out, the problem seems to be bigger
>  Daniel> and might also have other impact than just that single
>  Daniel> failing function call.
> 
> Please report those kind of problems to us so we have a chance to fix
> them. This is the first I hear of it.

I'm playing ping-pong between the two lists now, and over there they
pointed out that this was indeed reported quite a while ago:

	http://lists.busybox.net/pipermail/buildroot/2008-July/009884.html

Anyway, let's make sure to apply this patch asap :)

Daniel

[Buildroot] broken alsa-lib

[Peter Korsgaard]

>>>>> "Daniel" == Daniel Mack <daniel@caiaq.de> writes:

Hi,

 Daniel> I'm playing ping-pong between the two lists now, and over
 Daniel> there they pointed out that this was indeed reported quite a
 Daniel> while ago:

 Daniel> http://lists.busybox.net/pipermail/buildroot/2008-July/009884.html

Ahh, nothing happened to that mail as the submitter never replied to
Daniel Laird's mail.

 Daniel> Anyway, let's make sure to apply this patch asap :)

So what exactly needs to get committed? The --with-versioned=no is
easy, but should the:

ifeq ($(BR2_arm),y)
ALSA_LIB_CFLAGS+=-mabi=aapcs-linux
endif

Be in an EABI conditional?

-- 
Bye, Peter Korsgaard

[Buildroot] broken alsa-lib

[Daniel Mack]

On Mon, Feb 23, 2009 at 01:28:23PM +0100, Peter Korsgaard wrote:
>  Daniel> I'm playing ping-pong between the two lists now, and over
>  Daniel> there they pointed out that this was indeed reported quite a
>  Daniel> while ago:
> 
>  Daniel> http://lists.busybox.net/pipermail/buildroot/2008-July/009884.html
> 
> Ahh, nothing happened to that mail as the submitter never replied to
> Daniel Laird's mail.
> 
>  Daniel> Anyway, let's make sure to apply this patch asap :)
> 
> So what exactly needs to get committed? The --with-versioned=no is
> easy, but should the:

This one is certainly needed.

> ifeq ($(BR2_arm),y)
> ALSA_LIB_CFLAGS+=-mabi=aapcs-linux
> endif
> 
> Be in an EABI conditional?

I'm not aware of any ABI problem with that, so I can't say.

Daniel

[Buildroot] broken alsa-lib

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:

Hi,

 Peter> So what exactly needs to get committed? The --with-versioned=no is
 Peter> easy, but should the:

 Peter> ifeq ($(BR2_arm),y)
 Peter> ALSA_LIB_CFLAGS+=-mabi=aapcs-linux
 Peter> endif

 Peter> Be in an EABI conditional?

That hunk just seems wrong to me. We always add -mabi=<> on ARM, so
it's a noop on EABI, and who knows what happens on OABI?

Ulf, why did you add it in the first place?

-- 
Bye, Peter Korsgaard

[Buildroot] broken alsa-lib

[Daniel Mack]

On Sun, Mar 01, 2009 at 10:43:34AM +0100, Peter Korsgaard wrote:
>  Peter> So what exactly needs to get committed? The --with-versioned=no is
>  Peter> easy, but should the:
> 
>  Peter> ifeq ($(BR2_arm),y)
>  Peter> ALSA_LIB_CFLAGS+=-mabi=aapcs-linux
>  Peter> endif
> 
>  Peter> Be in an EABI conditional?
> 
> That hunk just seems wrong to me. We always add -mabi=<> on ARM, so
> it's a noop on EABI, and who knows what happens on OABI?

This one wasn't commited, right? With --with-versioned=no things are
fine now for EABI, but I don't know about the legacy case.

Thanks,
Daniel

[Buildroot] broken alsa-lib

[Peter Korsgaard]

>>>>> "Daniel" == Daniel Mack <daniel@caiaq.de> writes:

 >> That hunk just seems wrong to me. We always add -mabi=<> on ARM, so
 >> it's a noop on EABI, and who knows what happens on OABI?

 Daniel> This one wasn't commited, right? With --with-versioned=no things are
 Daniel> fine now for EABI, but I don't know about the legacy case.

No it wasn't committed. And yeah, it should be a noop with eabi as we
already add -mabi=aapcs-linux to CFLAGS for eabi builds, but it seems
very wrong for oabi builds.

-- 
Bye, Peter Korsgaard