All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.