geekmaster's simple guide to tcc (tinycc)

[geekmaster]

Hmmm...

tccmake test -lpthread

Works on my 5.1.0 kindle. Perhaps this is is a "firmware flavor of the month" problem.

Now we just need to know which "flavor" of 5.1.0 that the OP has on his kindle. There are multiple know 5.1.0 firmware versions, all different but using the same firmware version numbers. Because they have different defects, we need a reliable way to identify them so we know when and how to apply our repairs.

[knc1]

Originally Posted by deep

Ok here's the output

I copied the file over to /mnt/us

and ran the command from my linux machine

/media/Kindle$ file ./libpthread.so
./libpthread.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0x245a6c47c401422afb251b0bb4d29e9e309404dc, for GNU/Linux 2.6.16, not stripped

Good move.
Now that you have a backup copy of it (be sure to keep it in case we break something). . . .

Do:

cd /usr/lib/
mv libpthread.so libpthread.so.bak
ln -s /lib/libpthread.so libpthread.so
cd -

And if all the multi-threaded applications on your KT break, reverse the above process to fix it.
Then we will just over-ride the library search path order in the compile command.
Hmm... Maybe that is what I should have described to begin with.

[geekmaster]

Originally Posted by deep

Ok ... so here's the output after I modified my install file as above

I also tried creating the symlink !

That fix I did is for firmware 3.3. I do not yet know how to fix the bug in the 5.1.0 firmware. My 5.1.0 does not have that problem. It helps to duplicate the problem before trying to fix it. ???

In earlier posts, you can see that another user had a problem with fw 3.3 using nested symlinks, even though they worked fine on my fw3.3. So perhaps there are multiple versions of 3.3 out there too...

[knc1]

Originally Posted by geekmaster

Hmmm...

tccmake test -lpthread

Works on my 5.1.0 kindle. Perhaps this is is a "firmware flavor of the month" problem.

Now we just need to know which "flavor" of 5.1.0 that the OP has on his kindle. There are multiple know 5.1.0 firmware versions, all different but using the same firmware version numbers. Because they have different defects, we need a reliable way to identify them so we know when and how to apply our repairs.

Note the output of the "file" command - it includes the sha1 build id of the library.
That should be pretty specific.

[deep]

Originally Posted by knc1

Good move.
Now that you have a backup copy of it (be sure to keep it in case we break something). . . .

Do:

cd /usr/lib/
mv pthread.so pthread.so.bak
ln -s /lib/pthread.so pthread.so
cd -

And if all the multi-threaded applications on your KT break, reverse the above process to fix it.
Then we will just over-ride the library search path order in the compile command.
Hmm... Maybe that is what I should have described to begin with.

It works kcn1

[knc1]

Originally Posted by deep

It works kcn1

Super! (en_IBM)
I will confir with GM off-line about how to solve these problems in general for v5.1.0.

[deep]

I did modify the pthread to libpthread in your post forgot to mention that !

[geekmaster]

I loop mounted another 5.1.0 image somebody sent me, and it appears that this is a library loader script problem just like for libc.

Try replacing your tccmake script contents with this:

#!/bin/sh
[[ -f /usr/lib/libc.so ]]&& mount -o bind /mnt/us/tcc/tcc.libc.so /usr/lib/libc.so
[[ -f /usr/lib/libpthread.so ]]&& mount -o bind /mnt/us/tcc/tcc.libpthread.so /usr/lib/libpthread.so
tcc -I/mnt/us/tcc/include -o $1 $2 $3 $4 $5 $6 $7 $8 $9 $1.c
[[ -f /usr/lib/libc.so ]]&& umount /usr/lib/libc.so
[[ -f /usr/lib/libpthread.so ]]&& umount /usr/lib/libpthread.so

Does that work for you?

EDIT: Bind mounts like I show above are MUCH safer than making changes to root that could break an OTA update (possibly bricking the kindle). Please UNDO the changes you made and try my script. It is the same problem as libc, so the fix shown above WILL work. Although the changes you made are fine for testing (if you allow for undoing them like knc1 suggested with the backup copy of the old file). Please undo your changes and do it the right way as I showed, to prevent bricking your kindle. Thanks. Also, I want confirmation that the CORRECT (bind mount) fix that I provided works as expected.

[knc1]

Originally Posted by deep

I did modify the pthread to libpthread in your post forgot to mention that !

Nice catch. I'll edit my post so the next reader doesn't get lost.
If you would please edit your post, where you quoted my typo - the world will be a better place for the KT.

[deep]

Originally Posted by geekmaster

I loop mounted another 5.1.0 image somebody sent me, and it appears that this is a library loader script problem just like for libc.

Try replacing your tccmake script contents with this:

#!/bin/sh
[[ -f /usr/lib/libc.so ]]&& mount -o bind /mnt/us/tcc/tcc.libc.so /usr/lib/libc.so
[[ -f /usr/lib/libpthread.so ]]&& mount -o bind /mnt/us/tcc/tcc.libpthread.so /usr/lib/libpthread.so
tcc -I/mnt/us/tcc/include -o $1 $2 $3 $4 $5 $6 $7 $8 $9 $1.c
[[ -f /usr/lib/libc.so ]]&& umount /usr/lib/libc.so
[[ -f /usr/lib/libpthread.so ]]&& umount /usr/lib/libpthread.so

Does that work for you?

EDIT: Bind mounts like I show above are MUCH safer than making changes to root that could break an OTA update (possibly bricking the kindle).

Hmm the above method of completely replacing the libpthread.so file actually solved the problem

Thanks geekmaster ... Your method works without modifying the actual library files

[knc1]

So now we know two ways to fix it, well, three - we could have just used -L option to tcc.
I will look into that "too small" file and see if I can figure out what lab126 was smoking.

[geekmaster]

Originally Posted by deep

Hmm the above method of completely replacing the libpthread.so file actually solved the problem

Thanks geekmaster ... Your method works without modifying the actual library files

The replacement is a copy of the original library loader script file with the extra "crap" removed from it.

It is a text file (even though it has a ".so" file extension). You can cat (or vi) the original and my replacement to see how I changed it (and the libc loader script). We may need to do this for other libraries too as they get reported.

Perhaps I need a "smart" install script that parses the libraries and creates replacement library loader scripts, and adds their bind mounts to the tccmake script.

P.S. You can thank NiLuJe for teaching me the "bind mount" trick.

[geekmaster]

The problem is that tcc can only parse simple library loader scripts, and firmware 5.1.0 added extra crap to them that breaks when tcc tries to link to them.

So 5.1.0 is not only "anti-hacker", but it is also "anti-tcc" (but only enough to slow us down a little)...

[deep]

Originally Posted by geekmaster

The problem is that tcc can only parse simple library loader scripts, and firmware 5.1.0 added extra crap to them that breaks when tcc tries to link to them.

So 5.1.0 is not only "anti-hacker", but it is also "anti-tcc" (but only enough to slow us down a little)...

Just a note !

The version of /lib/libpthread.so actually worked for me ... so I copied it over to the tcc folder as required by your modified script...

[geekmaster]

Originally Posted by deep

Just a note !

The version of /lib/libpthread.so actually worked for me ... so I copied it over to the tcc folder as required by your modified script...

Ahh... I forgot to post the contents of my replacement loader script. Here is the one-line contents of my /mnt/us/tcc/tcc.libpthread.so:

GROUP ( /lib/libpthread.so.0 )

Are you saying that the original loader script works if copied to the tcc folder? That does not make sense to me because the original contains the file reference shown in the tcc error message. It would be nice to know how many different versions of 5.1.0 firmware are out in the wild. How can amazon even support this mess?

EDIT: It looks like JoppyFur and others did not have this problem. Only SOME versions of the 5.1.0 firmware have this problem.