Did you verify all the libraries know you're using libobjc2? For example: https://bitbucket.org/ivucica/gnustep-android/src/ff0a98ab86d3ef5e400d3c5ec7b4700df139c326/phases/45-patch-gnustep-base.sh?at=default https://bitbucket.org/ivucica/gnustep-android/src/ff0a98ab86d3ef5e400d3c5ec7b4700df139c326/phases/46-build-gnustep-base.sh?at=default
On Mon, Nov 3, 2014 at 6:59 PM, Amr Aboelela <[email protected]> wrote: > Hi Ivan, > > Yes I am using libobjc2 (I think), it is in: > > https://github.com/amraboelela/myos.android.libraries/tree/master/objc > > and NDK clang > > On Mon, Nov 3, 2014 at 10:27 AM, Ivan Vučica <[email protected]> wrote: > >> Just a quick inquiry: which runtime are you using? I tried quickly >> looking through myOS repos directly on GitHub, but the project is split >> into too many repositories for me to easily track what's happening where. >> It seems to me like it's a copy of David's libobjc2. >> >> Do your build scripts ensure that relevant components of GNUstep are >> fully aware they are being built with libobjc2? >> Is Clang used in the build process? >> >> On Fri, Oct 31, 2014 at 11:53 PM, Amr Aboelela <[email protected]> >> wrote: >> >>> 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 <[email protected]> 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 <[email protected]> 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 <[email protected] >>>>> > 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 <[email protected]> >>>>>> wrote: >>>>>> > Hi Jackie, >>>>>> > >>>>>> > On Wed, Dec 7, 2011 at 15:47, Jackie Gleason < >>>>>> [email protected]> >>>>>> > 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 - [email protected] >>>>>> > >>>>>> > >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Ivan Vučica - [email protected] >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ivan Vučica - [email protected] >>>> >>>> >>>> >>>> _______________________________________________ >>>> Gnustep-dev mailing list >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev >>>> >>>> >>> >>> >>> -- >>> Info about Islam: http://wikiz.info/islam >>> >>> >> >> >> -- >> Ivan Vučica - [email protected] >> >> > > > -- > Info about Islam: http://wikiz.info/islam > > -- Ivan Vučica - [email protected]
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
