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