Linux in Android! DesirAPT is at Beta Test! [9 Feb]

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.

Eureka! Found an overcome!

Well, forgot to say this: if you want the compiled applications to be installed to some place if possible, create a "defaultinstall" file under sd-card root and write "EXT" (for sd-card) or "MTD" (for internal MTD storage) to the file (note that all uppercase).

Install manager first checks this file and if not found, uses default setting found in package (which I wrote /sd-ext generally for not-so-essential stuff ). You can use this functionality to override this setting.

Note that, some libraries and stuff cannot be installed to a different location - package manager handles this and acts accordingly; so don't worry about it

PS: The stuff I keep calling Package Manager is actually just bunch of scripts, so it's not like I wrote a whole suit

Some compiled applications!

Well, if we're not going to use it, then why did we compiled it, right?

NOTE: The following packages don't have any specific order of installation: you can install them at any order you wish. The only exception is APT - it should be installed after DPKG, or otherwise your system will think you didn't install it

For those who hates command-line interfaces: DesirAPT (the APT front-end for Android) is here DesirAPT v1.0.0

For those who would like to run Enlightenment WM in Desire - this is the mediator application for Android: LinuxInAndroid APK

Note that it requires APT and it's dependencies, along with super user privilages.

---------------------

PACKAGE: NCurses Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: It's a shell extension library which is used to format shell (or terminal output) like colorful texts, and such. Default shell might not use it (but it's definitely something necessary for new applications like nano, like "new" bash etc.)
HOW BIG IS IT: Approx. 3.4 Mb.
WHERE TO DOWNLOAD: NCurses Lib. 5.5.9
UNINSTALL?: Available at NCurses Uninstaller
CHANGELOG:

---------------------

PACKAGE: Bash
DEPENDENCIES: GlibC Library, NCurses Library, Readline Library
WHAT DOES IT DO: It's the main command interpreter for a linux system (also Android). Normally, Android is also shipped with it, but it's a very lightweight and trimmed version (also annoying - it doesn't support tab completion!). This is 4.2 version (latest now).
HOW BIG IS IT: Approx. 3.8 Mb.
WHERE TO DOWNLOAD: Bash 4.2
UNINSTALL?: Available at Bash Uninstaller/reverter
EXAMPLE OF A COOLNESS: You can change your shell label (the one shows before $ or # sign) by assigning PS1 environment variable. For instance, this : PS1="[\w]\$ " (with quotes) will show your current working directory at every prompt
(More at: http://www.lifeaftercoffee.com/2006/10/31/customize-your-bash-prompt/ )
NOTES: The bash will run the commands that you write initially on /etc/profile automatically. You can define your PS1 values, environment variables (be careful to add "export" before them) there for whole system )


---------------------

PACKAGE: Busybox Binary
NOTE: Busybox with GlibC dependency is no longer supported, because package update mechanisms require some command interpreter independent of the updated package. In order to support GlibC Update, Busybox binary will no longer be updated with GlibC support. I recommend you to revert back to static, or Bionic-linked Busybox with the link below.
UNINSTALL: Available at Busybox old version reverter

---------------------

PACKAGE: Zlib Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: It's compression library that is used with various applications like Git, Apt, DPKG etc.. It's recommended to keep it there
HOW BIG IS IT: Approx. 350 Kb.
WHERE TO DOWNLOAD: ZLib 1.2.5
UNINSTALL?: Available at ZLib Uninstaller
CHANGELOG:

---------------------

PACKAGE: ReadLine Library
DEPENDENCIES: GlibC Library, NCurses Lib.
WHAT DOES IT DO: Readline is a command line and history manager library that's used in some command line tools like socat. I personally don't know what else uses it
HOW BIG IS IT: Approx. 1.4 Mb.
WHERE TO DOWNLOAD: Readline 6.2 - v0.1
UNINSTALL?: Available at Readline Uninstaller
CHANGELOG:

---------------------

PACKAGE: OpenSSL Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: OpenSSL Library is Secure Socket Library that is used in various secure applications and web browsers.
HOW BIG IS IT: Approx. 5.9 Mb.
WHERE TO DOWNLOAD: OpenSSL 1.0.0e
UNINSTALL?: Available at OpenSSL Uninstaller
CHANGELOG:

---------------------

PACKAGE: APT - Advanced Package Tool
DEPENDENCIES: GlibC Library, Curl Library, Zlib library
WHAT DOES IT DO: APT is a front-end for DPKG which installs, removes, updates etc. packages easily. APT also supports dependency tracking, and automatically removal of unneeded packages.
HOW BIG IS IT: Approx. 1.8 Mb.
WHERE TO DOWNLOAD: apt 0.8.10.3
UNINSTALL?: Available at apt Uninstaller
CHANGELOG:

---------------------

PACKAGE: Cryptography Package
DEPENDENCIES: GlibC Library , Zlib Library, PTH Library, Readline library
WHAT DOES IT DO: This package contains some cyrptographic libraries necessary for various applications. If you're to use APT, it's recommended to install this package, for since it also carries GPG package inside. Package includes
GnuPG (2.0.18), LibGPG-error (1.9), LibGcrypt 1.5.0, LibKSBA (1.2.0), LibAssuan (2.0.2)
HOW BIG IS IT: Approx. 8.2 Mb.
WHERE TO DOWNLOAD: crpyto package
UNINSTALL?: Available at crpyto Uninstaller
CHANGELOG:

---------------------

PACKAGE: cUrl
DEPENDENCIES: GlibC Library, OpenSSL Library, Zlib library
WHAT DOES IT DO: cUrl is a secure web client that supports HTTPS protocol. Package includes also libcurl which provides secure web connection API
HOW BIG IS IT: Approx. 916 Kb.
WHERE TO DOWNLOAD: cUrl 7.23.1
UNINSTALL?: Available at cUrl Uninstaller
CHANGELOG:

---------------------

PACKAGE: Dpkg - Debian Package Manager
DEPENDENCIES: GlibC Library, Zlib library, Tar binary, Linux Utils
WHAT DOES IT DO: Dpkg is the main package for Debian package managing structure. DPKG is the responsible application for installing, removing and updating packages. Using with Apt (or other front-end) DPKG allows users to install new packages easily.
HOW BIG IS IT: Approx. 7.5 Mb.
WHERE TO DOWNLOAD: dpkg 1.16.1.2
UNINSTALL?: Available at dpkg Uninstaller
CHANGELOG:

---------------------

PACKAGE: PTH - Portable Threads Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: PTH is a POSIX compliant thread library that is used in some linux applications.
HOW BIG IS IT: Approx. 251 Kb.
WHERE TO DOWNLOAD: pth 2.70
UNINSTALL?: Available at pth Uninstaller
CHANGELOG:

---------------------

PACKAGE: Tar Archiver
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: TAR is and old and multi-purpose compression format used in various places. This tar suite is designed to be 100% compatible with the PC one (busybox one is not so good at this).
HOW BIG IS IT: Approx. 3.7 Mb (1 MB in System partition).
WHERE TO DOWNLOAD: Tar 1.23
UNINSTALL?: Available at Tar Reverter
CHANGELOG:

---------------------

PACKAGE: Linux Utilities
DEPENDENCIES: GlibC Library, Ncurses Library
WHAT DOES IT DO: This package includes low-level linux tools that is necessary for a system to run in well manner. Busybox do provide many of those, but they are quite crippled versions - so high level applications may crash using busybox ones (like DPKG).
HOW BIG IS IT: Approx. 5.6 Mb
WHERE TO DOWNLOAD: Linux Utils 2.20
UNINSTALL?: Available at Uninstaller
CHANGELOG:


Where the hell is the other packages?
Since we know have an APT repository for our distributions, in order to follow all the packages from one source, they won't be published in zip form anymore. In order to obtain them, or update them if you have older versions, you can use apt :


The packages distributed can be list with the following command:


OR, you can use DesirAPT to do these works.

See you around!

NOTE
Before you start anything, don't forget to install build-essentials package. Under ubuntu, the command necessary for it is: sudo apt-get install build-essential - I don't know about other distros..

-------------------------

Well, as promised, now we should write the steps; right?... Now, before we begin, I should really warn that the process is really head spinning if you're to do all by yourself; so take heed to the warnings I give you (I learned the hard way)

Well, first thing is first, we need a Cross Compiler Toolchain, properly built that allows us to build applications, libraries etc. There is one toolchain that's already given to you with Android Native Development Kit (called NDK) but that one is quite restricted because it's built with support for Bionic (trimmed C library that is presented in Android), not Glibc or uGlibC. If you want to develop more native-like applications (especially linux programs) you need GlibC or uGlibC. You can try to build these libraries with that toolchain too, but don't do that, because it's going to fail as well. The reason is that some sort of Chicken-Egg problem is eminent in GlibC-GCC compilation

Let's put the steps to be followed first to build a nice toolchain. I assume you're using Linux - because the tools are developed for this platform only. If you're going to use them in Windows, you need Cygwin or such tools but I can't supply help about that, for since I didn't use them before at all. Google is your friend about this

(Note, the packages I wrote at this list are available at GNU's website www.gnu.org freely, open source)
1- We're going to build "binutils" first. This package includes some important stuff like assembler, linker, archiver (for libraries) etc..
2- We're going to build GCC's prerequisites. These are GMP, MPRF and MPC packages.
3- We're going to build a "bootstap" gcc (God, I hate that name. I like to call it "naked gcc" more ). This GCC just converts source codes to pure assemblies: thus cannot generate linkages or such. We're going to use it to build "actual" tools we're going to use.
4- We're going to extract Kernel source/headers - use Desire Kernel's here. There is some copying, and such to be done tho.
5- We're going to make GlibC headers installed, which will allow us to build more "complex" gcc, which can link applications with those libraries when the library binaries are given (so such thing is there yet, but we fool it )
6- We're going to build a very limited GlibC which will give us support for building more "complex" gcc.
7- We're going to build GCC again. This is called "Pass 1 GCC" or "GCC Stage 1". This GCC can link applications to libraries, with the information in Kernel headers and library headers (it's why we give it the headers, so it can create applications suitable with the Kernel architecture).
8- We're to build actual GlibC now. This glibC will be used for our compiled applications, statically or dynamically. You can, at the end of this step, copy the files to your devices and they would work, but picking files here is harder, so I'd recommend you to leave this alone for now
9- We're going to build "Pass 2 GCC" or "GCC Step 2" This is a full fledged GCC that can do anything we want

Complex isn't it? This is precisely why I recommend you to use Crostool-NG. The other tools (like Buildtools or Crosstool) (sadly) don't create GlibC based toolchains, or use old versions of them, so using this one is recommended. This package automatically will download, setup and link your all toolchain without you worrying about something (believe me, this is what you need. I gave 8 days without this to create a working GCC and Crosstool-NG made another one to me in 50 minutes. )

Well, however, Crosstool-NG won't create "nice" applications (they'll run allright, but they won't be optimized) without some settings done, so, let's go there. First, we need to install Crosstool-NG itself. To do that; go to http://crosstool-ng.org/ website, download and extract it to some place. Even though the steps are written in Crosstool website, you don't need all commands there (like setting PATH is unnecessary). The commands you should use is, after CD'ing to the Crosstool dir;

./configure --prefix="</some/place>"
make
make install
cd "</some/place/bin>"
./ct-ng menuconfig

I used prefix as /home/ahmet/crosstool for instance. Note that this is not going to be where your toolchain is, this is where your "toolchain creator" is .
---- NECESSARY KERNEL HEADER CHANGES ----

OK now, before we start compiling; we need to make some folder moving, copying etc. in Kernel directory. This is needed, because tree structure changed a tad in 2.6 kernels and unless you compiled this kernel before, some directories won't be in their correct place for our cross compiler. Switch to the directory which you extracted the kernel image. Now, from now on, I'm going to assume you're an Qualcomm/MSM board (like Desire, Nexus One etc.) user; but if you're not, change my descriptions accordingly:

1- Go to <kernel dir>/arch/arm/include folder. Copy "asm" directory and paste it into <kernel dir>/include directory.
2- Go to <kernel dir>/arch/arm/mach-msm/include folder. Copy "mach" directory and paste it to <kernel dir>/include/asm directory. It's going to complain that there is another mach folder there and will ask if you want to merge/overwrite. Say yes to all questions.

Now our kernel headers folder is showing a Desire device. Note that if you're not a Desire user, you should use your cpu folder instead of ARM and your board manufacturer in mach-xxxxx instead of mach-msm.

Note this kernel directory, we're going to use it to configure crosstool..

--- CONFIGURING CROSSTOOL ---

After issuing the commands, the crosstool-ng will give you a configuration menu. Most of the setting here are unchanged, but the ones you should change are given below.

1- Paths and misc options
a) Try features marked as EXPERIMENTAL (this is needed to build a toolchain with the latest GlibC support) -> Enabled
b) Local Tarballs directory -> The folder address that you want downloaded stuff to be kept. You might use them again (like for compiling GlibC again for device, you will use them
c) Save New Tarballs -> Enabled ( so that new downloaded files aren't erased )
d) Working Directory and Prefix directory -> Normally you don't have to change them, but you can if you want to install your toolchain to some other location. CT_TARGET signifies your target name (like arm-msm-linux-gnueabi - arm is cpu model, msm is vendor (can be anything), linux is showing the binaries are for linux system (you can use android, but then you'll get not GlibC but Bionic) and gnueabi shows you're going to use open-source EABI structure for your executables. The other option is ELF but EABI is more flexible (because also supports ELF).
e) Strip all toolchain executables -> do it if you don't want to debug GCC itself. this makes toolchain smaller of size, and a tad faster.

The other options can stay the way they are, or you can change them accordingly here. You can get help with ? key, and if you don't understand anything, just leave them default - there are very complex things there that you don't need to know if you're not planning to be a expert on subject

2- Target options
a) Target Architecture -> arm should be selected, cos Desire uses ARM. If you plan to make toolchain for, say, powerpc, pick that.
b) Endianness -> Should be little. ARM processors in Desire uses little endian system.
c) Architecture level -> "armv7-a" this is should be written. Desire uses ARMv7 based instructions and if you leave here empty, the applications will be built with armv5 support - they're still going to run but not use advanced v7 features.
d) Use Specific FPU -> "neon" . Desire uses NEON structure for floating point arithmetic, and if you leave here empty, the applications will not use Desire's FPU abilities (everything will be software based, which is slower)
e) Default instruction set mode -> arm . You can use thumb here for allegedly faster code but not every build system supports it. Leave it ARM.
f) Use EABI -> enabled. EABI is necessary for most flexible desing of binaries.

The other settings be as they were.

3- Toolchain options
a) Tuple's vendor string -> You can leave here empty if you don't want to; it's not necessary to use a string here. I used "msm" but you can write anything. This string here is used in toolchain name as arm-xxxxx-linux-gnueabi, so make it short, I recommend
b) Tuple's alias -> make it something short like "arm-linux" This alias string is used to make calls to your toolchain easier. Instead of writing arm-msm-linux-gnueabi-gcc everytime, you can use arm-linux-gcc to compile your applications. Can write anything here (like toolchain if you want to use toolchain-gcc to compile your applications)

The other settings can stay as they are, for since default values are the best in our case. You can tweak them only if you know Desire cpu like the back of your hand

4- Operating system
a) Target OS -> Use "linux" if you want the applications to run in Android and Linux; use "bare metal" if you're to compile low level applications which won't use linux headers. Default is linux.
b) Get Kernel headers from -> say "pre installed" because otherwise it's going to download standard Linux headers from internet. We needed some changes, so this option is compulsory to be "pre installed"
c) Path to custom headers directory/tarball -> Path to your kernel source folder - which you made changes above. WARNING: I say specifically extracted, because standart tarball won't work for us. We're going to make some changes in kernel directories, which is non-standart (Instructions were above).
d) This is a tarball -> No . We're going to use extracted folder.
e) Build shared libraries -> say "yes"; because we want dynamic linkage, not static one
f) Check kernel headers -> say "no" otherwise some unnecessary check causes compilation to stop.

5- Binary utilities
a) Binutils version - pick the latest one, 2.20.1a. If you use older versions with newer GCC/GlibC, it's not going to succeed.

Leave others as they are, they are not big deal..

6- C Compiler
a) GCC Version -> pick 4.6.1 for since it's the latest and most bug free. Just stay away from 4.5
b) Pick the languages you want support for. I've read online that Java is a tad troublesome in Android platform, for since Java in Android uses Dalvik, not Sun systems. You can try it at your second toolchain if you want Definitely pick C++ tho
c) Link libstdc++ statically -> say yes; it really saves you from big configure scripts later - apparently needed to avoid PPL problems as well
d) Compile lidmudflap/libgomp/libssp -> say no. These libraries are not the most suitable libraries for ARM platform (at least at cross-compiler level. You can compile them later, if you want, with your cross-toolchain.)

You can leave others as default

7- C library
a) C library -> gLibC (recommended). You can use other libraries which are eGlibC (embedded Glibc, like Bionic) and uGlibC (micro-glibc) too, but GlibC is the most spanning solution above those. The libraries are bigger, but they support more.
b) glibC version -> Use 2.13 (experimental) it compiles just fine, and you get a new version of GlibC. Not the newest, but that's ok
c) Threading implementation -> nptl (recommended) . You can use linuxthreads too, but nptl is more advanced ( like giving support to Thread-Local-Storage and such)
d) Force Unwind Support -> Enabled . If you don't use this option, for since we're making this toolchain from scratch, it's going to give you error during compiling that it couldn't find necessary headers (we're building them now, dumbass!)

Leave others default if you don't know what they're about

8- Companion Libraries
Well, go and pick the latest versions, even though when it says "Experimental", otherwise your GCC compilation will give you error about these libraries being old.

After setting these settings, press ESC key twice till it goes way back and ask if you want to save configuration; say yes.

--- STARTING COMPILATION ---
Now to start compilation write
./ct-ng build.

This is going to take approx. 45 minutes, so go watch some episodes of Big Bang Theory or something. Normally, there should be no errors but if there is; most probably either you made a wrong configuration, or didn't set your kernel folders well. Try again with other settings, google your problem etc..

After this process, you're going to have a cross-compiler at your use at /home/<username>/x-tool/arm-<vendor>-linux-gnueabi/bin folder. Note that Crosstool-NG automatically makes this folder read only to make you prevent screwing your toolchain You must edit your path variable to show "/home/<username>/x-tool/arm-<vendor>-linux-gnueabi/bin" folder as well for less headaches during compiling later

Whilst compiling other application, most used configure options you're going to use is "--host=arm-<vendor>-linux-gnueabi" and "--prefix=/some/folder/you/want/this/application/copied". After compilation, you can send binaries to your phone from prefix folder.

More options about GCC and Configure is available at GCC and Autoconf man pages; check them as well

Happy cross-compiling people

THIS POST IS ONLY FOR THE BRAVE MAN

These are packages which are compiled; but not installed and/or tested by myself. Please test them and inform me if they work (PM me if they work or not; it's better that way ).

--------------
NO PACKAGES HERE! Frankly, I did test virtually all of them. They might not work as expected maybe, but at least they don't impede functions of device

Developer Log

Now while preparing a suitable (and as flexible as it can) recovery zip; I realized that instead of editing ramdisk, I can also use init.d script to link /lib to /data/lib. This also allows some flexibility to user (i.e. move library folder around -if needed- and edit init.d script accordingly and still have a running system).

What baffles me most is PATH env-variable. Apparently, if I set it at init.d level, it's not exported quite well - apparently, there is a user mode switch between init.d script run and ramdisk loading process (because PATH variables at Ramdisk are exported to all applications, whilst init.d ones are not) and the only way to set PATH variable for all processes is editing Ramdisk (AFAIK)...

And another point: what if kernel doesn't support init.d? (Go to hell if you're reading this post with a kernel which doesn't ) Ramdisk solution is quite general (i.e. works for everyone) but it's a little harder to edit with scripts and not as flexible as init.d method. I think it's safe to assume that there is init.d support at this level

Maybe I can create two versions (init.d one and ramdisk one) of recovery zip's.. Keep in touch guys..

Droidzone said:

Well, what's the difference between init.d and ramdisk, when init.d support means running busybox runparts from ramdisk?

Click to expand...

Click to collapse

Well the difference is caused by Unix variable propagation.

Normally, when ramdisk is loaded and init.d scripts are starting to run (with run-parts binary) the exported variables are valid only for the scripts that run-parts do run. Since Linux only allows child processes to inherit variables from host, when runparts finishes job; defined variables within the scripts vanish.

When you add variables to Ramdisk (init.rc) directly, since variables become declared from init directly (and since init runs all the processes on boot) the variables automatically become available for all processes.

That's the difference I meant

Droidzone said:

Got it..So the variables from init.rc persist till shutdown..

Click to expand...

Click to collapse

Precisely. It's why the variables (even those which defined by export keyword) are vanished when the system booted up (unless defined in ramdisk)

Well, I've gotta learn RegEx one day anyways

Recovery zip is done! Now, I should test it on my device first

I'm also going to make a uninstaller script I think. It's really messy to clean this up otherwise

Android binaries and dependencies

I've examined the dependencies of all the binaries in /system/bin and /system/xbin in Android system. Too sad that the list contains some non-standart libraries (that's not that bad, sure you can find their sources).

Also, another problem is that you need to compile the binaries themselves from the source code as well (with the GlibC libraries) - which is near to the compiling the whole ROM itself - I'm not even sure if we can find source code (will check the Android source code itself when I've time)

The dependencies in my system, for instance, are as follows:

Well, it can, but the kernel needs ext4 modules (or direct support). I checked the native mount source, it actually does nothing much more than simply calling kernel's ioctl or mount system call..

I think a simple tweak at ramdisk is all you need for that (and a supporting kernel, of course )

Weird thing about previous issue is, I have the source codes of most utilities, I can compile them too, but I don't have proper makefiles and I'm too lazy to write them myself - that's a lot of trial and error.

Well, apparently, we're not going to be able to switch from Bionic to Glibc completely. I think I can make them coexist tho.

Droidzone said:

Earlier this month, I was trying to compile dosfstools for Android. But got stuck at static cross compile with ndk gcc

Click to expand...

Click to collapse

So, I'm not barking for the hollow tree here.. That's a relief. Seeing that this post is not that active, I was starting to think I'm working in vain..

Well, now, apparently init version of mount is quite restricted about options. The ones it supports are given in mount.c as:


I'm checking the mount.c source as we speak. I'm going to inform you if I can find something.

EDIT: BTW, also "no"+options are recognized (like noatime)

ADDENDUM:

The internal mount is exactly the same as the mount we use at busybox. So, most probably, it's the same was in init script.

Try this line


Notice that I erased some flags. You might also try to add them, but check if this line works first.