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 <mathias_bauer@gmx.net
<mailto:mathias_bauer@gmx.net>> 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
<mathias_bauer@gmx.net <mailto:mathias_bauer@gmx.net>
<mailto:mathias_bauer@gmx.net
<mailto:mathias_bauer@gmx.net>>__> 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> <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
Discuss-gnustep@gnu.org <mailto:Discuss-gnustep@gnu.org>
<mailto:Discuss-gnustep@gnu.__org
<mailto:Discuss-gnustep@gnu.org>>
https://lists.gnu.org/mailman/____listinfo/discuss-gnustep
<https://lists.gnu.org/mailman/__listinfo/discuss-gnustep>
<https://lists.gnu.org/__mailman/listinfo/discuss-__gnustep
<https://lists.gnu.org/mailman/listinfo/discuss-gnustep>>
--
Ivan Vučica
ivan@vucica.net <mailto:ivan@vucica.net>
<mailto:ivan@vucica.net <mailto:ivan@vucica.net>>
_________________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org <mailto:Discuss-gnustep@gnu.org>
https://lists.gnu.org/mailman/__listinfo/discuss-gnustep
<https://lists.gnu.org/mailman/listinfo/discuss-gnustep>
_________________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org <mailto:Discuss-gnustep@gnu.org>
https://lists.gnu.org/mailman/__listinfo/discuss-gnustep
<https://lists.gnu.org/mailman/listinfo/discuss-gnustep>
--
Ivan Vučica
ivan@vucica.net
<mailto:ivan@vucica.net>