Quote:
Originally Posted by xueyou2
I get it.
If you use other functions，just link the XX library?
Just like
tccmake myprog -lX (with the first letter?)
In tcc forums it said: can be linked to your program with the -l switch and the name of the lib without the leading word "lib".
For example time.h
tccmake myprog -lt ?
Another question :Can i replace the header file in tcc with the same file in gcc?
 |
Actually, a lot of the headers define "built in" functions that do not need additional linked libraries. But when the headers are for an additional loadable library module (not automatically linked), you need to do like the tcc forum said, which is -l followed by the library name (not including the "lib" prefix). It is the same for tcc and gcc. This is just a developer thing you need to learn by reading the man pages and other documentation.
The tcc and arm-linux-gcc headers (and in most cases host PC gcc headers) are interchangeable. In fact, as mentioned in the first post, I got them from the tinycc source archive AND from the codesourcery arm-linux-gcc include folder AND from the amazon gpl 5.0.0 source include files (but not all of the "buried" headers). In most cases the cross-tools are built from the same source code as the host PC build tools, so they would share the same headers (with differences depending on kernel and library versions that you need to watch for). That whole painful library version conflict thing that developers have to fight at various times is known on "other" platforms as "DLL Hell" and linux developers are not immune from that disease. 
In general, you can use either gcc or tcc, but gcc generates faster code (especially with the -O3 switch), whereas tcc actually compiles many times faster than gcc and runs in the kindle, so it is very nice for debugging sessions on the device.
I like to compile with gcc just before packaging up a release (or to see the effect of optimizations in my fast graphics code). For animation, programs compiled with tcc run the animation a lot slower than when compiled with gcc. For my video player, it does not matter that it runs slower, because the program spends most of its time sleeping, waiting for the next "vertical refresh" interval when eink updates are performed.
EDIT: One last thing, although I do not always do this, in many cases I like to add -static to my build command line for the final package, which loads all the libraries used on the build platform INSIDE the compiled executable. This makes it a lot bigger (not a problem because the USB drive is so large, and most of those libraries need to be in memory anyway when the program runs). But the important thing is that the program is then robust and will keep running on different platforms with different incompatible loadable libraries and different firmware versions (unless amazon breaks stuff in the OS and drivers like they did with the 5.1.0 update). In many cases, we can copy static-linked programs directly from an android device to a kindle and it runs fine -- try that with something dependent on specific loadable libraries (which may well be missing).
