[D-runtime] Supporting different C libraries and architectures
Johannes Pfau
johannespfau at googlemail.com
Sun Feb 26 05:32:47 PST 2012
Am 26.02.2012 10:45, schrieb Jonathan M Davis:
> On Sunday, February 26, 2012 10:02:00 Johannes Pfau wrote:
>> Am 25.02.2012 20:52, schrieb Sean Kelly:
>>> Ugh. It's worth noting that the current definitions for OSX, Linux, and
>>> FreeBSD are all glibc and all relatively different, too.
>> FreeBSD doesn't use glibc by default although glibc has FreeBSD support.
>> They use "BSD libc" http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/
>>
>> The OSX C library seems to be part of libSystem. And that seems to use "
>> Darwin libc" http://www.opensource.apple.com/source/Libc/ which is BSD
>> licensed and therefore can't be based on glibc.
> If it's varying for pretty much every OS,
I still think the big differences are between different C libraries, not
OS (and different OS often use different C libraries, but there's also a
glibc port for FreeBSD, so there are exceptions).
> and the problem is that android
> doesn't match what linux does but is considered linux,
'Linux' is just the kernel, and Linux can use many different C
libraries(eglibc, uclibc, glibc, dietlibc, bionic, musl). The problem is
that druntime assumes that linux == glibc which isn't true. glibc
specific code should be guarded with a version(Glibc)/static if(libC ==
Glibc) and not version(linux).
> then maybe there should
> be an android version and then either android isn't linux, or it's both linux
> and android, and we just do like we do with Posix and put the more specific one
> first in the version lists.
Android is both 'linux' and 'Android'. gdc currently defines both
version(linux) and version(Android) for it. It's not posix though.
But that's not the problem. The problems are like this: Android's thread
implementation is not posix compliant, but it supports most posix
threads functions. So what to do with core.sys.posix.pthread?
Sure we could just add another version(Android) block and include
everything there, but if we're going to duplicate all the function
definitions, enums, etc (like we already do for BSD, OSX, 'linux')
anyway, why put it all in a single file? Android is just one example,
there will be many more when gdc gets ported to different architectures.
Kagamin suggested to add complete glibc, bionic, etc bindings to deimos,
then core.* could publically import the approriate modules from deimos.
Seems like a good idea to me. We'd need some way to determine the used C
library with static if(), to import the correct files, but the rest
seems simple enough. Technically this means druntime depends on deimos,
but those are only bindings which could be compiled/shipped with druntime.
--
Johannes Pfau
More information about the D-runtime
mailing list