[alsa-devel] snd_pcm_hw_params_get_period_size points to __old_ symbol

[Alan Horstmann]

On Sunday 22 February 2009 22:22, Daniel Mack wrote:
> On Sun, Feb 22, 2009 at 10:15:56PM +0000, Liam Girdwood wrote:
> > > With alsa-lib and alsa-utils cross-compiled for ARM by
> > > buildroot (currently version 1.0.19, but earlier versions
> > > seem to be equally affected), I encounter the effect that
> > > snd_pcm_hw_params_get_period_size() does not write the expected
> > > value to the given snd_pcm_uframes_t pointer. In fact, this
> > > variable is not written at all. This makes aplay calculate 0
> > > for chunk_bytes in set_params() and then exit with the bogus error
> > > message "Not enough memory". I did some tracing and found out that
> > > the function called for snd_pcm_hw_params_get_period_size() is in
> > > fact __old_snd_pcm_hw_params_get_period_size() which has a different
> > > footprint and hence the pointer given to it is leaved untouched.
> > >
> > > As I don't fully understand all the system behind the symbol names
> > > remapping, I'm stuck here. Can anybody reproduce this bug?
> >
> > AFAICT, buildroot builds a broken ALSA ARM userspace. I've had driver
> > bug reports from numerous users for about 2 years now due to buildoot
> > building a faulty ARM ALSA userspace. I've also asked each bug reporter
> > to report this to buildroot bugzilla. Seems it's not fixed yet.
>
> Interesting, thanks for pointing that out.
>
> > Please either build alsa-lib natively or with OpenEmbedded.
>
> This is rather unpracticable for us as we build the whole system with
> buildroot. Hence, I'd rather go and fix it. Any hint about what could
> possibily go wrong during the build phase which would explain that bug
> to happen? A missing/wrong define, bogus configure arguments?

Just thought I would chip in from the sidelines here; we have successfully 
built for ARM (AT91 though) using Buildroot.

Looking back to my posting on devel list dated 12.08.08, one problem was:

"We are currently using the Buildroot system which uses the uClibc libraries.  
 Simply, uClibc does not support versioned symbols.  Therefore it is necessary 
 to override the ALSA-lib default by adding
        --with-versioned=no
 to the build.  Aplay, Alsamixer etc run without problems.

 I think the gcc optimisation bug may be fixed on recent gcc versions; it 
 didn't in the end turn out to be causing us any problems.

 We also noticed that it would be easy to accidentally build kernel and libs 
 with different settings of -mabi, which would also cause problems. "

Just in case that is any help.

Alan