So I've been playing with compiling GNUstep for Android a little this
evening. I'd love David's input, since reflecting back on his status report
for a WebOS port, he mentioned he worked on solving the precise problem I'm
having ('configure' not running test programs when cross-compiling).My setup: 0. OS X Lion 1. Installed Android SDK into /Applications/android-sdk-mac_x86 2. Installed android-ndk-r5c into /Applications/android-sdk-mac_x86/android-ndk-r5c 3. Installed an Objective-C-supporting toolchain into /Applications/android-sdk-mac_x86/ndk-objc - January 2010 download from: http://code.google.com/p/android-gcc-objc2-0/downloads/list 4. Wrote the following script, intended to be placed into .../core/make and .../core/base #!/bin/bash export SDK=/Applications/android-sdk-mac_x86 export NDK=${SDK}/android-ndk-r5c export NDKCC= "${SDK}/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86" export NDKOBJC=${SDK}/ndk-objc/usr/local/android export SYSROOT=${NDK}/platforms/android-5/arch-arm/ export PATH="${SDK}/tools:${PATH}" export PATH="${SDK}/platform-tools:${PATH}" export PATH="${NDK}:${PATH}" export PATH="${NDKCC}/bin:${PATH}" export PATH="${NDKOBJC}/bin:${PATH}" # The most preferred binaries are from ObjC NDK, so it comes last in order to be added to first place on the PATH. #NDKCC: #export DROID_TARGET=arm-linux-androideabi #NDKOBJC: export DROID_TARGET=arm-eabi export CC=${DROID_TARGET}-gcc export CXX=${DROID_TARGET}-g++ export CPP=${DROID_TARGET}-cpp export AS=${DROID_TARGET}-as export CPPFLAGS="-I${SYSROOT}/usr/include" export CFLAGS="-nostdlib ${CPPFLAGS} -specs=/tmp/android-gnustep-gcc-spec" export OBJCFLAGS="${CFLAGS} -I${NDKOBJC}/include" export LDFLAGS=" " #export DROID_TARGET=arm-linux-androideabi export ac_cv_c_bigendian=no echo '*invoke_as:' > /tmp/android-gnustep-gcc-spec echo '%{!S:-o %|.s | '"${DROID_TARGET}"'-as %(asm_options) %m.s %A }' >> /tmp/android-gnustep-gcc-spec ./configure --host=i686-apple-darwin --target=${DROID_TARGET} --prefix=${HOME}/gnustep-android exceptions=no Note the extremely hackish way of overriding "*invoke_as" spec in GCC downloaded as a part of that "January 2010" download from the android-gcc-objc2-0 project on Google Code. Build process. 1. In .../core/make, opened "configure" in vim to remove all attempts to link with pthread (unnecessary under Android): vim configure :%s/-pthread//g :%s/-lpthread//g :wq 2. In .../core/make, ran: ./android.sh && make && make install resulting in a gnustep-make installation in ~/gnustep-android 3. Sourced GNUstep.sh: . ~/gnustep-android/Library/GNUstep/Makefiles/GNUstep.sh 4. In .../core/base, opened "configure" in vim to remove all attempts to link with pthread (unnecessary under Android): vim configure :%s/-pthread//g :%s/-lpthread//g :wq 5. In .../core/base, ran: ./android.sh And this is where I'm stuck. pthread tests seem to pass ok, but tests having to do with objc exceptions seem to cause a failure since I'm cross compiling here, and there is a test program that needs to be run. checking size of pthread_mutex_t... 4 checking size of pthread_cond_t... 4 checking alignment of pthread_mutex_t... 4 checking alignment of pthread_cond_t... 4 checking for thread_create in ... yes checking for sched_yield in -lrt... no checking for nanosleep... yes checking for usleep... no checking for Sleep... yes checking whether objc really works... yes checking if +load method is executed before main... no checking for objc_sync_enter... yes checking for objc_setProperty... yes checking for _Block_copy... yes checking for objc_setUncaughtExceptionHandler() in runtime... no checking for objc_set_unexpected() in runtime... no checking for _objc_unexpected_exception in runtime... configure: error: in `/Users/ivucica/projects/THIRDPARTY/gnustep/core/base': configure: error: cannot run test program while cross compiling See `config.log' for more details David, in the previous mail from a few months ago, in a different thread, you mentioned you had removed all tests that ran test programs from 'configure' when cross-compiling is detected. Did you commit these changes to 'configure.ac' and 'configure'? If so, how do I use them? Did you manage to run base on WebOS? Everyone, there is also a TODO that tests for exceptions should not be run when option 'exceptions=no' is set. Just to note, I'm aware that some of the hacky changes I've made above should actually be done in 'configure.ac' and should depend on a new target OS called 'android'. I don't have autotools on the Mac, so it was easier to directly edit 'configure'. I'd really love to get GNUstep's base running. On Sat, Dec 10, 2011 at 19:03, Ivan Vučica <ivuc...@gmail.com> wrote: > Looks like in replying to your email directed to me I forgot to CC the > list. > > On Sat, Dec 10, 2011 at 16:24, Jackie Gleason <jackieglea...@gmail.com>wrote: > >> The problem with the lpthread join is that Android has no lpthread, it >> is actually integrated into libc so for Android this would need to be >> an optional param. >> > > True! I'd say something along the lines of "--enable-integrated-pthread" > which would just avoid passing -lpthread. > > There is a gcc option "-pthread": I would not be surprised if it > automagically did the "right thing" on Bionic platforms. > > >> >> I have started work on an Android make file instead, however, I am >> getting the following... >> >> >> /home/jackie/Development/Code/GnuStep/core/base/Headers/Foundation/NSException.h:44:2: >> error: #error The current setting for native-objc-exceptions does not >> match that of gnustep-base ... please correct this. >> >> So I am working to figure out why this is happening. >> > > Maybe you could try disabling the exceptions support for now. > > Is your work published somewhere in a public repository? SVN, Git, > Mercurial - anything? > > >> >> On Sat, Dec 10, 2011 at 6:02 AM, Ivan Vučica <ivuc...@gmail.com> wrote: >> > Hi Jackie, >> > >> > On Wed, Dec 7, 2011 at 15:47, Jackie Gleason <jackieglea...@gmail.com> >> > wrote: >> >> >> >> Yup that looks like the right one there looks like there is a link to >> the >> >> Labs toward the end. I am also looking into some of the options for a >> port >> >> of UIKit but not very far along there. Some people have also been >> having >> >> success with Cocotron (using my toolchain compiling), however, since I >> don't >> >> have XCode or a mac (although if I get desperate my gf does) I have >> stuck >> >> with trying to get GNUStep to work compile (see original message). >> > >> > >> > I intend to work on UIKit using OpenGL and primarily targeting X11. I >> began >> > work on UIApplication, and intend to work on it slowly. >> > >> > It's in the GNUstep repository under dev-libs. >> > >> >> >> >> >> >> I have included the config.log, however, I think the real problem here >> is >> >> for some reason the pthreads stuff isn't get included. This seems odd >> >> considering it should be included inside the platform folder included. >> I >> >> know there can be some problems with Bionic and pthreads but join >> shouldn't >> >> be that issue. >> >> >> >> GnuStep Make seems to compile fine... >> >> >> >> jackie@jackie-Latitude-E6410:~/tmp/gnustep/make$ ls >> >> bin etc share >> >> jackie@jackie-Latitude-E6410:~/tmp/gnustep/make$ ls ./bin/ >> >> debugapp gnustep-config gnustep-tests openapp opentool >> >> >> >> Am I missing some sort of fancy include in my CFLAGS or LDFLAGS? >> > >> > >> > From what I can see in config.log, linker step of compiling is failing >> on >> > the pthread_join() test, just as you documented in your later email. >> > >> > Just look for the line: >> > "configure: failed program was:" >> > and this line will be followed by the program that failed. >> > >> > Program that failed is testing for pthread_join(). Looking above the >> program >> > that failed, I see the following: >> > >> > <a long path to ld>/bin/ld: cannot find -lpthread >> > >> > You probably need to tell the linker where to find libpthread.a. LDFLAGS >> > then needs to contain -Lfolder/which/contains/libpthread/dot/a in >> addition >> > to any other options you want to have in there. >> > >> > In your later email you stated: >> >> >> >> if I set pthread_ok=yes to goes on to the next issue (seems test are >> ran >> >> even when cross compile which of course fails.) >> >> Although that I can just change it I am worried I have my linking set >> up >> >> wrong, any help would be great. >> > >> > >> > Can you document where it fails, apart from tests? >> > >> > Also, it might be possible to turn off thread support under GNUstep. >> > >> > -- >> > Ivan Vučica - i...@vucica.net >> > >> > >> > > > > -- > Ivan Vučica - i...@vucica.net > > > -- Ivan Vučica - i...@vucica.net
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
