Hi, I am getting this error:
WARNING your program is becoming multi-threaded, but you are using an ObjectiveC runtime library which does not have a thread-safe implementation of the +initialize method. Please see README.initialize for more information. Everytime I run an Objective-C process, of myOS project: https://github.com/amraboelela/myos.android.frameworks Any help is appreciated On Sat, Mar 17, 2012 at 1:08 PM, Ivan Vučica <ivuc...@gmail.com> wrote: > 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 > > -- Info about Islam: http://wikiz.info/islam
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
