Audio (video) - Kindle. Getting it up and running, Code level.

[twobob]

THIS ENTIRE PAGE IS ABOUT GETTING X-COMILERS TO WORK (OR NOT) GO TO PAGE 3 FOR MORE AUDIO TIPS

Originally Posted by geekmaster

Ahh.. so they ACCIDENTALLY begain obfuscating the JVM code starting with 5.1.x? Or are you implying that they made an incompetent decision to do that?

I think he's referring to the bulk rather than the specific.

[twobob]

Originally Posted by knc1

There is a project here:
https://www.mobileread.com/forums/sho...d.php?t=174066
that stalled over problems with the Kindle alsa implementation.

Most of my problems appear to revolve around failed support for the multilib implementation on my OS.

Sigh. May just build a 32 build OS and get on with the job.

[knc1]

Originally Posted by twobob

Most of my problems appear to revolve around failed support for the multilib implementation on my OS.

Sigh. May just build a 32 build OS and get on with the job.

Similar situation here with cross-building anything 32-bit from 64-bit systems.
Finally gave up and added a 32-bit system to the clutter of installed "stuff".
Nice that Linux makes "multi-boot" so easy. There should be a 32-bit Slackware out there.

Things were getting confusing here, so I finally added in different "default" window managers to the different systems so I would be reminded of what I was using at any moment.

[twobob]

EDIT: THIS SECTION IS ABOUT GETTING KDEVELOP CROSS COMPILING
WHICH NEVER WORKED: I GOT NEW TOOLS FROM THE KEK PROJECT
FEEL FREE TO SKIP OVER THESE POSTS TO THE SOUND INFO

I really am at a loss how in to include my cross-compiled alsa-libs to the CodeSourcery Gcc.

Spoiler:

arm-none-linux-gnueabi-gcc salsa.c -o arm-alsa -B/home/simon/CodeSourcery
/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/alsa -L/home/simon/CodeSourcery \
/Sourcery_Codebence_Lite_for_ARM_GNU_Linux/lib/alsa -B/home/simon/CodeSourcery \
/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib -B/home/simon/CodeSourcery \
/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux -lasound

seems to cover all eventualities for actually finding the libs. perhaps I need to run libran or something? Meh. Any clues to this noob would be great. Of course this could all simply be to do with the fact that the vast majority of stuff just does not want to "work" out of the box on my current OS config. Sigh

Anyways if someone could just confirm that I am indeed referencing the -lasound and it's location(s), correctly that would be great. Googling didn't help as I seem to get conflicting answers and nothing specific to my issue. many thanks.
EDIT: I NEVER GOT THIS WORKING UNDER KDEVELOP.
I GOT NEW TOOLS FROM THE KEK PROJECT

RESULT:

Spoiler:

bash-4.1$ arm-none-linux-gnueabi-gcc alsawave.c -o arm-alsa -B/home/simon\
/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/alsa -L/home/simon\
/CodeSourcery/Sourcery_Codebence_Lite_for_ARM_GNU_Linux/lib/alsa -B/home/simon\
/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib -B/home/simon/CodeSourcery\
/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux -lasound                
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_dmix.o): In function `snd_pcm_dmix_sync_ptr':
pcm_dmix.c:(.text+0x245c): warning: Warning: snd_pcm_hwsync() is deprecated, consider to use snd_pcm_avail()
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_ioplug.o): In function `gettimestamp':
pcm_ioplug.c:(.text+0x258): undefined reference to `clock_gettime'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_dmix.o): In function `gettimestamp':
pcm_dmix.c:(.text+0x2e4): undefined reference to `clock_gettime'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(dlmisc.o): In function `snd_dlopen':
dlmisc.c:(.text+0x124): undefined reference to `dlopen'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(dlmisc.o): In function `snd_dlclose':
dlmisc.c:(.text+0x168): undefined reference to `dlclose'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(dlmisc.o): In function `snd_dlsym_verify':
dlmisc.c:(.text+0x244): undefined reference to `dlsym'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(dlmisc.o): In function `snd_dlsym':
dlmisc.c:(.text+0x37c): undefined reference to `dlsym'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_meter.o): In function `snd_pcm_meter_update_main':
pcm_meter.c:(.text+0x3b8): undefined reference to `pthread_mutex_trylock'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_meter.o): In function `snd_pcm_meter_hw_params':
pcm_meter.c:(.text+0x1560): undefined reference to `pthread_create'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_meter.o): In function `snd_pcm_meter_hw_free':
pcm_meter.c:(.text+0x162c): undefined reference to `pthread_join'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_meter.o): In function `snd_pcm_meter_add_scope_conf':
pcm_meter.c:(.text+0x1d58): undefined reference to `dlsym'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_rate.o): In function `gettimestamp':
pcm_rate.c:(.text+0x9c0): undefined reference to `clock_gettime'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_dsnoop.o): In function `gettimestamp':
pcm_dsnoop.c:(.text+0x16c): undefined reference to `clock_gettime'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_softvol.o): In function `softvol_load_control':
pcm_softvol.c:(.text+0x2f54): undefined reference to `pow'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_ladspa.o): In function `snd_pcm_ladspa_free_plugins':
pcm_ladspa.c:(.text+0x5b4): undefined reference to `dlclose'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_ladspa.o): In function `snd_pcm_ladspa_get_default_cvalue':
pcm_ladspa.c:(.text+0x1810): undefined reference to `log'
pcm_ladspa.c:(.text+0x1880): undefined reference to `log'
pcm_ladspa.c:(.text+0x18c8): undefined reference to `exp'
pcm_ladspa.c:(.text+0x1a50): undefined reference to `sqrt'
pcm_ladspa.c:(.text+0x1b3c): undefined reference to `log'
pcm_ladspa.c:(.text+0x1bac): undefined reference to `log'
pcm_ladspa.c:(.text+0x1bf4): undefined reference to `exp'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_ladspa.o): In function `snd_pcm_ladspa_check_file':
pcm_ladspa.c:(.text+0x3d7c): undefined reference to `dlopen'
pcm_ladspa.c:(.text+0x3d9c): undefined reference to `dlsym'
pcm_ladspa.c:(.text+0x3e04): undefined reference to `dlclose'
pcm_ladspa.c:(.text+0x3ef4): undefined reference to `dlclose'
pcm_ladspa.c:(.text+0x3f54): undefined reference to `dlclose'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_hw.o): In function `snd1_pcm_hw_open_fd':
pcm_hw.c:(.text+0x335c): undefined reference to `clock_gettime'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_file.o): In function `snd_pcm_file_open':
pcm_file.c:(.text+0x214c): undefined reference to `clock_gettime'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_route.o): In function `snd_pcm_route_convert1_many':
pcm_route.c:(.text+0x3048): undefined reference to `rint'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_share.o): In function `gettimestamp':
pcm_share.c:(.text+0x44c): undefined reference to `clock_gettime'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_share.o): In function `snd_pcm_share_close':
pcm_share.c:(.text+0x353c): undefined reference to `pthread_join'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_share.o): In function `snd_pcm_share_open':
pcm_share.c:(.text+0x3e84): undefined reference to `pthread_create'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_dshare.o): In function `gettimestamp':
pcm_dshare.c:(.text+0x1a4): undefined reference to `clock_gettime'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_generic.o): In function `gettimestamp':
pcm_generic.c:(.text+0x64): undefined reference to `clock_gettime'
/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_null.o): In function `gettimestamp':
pcm_null.c:(.text+0x28): undefined reference to `clock_gettime'
collect2: ld returned 1 exit status

Which doesn't really tell me a lot; other than guesses: incompatible library revisions? object not found? Paths incorrectly specified ? I'm at a loss. which is a shame as I am at a place where I can now deliver random bytes to the dsp via alsa on my local installation and would very much like to get it to compile to check if it works on the kindle.

It's basically just an alsa-test configured correctly for the kindle. Any takers on either a) helping me to get the file to compile. or b) compiling it for me would be great.

I don't suppose trying the -lasound option in tcc would hurt if anyone can direct me how to get the libraries from tcc/includes/sound included that would also be great

[root@kindle tcc]# tccmake -lasound -B/mnt/us/tcc -B/mnt/us/tcc/include/sound -B/mnt/us/tcc/include/ ./salsa.c doesn't appear to cut it...

In file included from ./salsa.c:19:
./include/sound/asoundlib.h:42: include file 'asoundef.h' not found

('asoundef.h' is indeed there)

apologies for the sprawling nature of the post.

[knc1]

Tells what is wrong.
The compiler can't find the header files, at least in the big code post.

One or two questions:
Did you build the "missing" library yourself?
If so;
What did you use for the --prefix= path to configure? The proper path so that "make install" would install **both** the library and the header files to the Cs toolchain location?
Did you include any DESTDIR= environment variable while doing "make install"

Duh,,,
Too many ways this might have gotten to this state to give a winning answer on the first reply.

[twobob]

EDIT: THIS SECTION IS ABOUT GETTING KDEVELOP CROSS COMPILING
WHICH NEVER WORKED: I GOT NEW TOOLS FROM THE KEK PROJECT
FEEL FREE TO SKIP OVER THESE POSTS TO THE SOUND INFO

Originally Posted by knc1

Tells what is wrong.
The compiler can't find the header files, at least in the big code post.
Duh,,,
Too many ways this might have gotten to this state to give a winning answer on the first reply.

Indeed yes. Headers not there.

If so;
What did you use for the --prefix= path to configure? The proper path so that "make install" would install **both** the library and the header files to the Cs toolchain location?

Yep myself. yep I gave it the fully qualified path the Toolchain via prefix like /PATH/TO/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux

Did you include any DESTDIR= environment variable while doing "make install"

do you know I think I did not, From my reading of the documents this was interchangeable with prefix-blah

WHAT HAPPENED:

Spoiler:

I should document this more thoroughly the next time.

The intial compilation went okay after a few python snags built fine. made dep and made fine,

installed fine.

oddly on the BIG post (host) the line

/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/lib/libasound.a(pcm_dmix.o): In function `snd_pcm_dmix_sync_ptr':
pcm_dmix.c:(.text+0x245c): warning: Warning: snd_pcm_hwsync() is deprecated, consider to use snd_pcm_avail()

to me implied it had found the first file at least...

and then in the second attempt actually on the kindle device:

significantly it is complaining about a file in a subfolder of the main folder and it says it cant find file "blah" from inside the already located other file from that series?

so did it find the first file again and fail to file the others?

odd I thought, such a similar error on two completely different environments.
I feel like that should tell me something.

Thanks for some feedback. at least I could answer the questions coherently so I do I have some understanding of the process. Even if none if the answers. other questions gratefully accepted. erm. not at the harm of other projects please though.
thanks

I am certain this will be user error

[knc1]

Add the option -v to your gcc options, capture the output, check what the include and library search paths are that the compiler is trying to use.
Pick any small file (hello.c ?) otherwise you'll be overwhelmed by the output.

My thoughts here are . . .
That compiler is location independent, so it must have a sysroot= defined in its configuration and that may be messing with the "normal" (what a person expects) search order.

[twobob]

EDIT: I NEVER GOT THIS WORKING UNDER KDEVELOP.
I GOT NEW TOOLS FROM THE KEK PROJECT

Spoiler:

Originally Posted by knc1

Add the option -v to your gcc options, capture the output, check what the include and library search paths are that the compiler is trying to use.

My thoughts here are . . .
That compiler is location independent, so it must have a sysroot= defined in its configuration and that may be messing with the "normal" (what a person expects) search order.

Yep. It's codeSourcery. My thoughts also hence the ridiculous /B ing and /L ing
So... I guess it's back to the docs again.

Pick any small file (hello.c ?) otherwise you'll be overwhelmed by the output.

Good advice but the program IS the HelloWorld of the Audio Realm. With a lib

Thanks knc1!

--prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/scratch/nsidwell/arm/linux/install/arm-none-linux-gnueabi/libc

hmm... opt.. hmm

[twobob]

perhaps I mis-understood where to install the libs?
Sigh

I'm an audio guy. who does code. not the other way round. sadly. but I'm trying.

probably the patience of saints

[knc1]

Originally Posted by twobob

perhaps I mis-understood where to install the libs?
Sigh

I'm an audio guy. who does code. not the other way round. sadly. but I'm trying.

probably the patience of saints

Ask the administrator of your system to let you open the CS tarball in /opt.
Oh, wait, the admin is yourself.
Well, go yell at the image in the mirror.

You might not be the only one -
There have been about 80 downloads of the archives, but only 7 downloads of the "getting started" (directions) guide.

[NiLuJe]

@twobob: Not sure what happened after #19, but here's what it's telling you:

You're trying to link against a library that depends on other libraries. Except you're linking statically, and there's no dependency tracking for static libraries [if you forget libtool and its horrible .la files], so you *need* to have them passed to your compiler/linker *in the right order*.

Let's say hello.c depends on libasound. libasound depends on libm, libdl, libpthread. You'll need to do something like

gcc -c hello.c -o hello -lasound -lpthread -ldl -lm

(Keep the *in the right order* thing in mind, AFAIR, libdl/lm/libpthread are more or less standalone, usually, but let's say libm depends on libdl, you'd have to do -lm -ldl, not the other way around).

It's explained in more details somewhere in the GCC manual, but it can be a bit tricky. (Usually, autotools (or any other proper, real buildsystem) takes care of it, but for small Makefile only projects, you may need to get your hands dirty).

(ELF) Static linking is *FUN*

EDIT: And, yeah, of course you do need to set the proper searchpaths for headers & libs, using the proper env vars:

-I/custom/path/include in CPPFLAGS for the headers
-L/custom/path/lib in LDFLAGS for the libs

(I've never had to play with -B)

(You may need to just squish everything into CFLAGS for some broken buildsystems)

EDIT²: Granted, knowing more or less to which library the undefined symbols belong to helps a bit. If you're not sure, a man/man 3 on the symbol name usually helps .

From what I gather from your logs, you need at least libm, librt, libdl and libpthread

EDIT^3: I saw a few mentions of configure/prefix. When using autotools, the prefix you pass is more or less the destination directory (it'll in fact be used to set DESTDIR). On a native system, it's usually /usr or /usr/local or /opt. When crosscompiling, you'll probably want to set it to a staging sysroot to keep things clean. Don't forget to pass the right toolchain triplet (apparently arm-none-linux-gnueabi in your case) to --host to use the proper toolchain .

[knc1]

Originally Posted by NiLuJe

@twobob: Not sure what happened after #19, but here's what it's telling you:

You're trying to link against a library that depends on other libraries. Except you're linking statically, and there's no dependency tracking for static libraries [if you forget libtool and its horrible .la files], so you *need* to have them passed to your compiler/linker *in the right order*.

Let's say hello.c depends on libasound. libasound depends on libm, libdl, libpthread. You'll need to do something like

gcc -c hello.c -o hello -lasound -lpthread -ldl -lm

(Keep the *in the right order* thing in mind, AFAIR, libdl/lm/libpthread are more or less standalone, usually, but let's say libm depends on libdl, you'd have to do -lm -ldl, not the other way around).

It's explained in more details somewhere in the GCC manual, but it can be a bit tricky. (Usually, autotools (or any other proper, real buildsystem) takes care of it, but for small Makefile only projects, you may need to get your hands dirty).

(ELF) Static linking is *FUN*

EDIT: And, yeah, of course you do need to set the proper searchpaths for headers & libs, using the proper env vars:

-I/custom/path/include in CPPFLAGS for the headers
-L/custom/path/lib in LDFLAGS for the libs

(I've never had to play with -B)

(You may need to just squish everything into CFLAGS for some broken buildsystems)

EDIT²: Granted, knowing more or less to which library the undefined symbols belong to helps a bit. If you're not sure, a man/man 3 on the symbol name usually helps .

From what I gather from your logs, you need at least libm, librt, libdl and libpthread

EDIT^3: I saw a few mentions of configure/prefix. When using autotools, the prefix you pass is more or less the destination directory (it'll in fact be used to set DESTDIR). On a native system, it's usually /usr or /usr/local or /opt. When crosscompiling, you'll probably want to set it to a staging sysroot to keep things clean. Don't forget to pass the right toolchain triplet (apparently arm-none-linux-gnueabi in your case) to --host to use the proper toolchain .

another choice is the use the start-group, end-group notation for the libraries. That way the linker will do multiple passes over the group rather than a single pass. Saves a lot of the "proper order" hassles.
The above "start-group and end-group" is probably not the proper option names, just what they do in English. You'll need to look the proper option names up.

Also, don't forget the trailing '-' on the arm-none-linux-gnueabi when setting the CROSS_COMPILE (or whatever the proper name is) variable.

Sorry for being so inexact, its been an 18 hour work day here.

[NiLuJe]

Yep, although not every package out there obey the CROSS_COMPILE env var (busybox & openssl do, among others), but when they do, and that's usually because they have a custom buildsystem, they expect the extra dash, unlike autotools --host, true .

[twobob]

Thanks boys. I still can't get Kdevelop to swallow it, but I took another tack and simply downloaded the Kek provided version of Eclipse and configured it all again.

Compiles not a problem on the host. Further tests ongoing.
Yay for Kek.

[knc1]

Originally Posted by twobob

Thanks boys. I still can't get Kdevelop to swallow it, but I took another tack and simply downloaded the Kek provided version of Eclipse and configured it all again.

Compiles not a problem on the host. Further tests ongoing.
Yay for Kek.

Thanks.
That is what my intent is - one-stop-shopping for development stuff that "just works".

Well, as close to: "just works" as one can reasonable expect in the world of complex, cross-system, program development.

The last K does mean "Kit" - I.E: user must supply the tweaks.