Well, you can always try writing a layer that allows opening an OpenGL ES drawing context from something that approximates the usual C program structure of having main(), and then (some time in the future) attaching our Core Animation implementation to it... ;-)
On Fri, Mar 28, 2014 at 3:53 PM, Mathias Bauer <[email protected]>wrote: > Update: as the NDK also contains clang 3.3, I gave it a try. No problems > with the assembler. :-) > > So now I successfully compiled and linked libobjc2 and most of the test > cases. > > Now I'm curious about the next steps... > > Am 28.03.14 15:45, schrieb Mathias Bauer: > >> I tried to compile libobjc2 with a standalone-toolchain based on the >> current NDK (contains clang 3.4) on Ubuntu_64 (12.04). >> >> After removing some lines in the CMakeLists.txt of libibjc2 that are not >> needed, but don' work, I got the makefiles generated with CMake. Thanks >> for your "script" BTW, it helped me to figure out how to tell CMake what >> to do and so saved me a lot of time! >> >> Calling "make" however ended up in the assembler complaining that the >> selected processor "does not support ARM mode blx r3" and the like. I >> added -integrated-as to the flags for C and C++ files and then the make >> went on to 40% and then complained about a similar problem again. I also >> saw some warnings about "soft-float" not being a recognized feature for >> the target. >> >> As you obviously had more success back then with clang 3.1, maybe it's a >> problem caused by (not necessarily in) the compiler. >> >> So currently I have no clue how to proceed. >> >> I wonder whether it's possible to use the vanilla clang trunk version >> instead of the clang provided by the NDK, but probably the NDK clang >> contains some necessary patches. >> >> Regards, >> Mathias >> >> Am 26.03.14 15:48, schrieb Ivan Vučica: >> >>> Any work I have done has focused solely on getting *something* to work. >>> I've essentially tested if NSString works, and that's about it. >>> >>> The best way to determine whether something you're interested works is >>> to try it out. I wasn't personally interested in getting more than a >>> proof that it is possible to continue to work on gnustep-base. And it is >>> possible. One can sit down, iterate and contribute upstream. Even that's >>> fantastic news compared to, say, four years ago. You "only" have to deal >>> with a nonstandard libc, nonstandard directory layouts, nonstandard >>> sandboxing approaches and a requirement to interface with Java. You >>> don't have to build your own compiler, deal with a custom build system >>> or (as was the case until recently on certain other platforms) find a >>> way to target a proprietary bytecode VM... >>> >>> I'd say that, similar to any other platform where portability is not >>> proven yet nor guaranteed, it is best to start a project 'from scratch' >>> and work on target ports 'in parallel', adapting to quirks of each in >>> the process. Based on what experience I had with targeting Android in >>> general (and that isn't much), I'd treat porting existing code akin to >>> starting a new port of a game that draws with DirectX and in general >>> shows little consideration for non-Win32 platforms -- one year into the >>> project. It's probably not going to end well (or at least not without >>> many stolen staplers and burning buildings). >>> >>> >>> On Wed, Mar 26, 2014 at 11:40 AM, Mathias Bauer <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi, >>> >>> what is the current status for GNUstep base on Android? >>> >>> I did some research and found some activity, but mostly older stuff. >>> Nowadays one year already is quite old. :-) >>> >>> From an external view point I see the following possible problems: >>> >>> - as Linux/ARM showed us, exception handling and unwinding on ARM >>> don't work properly with clang <= 3.4, but that's the clang version >>> used by the Android NDK; so should we expect similar problems there? >>> >>> - I couldn't find reliable information about libdispatch on Android, >>> and AFAIR Android does not have a fully compliant implemenation of >>> pthreads, so I'm concerned if the pthread-workingqueue lib (a >>> prerequisite of libdispatch) works on Android >>> >>> - GNUstep base has some prerequisites like libxml2 etc.; I think >>> they all need to be compiled for Android also >>> >>> - I wonder if there is an NSNetServices implementation in GNUstep >>> that works on Android >>> >>> I know that there is apportable.com <http://apportable.com>, but >>> they claim not to use GNUstep anymore, so this does not give any >>> hints about the feasability of using GNUstep/libobjc2/libdispatch >>> for porting Objective-C code (at least code that does not use GUI >>> classes) from iOS to Android. >>> >>> Regards, >>> Mathias >>> >>> _________________________________________________ >>> Discuss-gnustep mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.gnu.org/mailman/__listinfo/discuss-gnustep >>> <https://lists.gnu.org/mailman/listinfo/discuss-gnustep> >>> >>> >>> >>> >>> -- >>> Ivan Vučica >>> [email protected] >>> <mailto:[email protected]> >>> >> >> _______________________________________________ >> Discuss-gnustep mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > -- Ivan Vučica [email protected]
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
