Hi Garret, > More importantly, can the SDK build be driven by anything other than > eclipse (UCK..)? I'd rather not install that mess and have to drive > builds if at all possible.
Hmm.. Please correct me if I am wrong. For Android Application development (Java Apps) and dealing with the emulator/hardware, we need SDK. To compile SDK, we don't need Eclipse IDE.If you don't want to mess up with SDK source, precompiled SDK is available at: http://developer.android.com/sdk/index.html However, for cross compiling LTP to Android, we need Android NDK (Native Development Kit/Tools) which is basically the arm cross toolchain tailored for Android. It's latest version is available at : http://developer.android.com/sdk/ndk/1.6_r1/index.html >> Android. To resolve this, we need to cross compile the bash-4.1 for >> Android. This change is working fine for me. > > Yes, we're trying to nuke all bashisms whenever possible. Please send > a full list of problem scripts so that they can be fixed instead of > having to cross-compile bash (><). I am afraid that it's not 100% possible. I have observed that the ash shell present in busybox will not be able to handle arrays properly (http://osdir.com/ml/busybox/2004-07/msg00152.html). > 1. #!/bin/sh not existing is a nasty portability issue that really > should be fixed with android unless google plans to roll all of their > rc scripts and stuff as a lot of people assume that /bin/sh exists > (and it's a fairly valid assumption to trust as it's standard across > multiple Unices, not just Linux..). Here, we are helpless. Can't do anything unless Google decides so, I guess. > 2. /tmp shouldn't be a big problem if tests do the right thing (for > the most part) and apart from modifying /etc/ files, put all generated > files in tmpfs mounted /tmp // /var . Some tests may fail though > unless the host platform has 2GB `free space' allocated for the tmpfs > filesystem. I really don't think 1GB/2GB free space will be available in commonly available embedded devices. We should modify the memory requirements based on the capabilities of the actual device in hand. > > If Bionic isn't being standard according to standard Linux libcall // > syscall manpages, Bionic needs to be fixed -- not LTP, as LTP (or any > Linux project) shouldn't support non-standard distro packaging quirks. I do agree with this. However, just to make things work, can we follow the same way as UCLIBC support in LTP. like: #if defined(__linux__) && !defined(__UCLIBC__) >> 4. Some syscalls should be modified using >> "syscall(__NR_syscallname,parameters...)" which is present in >> <sys/syscall.h> > > Example? fdatasync(fd) -> syscall(__NR_fdatasync,fd) truncate64( name->path, length) -> syscall(__NR_truncate64, name->path, length) .. etc >> 5. Better to have cross compiled 'perl' binary since we need to run >> some perl scripts also. > > We [Mike F and I] are advocating that we get rid of the perl > dependency where it's not required because it's just another > `annoying' tool that needs to be maintained in-house and the majority > of the time perl can be replaced by awk // sed. I honestly don't know > of any mainstream tools though that require perl other than the > top-level and post-processing scripts. This is a nice idea specially useful for the embedded devices where there are limitations on the available memory. > Thanks for the feedback! Thanks for the comments, Garrett. Best Regards, Maxin B. John www.maxinbjohn.info ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
