[alsa-devel] snd_pcm_hw_params_get_period_size points to __old_ symbol
gineera at aspect135.co.uk
Mon Feb 23 12:52:39 CET 2009
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
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.
More information about the Alsa-devel