MobileRead Forums - View Single Post - Audio (video) - Kindle. Getting it up and running, Code level.

NiLuJe · 07-04-2012, 07:50 PM

@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

.

07-04-2012, 07:50 PM	#26
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	@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 . Last edited by NiLuJe; 07-04-2012 at 08:09 PM.