Native Qte On-board Development Package

[dinorex]

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....

[dinorex]

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 through.

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] ...

[dinorex]

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) :-
[img]http://img352.imageshack.us/img352/6285/scrn0022jv.jpg\" border=\"0\" class=\"linked-image\" /]

[dinorex]

Here comes with the dev-img_ctl bash-shell scripts written by me:-

#!/bin/sh -e
#
# driving the development image (dev-image_1.5.img).
# written by: Phil Lau in May 2006
# Zaurus version.
#

export PATH=/bin:/usr/bin

# Safeguard (relative paths, core dumps..)
cd /

case "$1" in
  'start')
        #
        # DEPLOY the environment
        # create /mnt/card/devel dir and mount it from dev-image_1.5.img
        #
        if test ! -f /mnt/card/devel
        then
                mkdir -p /mnt/card/devel
        fi
        echo -n "mounting the disk image and source envt vars..."
        echo
        sudo mount -o loop /hdd3/dev-image_1.5.img /mnt/card/devel
        echo -n "remember to type 'source /mnt/card/devel/devel.sh' before further proceeding!"
        echo
        echo -n "******* Plz run '"$0" stop' b4 u try to take ur SD out!!!!!!"
        echo
        echo
        ;;
       
  'stop')
        #
        # STOP the environment
        # umount /mnt/card/devel dev-image_1.5.img and rm /mnt/card/devel dir
        #
        echo -n "unmounting the disk image and remove the /mnt/card/devel..."
        echo
        echo -n "******* U can now safely take ur SD out......"
        echo
        echo -n "******* Plz 'source .profile' again to revert the console prompt"
        echo
        echo
        cd /home/zaurus
        sudo umount /mnt/card/devel
        if test ! -f /mnt/card/devel
        then
                cd /mnt/card
                rmdir devel
                echo -n "removed /mnt/card/devel"
                echo
        fi
        source /home/zaurus/dev-img_prompt
        ;;

  *)
        echo "usage: $0 [ start|stop ]"
        exit 1
        ;;
esac

[speculatrix]

good work - useful information - thanks!

[dinorex]

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...

[dinorex]

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): -

[dinorex]

A further comment: -

after this patch, the HancomWord can HancomSheet can read further complex .doc and .xls document (say, initially they can't read doc with images, but now they can...)

the JustReader can read txt file more than 1M.

Conclusion: seems the /tmp directory space plays an important role on the apps capability...  

[Meanie]

A further comment: -

after this patch, the HancomWord can HancomSheet can read further complex .doc and .xls document (say, initially they can't read doc with images, but now they can...)

the JustReader can read txt file more than 1M.

Conclusion: seems the /tmp directory space plays an important role on the apps capability... 
[div align=\"right\"][a href=\"index.php?act=findpost&pid=126228\"][{POST_SNAPBACK}][/a][/div]

just to add that setting the TMPDIR environment variable also allows you to change where the applications places its tmp files, ie

Code: [Select]

export TMPDIR=/mnt/cf/tmp
will tell the apps to use /mnt/cf/tmp instead of /tmp

however, some naughty apps have /tmp hardcoded and will ignore that variable so you will need to force it to use the alternate location by mounting over /tmp as mentioned before or just do

Code: [Select]

mount -o bind /mnt/cf/tmp /tmp

[Cresho]

after surviving my "HDD 00 Clear" dilema and managed to restore my 6gb internal hardisk back to spec, Now i am thinking of repartitioning my internal drive to run a tmp.  you seriously gaved me something to look forward to.

[bam]

where's the ipk's or bin's?

[dinorex]

where's the ipk's or bin's?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=129076\"][{POST_SNAPBACK}][/a][/div]

posts #2 & #3, there are 2 links implicitly specified....  

[dinorex]

just a simple follow-up: -

having watched Meanie's zgcc on-board X/Qt compiler package..

https://www.oesf.org/forums/index.php?showtopic=18789&st=0

I found that package is already terrific for Qt development as well. Having attached automatically via the loop device, it is advised to use that package right away.

Moreover, for the 'qmake' function in Qt env't, this can be achieved by the 'tmake' with a little longer command: -

Code: [Select]

tmake {project name}.pro > Makefile
so that the Qt project's Makefile can be easily made out....

[Cresho]

I spent 1 hours last night trying to install this.  I do not understand why I couldnt get the zgcc to work but I grabed a crams image and then i modified one of the installers.  Thing mounts and stays mounted with automounter.  when i launch qconsole, zgcc greats me as if it was just staying in the background waiting for me to use it.  Very nice.  automounter insures after a reboot, the zgcc stays mounted.

[dinorex]

I spent 1 hours last night trying to install this.  I do not understand why I couldnt get the zgcc to work but I grabed a crams image and then i modified one of the installers.  Thing mounts and stays mounted with automounter.  when i launch qconsole, zgcc greats me as if it was just staying in the background waiting for me to use it.  Very nice.  automounter insures after a reboot, the zgcc stays mounted.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=129545\"][{POST_SNAPBACK}][/a][/div]

actually, i have already kicked this stuff away for a period of time since i found the awesome Meanie's second edition of his zgcc-2.95-2.cramfs (which is mentioned in my previous post) which covers essentially most of the Qt development.

For further follow-up, since the dev...img has 'qmake' and 'qembed' utilities which can build an 'include' file and 'Makefile' easily by them, i strong suggest Meanie's zgcc cramfs to cover this as well as my temporal solution to Qt development is just put those stuffs inside my /usr/local/bin .

concerning the 'Standalone Qt Tutorial' which covers OpenGL library, I also found that even Meanie's second edition of zgcc cramfs cannot compile them (of coz for the previous stuff / dev...img bounces back with a horrible absentee messages...), I suspect that even this version of cramfs doesn't cover the LIB of the OpenGl (as it reports that '-lGLU' option hasn't be recognised during ld operation, that means system includes are present, but the linker libraries are evicted out...).

if that can be added in the future versions, I think this tiny little development box can be achieved in a more enhanced fashion so that the 'freshmeat' stuff can be compiled as well...