Thanks for that wild guess.
You were exactly right, it was failing when trying to initialise std::vector, and moving the global object into main() has fixed it.  I now have my application running in r1183 and can use the sound card.

I have now also got the Alsa sound library working in r1183.
Firstly buildroot needs to be compiled after making a small change in /package/alsa-lib and alsa-utils
change the config.in to read BR2_PACKAGE_ALSA_LIB or _UTILS in line 1

Then you'll find in ./gumstix-buildroot/build_arm_nofpu/staging_dir/usr/share/alsa all the required files.  Copy the whole alsa directory into the gumstix, into a directory with an identical path to the directory on you build environment

so in my case I created a dir /home/bt/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/usr/share/alsa on the gumstix and copied everything in. 

This needs to be fixed in the install path in the config files that come down from buildroot - any takers?

then,
modprobe snd-pxa2xx-ac97

run aplay -l and you should see your device.

I have still to actually record/play anything through the alsa driver but I think it should work.  You need to turn on the channels and unmute the volume in the amixer control.

If anyone manages to record and play something then please post the steps you take with the mixer etc.

Ben

-----Original Message-----
From: gumstix-users-bounces@lists.sourceforge.net on behalf of bearclaw
Sent: Tue 10/04/2007 09:58
To: General mailing list for gumstix users.
Subject: Re: [Gumstix-users] c++ and sound compatibility

Toner, Ben wrote:
>
> I've spent some time looking into the best buildroot release to use
> for my requirements
>  - sound capability
>  - c++ application
>
> My c++ application is a working linux application and I'm trying to
> port it to Gumstix.  With the later buildroots (1360+ ) the
> application builds and executes but fails when it comes to opening a
> sound device (as expected seeing as the sound is broken)
>
> Using buildroot 1183 where sound has been confirmed to work well, my
> application builds but execution stops almost immediately reporting a
> segmentation fault.  My application has a large global object and
> Strace and gdb both show the application to stop in the constructor
> for this object which makes debugging very difficult.  The only thing
> I can see that may be linked to the segmentation fault is that there
> templates to create a complex type are being called around the point
> where execution stops.
>
> I'm not sure what is causing this but a guess would be that my c++
> application will not execute having been built with gcc 3.4.5 (in
> builroot r1183).  Maybe this is something to do with the way c++
> templates are handled as I remember something about that changing
> around gcc 3.4.x?
> I have tried updating the gcc in buildroot 1183 (using make
> menuconfig) to a gcc 4.x version but then buildroot fails.
> Another issue could be to do with libstdc++?  Do the different
> buildroot versions use fixed releases of libstdc++ or is the latest
> stable version brought down regardless of the buildroot version?
>
> Are there any similar issues and workarounds known as it looks as
> though I have to either do some painful debugging/repairing in r1183
> or get the sound working in the latest releases.
>
> Is there something I could help with to get the sound working in the
> latest buildroot as this is my preferred solution.  I am by no means a
> kernel expert and have tried some novice tricks such as copying the
> sound from linux-2.6.18gum to linux-2.6.20gum but surprise surprise,
> that doesn't work.
> Any other suggestions about what I could do to get a solution moving?
>
> Thanks
>
> Ben
>
Hi. If your object is global and declared as 'Foo foo;' then it is
initilaized before main is called. This can cause trouble as the
initialization of global objects' order is undefined. For instance if
Foo's constructor is using a global std::list, this may fail if Foo is
initialized before the list.
I'd recommand replacing your object by a pointer, and initialize it in main.
That's just  a wild guess though, it may not be relevant to your problem.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users

--

Roke Manor Research Ltd, Romsey,
Hampshire, SO51 0ZN, United Kingdom

A Siemens company

Registered in England & Wales at:
Siemens House, Oldbury, Bracknell,
Berks RG12 8FZ. Number 267550

------------------------------------------------------------------------

Visit our website at www.roke.co.uk

------------------------------------------------------------------------

The information contained in this e-mail and any attachments is
proprietary to Roke Manor Research Ltd and must not be passed to any
third party without permission. This communication is for information
only and shall not create or change any contractual relationship.

------------------------------------------------------------------------

Please consider the environment before printing this email