Well, as an introduction to topic, you could read the following entry:
http://xdaforums.com/showthread.php?t=1296186
So far, when using "-static" directive for compiler, the applications could be compiled without doing of these steps, so why do I try this? Well, a statically linked executable is embedding all the required libraries to itself, so it's generally too huge. Also, if you compile all the applications statically, you probably link the same library (like C library, for instance) twice or more for every application you compile. This is definitely unnecessary.
It's why, for a few days now, I'm trying to compile the whole GlibC suite for Android (ARM devices, to be precise). The motive behind it is simple: since all Linux applications rely on full-fledged C library (rather than trimmed version like Bionic), if I compile it for this device, I can run every application; given that its compiled for the device.
Since it's Linux kernel underneath, we don't have to worry about changing whole system from Android to native Linux (hopefully )
So far what I did was following (I'm going to write the steps more systematically once I've time, so don't worry if those steps are too vague for you ):
1- Make a toolchain for ARMv7 architecture (which Desire CPU rely on). You can use crosstool-ng etc. or (if you're masochistic enough ) try to make your own.
2- Compile GlibC with this new toolchain of yours, store the compiled libraries in a folder where you can easily access (I keep mine at Desktop/glibc-arm for instance)
3- Edit Ramdisk of the Kernel. To do this, first you must extract the boot.img; then extract the ramdisk, edit init.rc to accordingly, so the libraries can be searched in a folder other than /system/lib (say, /data/lib). You can tweak PATH env-variable while you're at it as well . This is necessary because /system partition isn't big enough to carry all GlibC lib in it, so we can copy the library to some other folder (like /data/lib) and then make the system search for libraries there as well. The point is, since I'm using Data2ext; my data is large enough for this. I'd recommend the same to you if you're willing to go on this road.
After the editing of init.rc, reconstruct ramdisk; make a boot.img with it and flash it to the device.
4- Copy the libraries to the folder of you picked.
5- Compile some test apps (like Hello world etc ) with your cross compiler and place them to your device as well.
6- Test if they're running.
What I've found so far, the cross compiled executable (like simple Hello world), when dynamically linked, gives "no such file or directory" error when tried to be run at the device (WTF, right ). However, when when I do run it with the cross-compiled ld-linux.so (the linker of C library) it runs perfectly. So what I should do to overcome this is, somehow inform the system that this ld-linux.so binary should be used.
I'll keep you updated as I try new things
Till next time, happy Android'ing
ADDENDUM 1:
EUREKA! Found the solution! It's as simple as symbolically linking the library folder of your GlibC as /lib to root file system. You can edit ramdisk accordingly to do this process automatically.
Another thing I'm going to try is finding a way to change the path of the dynamic-linker option of my cross compiler accordingly. Apparently, the cause of the problem was the compiler, telling the application to look for the dynamical linker at /lib/ld-linux.so.3; while it was at /data/lib (in my case). I can put ld-linux.so.3 to /system/lib and change compiler accordingly; but I don't know which way would be the best for flexibility: symbolic linking of /lib to library dir; or putting dynamic linker to /system/lib (the dynamic linker can look for libraries at the "custom" libdir already, since $LD_LIBRARY_PATH is already showing it).
Will try some tweaks now. If I can make it all work, I'll see if I can make a flashable zip or something (also will write whole process step by step
-------------------------------------
ADDENDUM 2!!
Well, I kept you waiting a lot, but wow, was this process head spinning. This was the first time I actually wrote a recovery script; first time I had to use AWK, SED or regex; and first time I wrote such a long scripts Well, whatever, we're done for now..
There are two zip files attached to the end of this thread: One is an installer and other is uninstaller. Just flash the recovery zip and reboot the phone. Your native C or C++ applications should run flawlessly (only added support for this two language for now) if all other dependencies are also met
Happy Android'ing guys; and well, I'd appreciate if you'd buy me a beer for that (or just click thanks, or just say thanks.. If you did all of those, you're my hero )
Here is the hero of the post :
Glibc for Android v0.9.5
Uninstaller for GlibC
NOTE: Uninstallers erase only files, not directories. Ergo, you might need to erase them yourself (had to do it for not to erase your own binaries and such).
HERE'S HOW YOU'RE GOING TO MAKE TOOLCHAIN YOURSELF (making a toolchain):
http://xdaforums.com/showpost.php?p=18356849&postcount=5
CHANGELOG
-----------------------------------------------------
Thank you very much for donations of:
Mr. Brochard and Mr. Huemer
I really appreciate it.
http://xdaforums.com/showthread.php?t=1296186
So far, when using "-static" directive for compiler, the applications could be compiled without doing of these steps, so why do I try this? Well, a statically linked executable is embedding all the required libraries to itself, so it's generally too huge. Also, if you compile all the applications statically, you probably link the same library (like C library, for instance) twice or more for every application you compile. This is definitely unnecessary.
It's why, for a few days now, I'm trying to compile the whole GlibC suite for Android (ARM devices, to be precise). The motive behind it is simple: since all Linux applications rely on full-fledged C library (rather than trimmed version like Bionic), if I compile it for this device, I can run every application; given that its compiled for the device.
Since it's Linux kernel underneath, we don't have to worry about changing whole system from Android to native Linux (hopefully )
So far what I did was following (I'm going to write the steps more systematically once I've time, so don't worry if those steps are too vague for you ):
1- Make a toolchain for ARMv7 architecture (which Desire CPU rely on). You can use crosstool-ng etc. or (if you're masochistic enough ) try to make your own.
2- Compile GlibC with this new toolchain of yours, store the compiled libraries in a folder where you can easily access (I keep mine at Desktop/glibc-arm for instance)
3- Edit Ramdisk of the Kernel. To do this, first you must extract the boot.img; then extract the ramdisk, edit init.rc to accordingly, so the libraries can be searched in a folder other than /system/lib (say, /data/lib). You can tweak PATH env-variable while you're at it as well . This is necessary because /system partition isn't big enough to carry all GlibC lib in it, so we can copy the library to some other folder (like /data/lib) and then make the system search for libraries there as well. The point is, since I'm using Data2ext; my data is large enough for this. I'd recommend the same to you if you're willing to go on this road.
After the editing of init.rc, reconstruct ramdisk; make a boot.img with it and flash it to the device.
4- Copy the libraries to the folder of you picked.
5- Compile some test apps (like Hello world etc ) with your cross compiler and place them to your device as well.
6- Test if they're running.
What I've found so far, the cross compiled executable (like simple Hello world), when dynamically linked, gives "no such file or directory" error when tried to be run at the device (WTF, right ). However, when when I do run it with the cross-compiled ld-linux.so (the linker of C library) it runs perfectly. So what I should do to overcome this is, somehow inform the system that this ld-linux.so binary should be used.
I'll keep you updated as I try new things
Till next time, happy Android'ing
ADDENDUM 1:
EUREKA! Found the solution! It's as simple as symbolically linking the library folder of your GlibC as /lib to root file system. You can edit ramdisk accordingly to do this process automatically.
Another thing I'm going to try is finding a way to change the path of the dynamic-linker option of my cross compiler accordingly. Apparently, the cause of the problem was the compiler, telling the application to look for the dynamical linker at /lib/ld-linux.so.3; while it was at /data/lib (in my case). I can put ld-linux.so.3 to /system/lib and change compiler accordingly; but I don't know which way would be the best for flexibility: symbolic linking of /lib to library dir; or putting dynamic linker to /system/lib (the dynamic linker can look for libraries at the "custom" libdir already, since $LD_LIBRARY_PATH is already showing it).
Will try some tweaks now. If I can make it all work, I'll see if I can make a flashable zip or something (also will write whole process step by step
-------------------------------------
ADDENDUM 2!!
Well, I kept you waiting a lot, but wow, was this process head spinning. This was the first time I actually wrote a recovery script; first time I had to use AWK, SED or regex; and first time I wrote such a long scripts Well, whatever, we're done for now..
There are two zip files attached to the end of this thread: One is an installer and other is uninstaller. Just flash the recovery zip and reboot the phone. Your native C or C++ applications should run flawlessly (only added support for this two language for now) if all other dependencies are also met
Happy Android'ing guys; and well, I'd appreciate if you'd buy me a beer for that (or just click thanks, or just say thanks.. If you did all of those, you're my hero )
Here is the hero of the post :
Glibc for Android v0.9.5
Uninstaller for GlibC
NOTE: Uninstallers erase only files, not directories. Ergo, you might need to erase them yourself (had to do it for not to erase your own binaries and such).
HERE'S HOW YOU'RE GOING TO MAKE TOOLCHAIN YOURSELF (making a toolchain):
http://xdaforums.com/showpost.php?p=18356849&postcount=5
CHANGELOG
Code:
Version 0.9.5:
* Ramdisk-boot image editing tools are included in the package, for some systems might not have it.
-------------------
Version 0.9.4:
* A bugfix for a script syntax error which causes GlibC to pass the installation checks but make binaries give "not found" error.
* A bugfix for Bash, not working well, so causing system to freeze at boot.
-------------------
Version 0.9.3:
* A major bugfix for the bug that was causing bootloops.
* A bugfix for scripting errors inside the recovery zip, causing half-installation
-------------------
Version 0.9.2:
* A small patch added that will allow GlibC to be installed with Apt-get without problems.
* Made compatible with the Sibere's new Data2SD solutions
-------------------
Version 0.9:
* Moved configuration files from /data/etc to /system/etc
-------------------
Version 0.8.1:
* Removed a symlink which may cause some Android apps use wrong version of library.
-------------------
Version 0.8:
* Complete recompilation.
-------------------
Version 0.7:
* Fixed a bug which causes Sibere's Data2sd unrecognized if Droidzone's flasher is not used
* Fixed a bug with the installation of locales.
* Included a basic busybox binary and flash_image to make library installation successfull in all recovery systems - was causing problems in some systems
-------------------
Version 0.6:
* Standart C++, MPRF, GMG and MPC libraries are added to the package
* Library profiling support is added
* All libraries are recompiled with PIC (position independent code) for better portability.
-------------------
Version 0.5:
* LibGD included in package - it's a picture manipulation library
* GlibC Version 2.14 - I'm sure even your Ubuntu-Debian machines have older versions now :)
* Locale support added. Your C/C++ programs can use it freely.
-------------------
Version 0.4:
* /tmp support added, necessary configurations are done
* Package manager support is implemented, allows users to install to both MTD and SD-ext in coexistent way (no more had to choose!).
* Developed a flexible structure, thus allowing libraries to be installed with a helper application (it's going to be shipped later)
-------------------
Version 0.3:
* Stripped libraries and binaries for make them smaller
-------------------
Version 0.2:
* Installs to the MTD Partition instead of sd-ext. Needed for inital-time programs to run correctly.
-------------------
Version 0.1:
* Initial version
-----------------------------------------------------
Thank you very much for donations of:
Mr. Brochard and Mr. Huemer
I really appreciate it.
Last edited: