I bought this tiny SL-C3100 in mid-February, and keen on studying her functionality during these couple of months. . .
So far, I haven’t changed the original SHARP ROM, any partition in /dev/hda3, and any other ROM-related customizations (even though those awesome cacko, pdaXrom images are v. attractive)
By studying meanie’s customization page and pdf, I start to understand the preliminary procedures and related stuff down here, and was wondering by the AWESOME zgcc.cramfs and java.cramfs images which are widely adopted for my compilation of gcc and java packages...
In view of this, there is a limitation for the NATIVE compilation (i.e. non-cross-compilation) in that tiny dog owing to the swap space limitation problem. Therefore, I have started seeking ‘work-around’ on that for a long time.
recently, I am attracted by a forum poster in Hong Kong (my home city) saying that he can deploy a complete GNU man page package (via man.ipk package, and make use of less.ipk, and groff.ipk packages as the media for viewing the man pages directly in console) inside his dog - but that deployment was UNDER pdaXrom. I was very astonished and frustrated when I saw that the attached .ipk (groff-1.19.2_arm.ipk, less-392_arm.ipk) was compiled using not in gcc version 2.95.2 - instead it is in later release which cause the gcc lib cannot be loaded upon arm execution. In view of this environment, some thoughts are coming out of my mind: is SHARP ROM really very not so USEFUL and needs to be abandoned?
Therefore, my gcc compilation journey starts. . .I took the groff-1.19.2.tar.gz, and less-392.tar.gz source code directly from GNU ftp site, and resides them under a /hdd3 loop image for compilation - by making use of the awesome meanie’s prepared zgcc.cramfs package. But this was a failure.
Therefore, I trusted there is a swapfile limitation issue, and I enlarge the swapfile to be 512MB in size, and put it peacefully in /hdd3 as well. Although I have done that, the compilation was in vain…. groff cannot be compiled though.
My searching was not stopped and further investigation is coming out. In a specific web page there is an introduction of Native onboard QTE development. This is an enhanced version of the zgcc cramfs image in which the file is called dev-image_1.5.img...
this gcc compilation environment is exactly the same as meanie’s zgcc.cramfs, but with the added full documentation on gcc env’t and Qt/E documentation down there, which makes the cramfs image doubles to meanie’s one. Another major difference is that it is not stationed permanently in the loop file system. Instead, it makes use of the /mnt/card/devel directory - which means the development env’t is made on demand.
Therefore, after my studies on that env’t, I have drafted out a bash-shell script which can create the /mnt/card/devel directory, mount the loop image to that, and notify the developer NOT TO REMOVE the SD card during the development env’t is launched - otherwise the Zaurus may need to be rebooted; moreover, that shell script also does the stopping of the development env’t, and prompt the developer the SD card can be removed after that. That shell script, I named it as dev-img_ctl [start stop] ...
After that development package is mounted, this link: GNU C Compiler for the Zaurus is needed to refer (as the lib version #s are different from that link) on creating manual linkages to the essential compilation libraries and includes for the environment (which can be a permanently symbolic link if you don’t plan to remove so). Concerning the Qt/E documentation, which are html pages, you can directly symbolic link to the apache / lighttpd directory for the local reference, and the man pages can be man-ed out when the ‘man-pages’ work in Qtopia is done...
the screen shot of that env’t linkage is shown in the following picture (this is my Zaurus) :-
Here comes with the dev-img_ctl bash-shell scripts written by me: -
when this development env’t is set up, I am still v. frustrated by seeing that the groff ’s and less’ compilation are still backing off; So, I try to examine the underlying error message during the compilation. . .
The error mesgs are saying ‘I/O error’ when a compilation is calling off - without any previous errors shown before that. Therefore, I suspect this error is coming from the ‘temporal directory disk space’ problem in the /tmp directory.
passing ‘ls’ in the console, we can see that the /tmp is symbolicly linked to the /dev/shm/tmp directory.
passing ‘df’ in the console, we can see that only 1M memory is allocated to /dev/shm as well. This maybe the core reason why the gcc cannot compile harsh compilations in SHARP original ROM Qtopia environment.
if you study the /root/etc/rc.d/rc.rofilesys in detail, you can understand that the /dev/shm/tmp is in fact temporarily created inside this script, and I thought out one method on EXPANDING the /dev/shm/tmp directory size is to make use of loop file image method: we can dd a “whatever-sized” called tmp.ext2 in /hdd3 directory by this command (thanks meanie again by teaching me how to do so - this example shows creating a 512M tmp.ext2): -
# su
# dd if=/dev/zero of=/hdd3/tmp.ext2 bs=1MB count=512
# echo y/sbin/mke2fs /hdd3/tmp.ext2
inside the rc.rofilesys, this statement can be easily spotted out:-
mkdir /dev/shm/tmp
you can add the following statement after the HDD is initialized (don’t add that statement too far away since the /dev/shm/tmp may fill some temp files after the checking. . . )
mount -o loop -t ext2 /hdd3/tmp.ext2 /dev/shm/tmp
Please note that THERE ARE TOTALLY 3 INCIDENCES OCCURRED INSIDE this rc.rofilesys file, you need to fill the 3 incidencies out in order to achieve a permanent expansions on the /tmp directory. . .
N.B. since rc.rofilesys file is mounted in a intrinsic read-only volume, you need to remount that volume by meanie’s taught command first: -
# mount -o rw,remount /
and after modifying the rc.rofilesys file, the following command is issued again. . .
# mount -o ro,remount /
and the final ‘df’ of my /tmp folder is shown in the following picture (i created a 128M loop image tmp.ext2 only): -
After this configuration is deployed, this tiny little Zaurus dog can now compile the complicated groff-1.19.2.tar.gz package, less-3.93.tar.gz, tar-1.15.90.tar.gz packages (even though the groff-1.19.2.tar.gz use her 1 hour for complete compilation [this is inevitable since it needs to pass so many loop devices to get it thru], the final binary is found to be successfully run and becoming my man page troff engine. . .)
Concerning the man page package, the final output is shown in the following diagram: -
