From: Peter Korsgaard <jacmet@uclibc.org>
To: buildroot@busybox.net
Subject: [Buildroot] alsa lib problem
Date: Tue, 27 Jan 2009 06:49:51 +0100 [thread overview]
Message-ID: <87ocxt2t8g.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <497E0B14.8040801@carallon.com> (Will Wagner's message of "Mon\, 26 Jan 2009 19\:12\:20 +0000")
>>>>> "Will" == Will Wagner <will_wagner@carallon.com> writes:
Hi,
Will> The definition in asound.h is:
Will> struct sndrv_pcm_channel_info {
Will> unsigned int channel;
Will> off_t offset; /* mmap offset */
Will> unsigned int first; /* offset to first sample in bits */
Will> unsigned int step; /* samples distance in bits */
Will> };
Will> The problem is that when compiling linux it thinks off_t is 4
Will> bytes but it appears that when compiling alsa-lib it thought it
Will> was 8 bytes. I assume this is because something in the
Will> toolchain on the host PC or the alsa-lib build is wrong and it
Will> is picking up a define from outside buildroot.
It looks to me like a largefile problem, E.G:
cat test.c
#include <stdio.h>
#include <sys/types.h>
int main(int argc, char **argv)
{
printf("%d\n", sizeof(off_t));
return 0;
}
arm-linux-gcc -static -o test test.c && qemu-arm ./test
4
arm-linux-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -static -o test test.c && qemu-arm ./test
8
We unconditinally add the largefile stuff to TARGET_CFLAGS, which
apparently isn't a good idea for alsa.
If the kernel interface is always with an 32bit offset, then asound.h
should probably be changed to use a 32bit data type instead. Could you
try changing it to an unsigned int and recompile?
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2009-01-27 5:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-26 19:12 [Buildroot] alsa lib problem Will Wagner
2009-01-27 5:49 ` Peter Korsgaard [this message]
2009-01-27 12:32 ` Will Wagner
2009-01-27 12:44 ` Hans-Christian Egtvedt
2009-01-27 12:47 ` Will Wagner
2009-01-27 12:56 ` Peter Korsgaard
2009-01-27 12:45 ` Peter Korsgaard
2009-01-28 15:34 ` Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ocxt2t8g.fsf@macbook.be.48ers.dk \
--to=jacmet@uclibc.org \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.