Help with cross-compiling tools?

[icantbebothered]

Originally Posted by twobob

one more thing... the busybox dd does NOT support these append modes...

Here is one that does. Enjoy.

Um,

[root@kindle /]dd if=/dev/zero bs=1M count=512 >> /mnt/us/debian.ext3

blah blah blah bytes copied in so many seconds.
Woot.

[twobob]

um,

"you should also specify ‘conv=notrunc’ unless you want the output file to be truncated before being appended to"

yeah...

but okay okay I get your point :P Since the file should not actually BE MOUNTED at that point... that should be safe.


EDIT: Updated ma post to reflect your wise observation.

[brianinmaine]

Originally Posted by twobob

build stuff like:

root@kindle:/# ./configure --prefix=/mnt/us/extensions/{thing}/usr <other options>

root@kindle:/# make clean; PATH=/usr/lib/ccache:$PATH make ; make install

Hope that helps.

So far I am unsucessful at building the few packages I tried. I am still trying Navit, the map/gps program, but even with the instructions on here to build it, I can't get it to work. So after 8 hours or so of trying, I tried something else.

I tried to compile Midnight Commander. I know there is a version on here:
https://www.mobileread.com/forums/sho...3&postcount=24

but I wanted to try it myself, maybe with sftp (not in the other one). This is the error I get:

./mc: error while loading shared libraries: invalid mode for dlopen(): Invalid argument

which leads me to believe (from google searches) that it is a problem of different glib versions??? How to I link to the libraries on the native Kindle, not the one in the image?

I'm sure this is a complete newbie error, I just can't seem to get it?

[twobob]

hmm... are you still using that SID version of dos1's?

or the wheezy seed I posted?

[knc1]

Originally Posted by brianinmaine

but I wanted to try it myself, maybe with sftp (not in the other one). This is the error I get:

./mc: error while loading shared libraries: invalid mode for dlopen(): Invalid argument

Which leads me to believe (from google searches) that it is a problem of different glib versions???

How to I link to the libraries on the native Kindle, not the one in the image?

A little bit more can be told from that runtime error message.

dlopen() is implemented in libdl (yeah, that one is easy, some are much harder to find).

The libdl header files imported during the build had to match what was expected in the mc code, or it would not have built.
But it did build, it just doesn't run.

Now those parts of the messages that look informative?
Ah, those things are not standardized, so it is best to confirm what is happening by some means other than the message text.

Use the strace utility on mc when you run it next time - - -
That will show what is being passed and in what format.

(Of course, take hints from the error messages, look first to see what is being passed to the dlopen's mode argument.)

If you are doing this inside of twobob's chroot image -
I am pretty sure he did not strip out the manual and info documents (we only talked about stripping out some backup files) -
So the 'man' command should work for all of the above inside the chroot.

[brianinmaine]

Originally Posted by knc1

Use the strace utility on mc when you run it next time - - -
That will show what is being passed and in what format.

(Of course, take hints from the error messages, look first to see what is being passed to the dlopen's mode argument.)

Thank you so much for your help! I am learning so much!

error portion of the outside_chroot log:

User:/tmp/framework:/bin/sh\n", 1024) = 429
close(3) = 0
munmap(0x4001e000, 4096) = 0
mkdir("/tmp/mc-root", 0700) = -1 EEXIST (File exists)
lstat64("/tmp/mc-root", {st_mode=S_IFDIR|0700, st_size=40, ...}) = 0
getuid32() = 0
stat64("libX11.so", {st_mode=S_IFREG|0755, st_size=1126040, ...}) = 0
futex(0x404810a0, 0x81 /* FUTEX_??? */, 2147483647) = 0
writev(2, [{"./mc", 4}, {": ", 2}, {"error while loading shared libraries", 36}, {": ", 2}, {"", 0}, {"", 0}, {"invalid mode for dlopen()", 25}, {": ", 2}, {"Invalid argument", 16}, {"\n", 1}], 10) = 88
exit_group(127) = ?

I don't see what file it is trying to write to? I tried copying libX11 (so it could find it), it's on fat32 so it should be able to be opened for reading, mode 755, right? why would this not work?

I can run mc that I built inside the chroot just fine. I'm using the image twobob posted above, resized to 2Gb, on the Kindle, the latest version:
http://ftp.midnight-commander.org/mc-4.8.10.tar.bz2

I compiled it with the prefix twobob uses above (/mnt/us/extensions/mc) and added flags to not build the documentation. I might rebuild it later if I can get it to work! I exported the whole deal outside the chroot, and specify LD_LIBRARY_PATH=../lib:$LD_LIBRARY_PATH ./mc on the command line.

Any more help would be GREATLY appreciated!

PS: congrats on the 5000 post barrier, knc1!

[knc1]

The program does find and open libdl (for the function dlopen() )

open("../lib/libdl.so.2", O_RDONLY)     = 3

Much, much earlier than the fragment you posted.

Sorry, I don't see anything more than the error messages we saw earlier.

Have run out of guesses.

[brianinmaine]

Originally Posted by knc1

The program does find and open libdl (for the function dlopen() )

open("../lib/libdl.so.2", O_RDONLY)     = 3

Much, much earlier than the fragment you posted.

Sorry, I don't see anything more than the error messages we saw earlier.

Have run out of guesses.

Oh, well. Maybe I'll try it again in a while. I'd like to get SOMETHING to work this way, just so I know I'm doing it right! Maybe I'll try something else.

Thank you again, knc1!

[twobob]

hmm... yeah... interesting.

arm-linux-gnueabi/libdl.so.2 huh...
I'll have a play in a bit.

hmm... you know... have you tried the scripty wangle?


cd thing/bin
/lib/ld-linux.so.3 --library-path $PWD/../lib ./thing (or w/e the relative path)

Sounds like that is a libc thing maybe?
chuck me a binary?

[NiLuJe]

Keep in mind that trying to load a library built for the wrong architecture is known to trigger all kinds of weird and helpful (not) errors .

(That's a wild guess, but given the initial subject, maybe not that far off target ).

[twobob]

okay so I worked through your example....

here's what I did

downloaded your codebase
loaded/mounted debian
shoved the code in /usr/local/src/mc-4.8.10
(well /mnt/us/debian/usr/local/src/mc-4.8.10 as viewed externally )


get the stuff we need to build this lot
apt-get build-dep mc

configure it (keep it simple) / make it / install it
./configure --prefix=/mnt/us/extensions/mc/usr
make; make install


then copy everything from the resulting /mnt/us/debian/mnt/us/extensions/mc to /mnt/us/extensions/mc

tidy up the missing libs:
cd /mnt/us/extensions/mc
cp /mnt/us/debian/usr/lib/arm-linux-gnueabi/libgpm.so.2 usr/lib/
cp /mnt/us/debian/lib/arm-linux-gnueabi/libslang.so.2 usr/lib/

make a run script...

(let's read it)
cat /mnt/us/extensions/mc/mc

#!/bin/sh
LD_LIBRARY_PATH=/mnt/us/extensions/mc/usr/lib:/usr/lib:/lib  /mnt/us/extensions/mc/usr/bin/mc

now run that...

(attached)

Hope that helps.

[brianinmaine]

NO FAIR I just knew I was doing something simple wrong. I'll try it again. I just don't get all this shared library stuff from different systems...

Aside from this,
Is there a way to use the kindle libraries to compile against? I tar.gzipped them and and put them anywhere. I uncompressed to /kindle/lib and /kindle/usr/lib. Is there some compile setting or something?

Also, I have used sshfs before, not for a chroot though. Could you share your script 'remote-debian' or whatever from that other thread?

[twobob]

the remote-debian thing was a "bad idea" in terms of compilation.

it runs things just fine but extremely heavy traffic (caused by compilation) can lock up the device sadly

in terms of the libs... drop them in your toolchains include folder.

[NiLuJe]

@brianinmaine: Wanting to link against "the Kindle's libraries" is a good idea in theory, but in practice, the libraries (at link-time) don't dictate much, the headers do, and amazon doesn't ship headers in their FW (not unlike a binary Linux distro, which is why you have a -dev/-devel package for each package) .

So, if you *really* want to link against the same stuff, you'll need to replicate the Kindle sysroot *with* the development files (the headers). (ie. cross-compile the exact same versions of what you care about as the device you target).

Fortunately for us, we can get away with building against newer/older stuff, as long as we're building against something that is ABI compatible with what the Kindle runs. That's where API/ABI, sover & symbol versionning come into play, and you start to dig into the inner workings of the ELF binary format.

[twobob]

and for the headers... I use buildroot to spit out some and then splatter them either in my TC includes or just link them with the -I/location flag.

notable exception is the eink header - but that is certainly available from various places too.