On 15.11.2011 21:12, Jonas Maebe wrote:
On 15 Nov 2011, at 21:06, Florian Klämpfl wrote:
I dn't know if this is a good long term solution: I fear too much
duplication with having a seperate android target. I'd prefer an
FPC_ANDROID define, I don't think that it will pollute the rtl and
considering that there are a lot of arm "sub architectures" out there
having an own target for each of them isn't a good idea either. Maybe we
can even introduce some SUBARCH in the long term into our build system.
Android isn't a different architecture (if you consider native applications),
but a different OS. It uses a Linux kernel (although even that one is heavily
patched, afaik), and user land is obviously quite different (including the C
library and the dynamic linker).
But FPC also supports different C libraries (at least glibc and uclibc).
And they may have drastic differences, too, they simply didn't occur yet
as not that many people are testing/using the uclibc support. So what
would speak against adding another one and using (and if necessary
adjusting) the libc variation of the RTL (if it's indeed not a good idea
to use direct syscalls)?
Regards,
Sven
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
