[D-runtime] Supporting different C libraries and architectures

Martin Nowak dawg at dawgfoto.de
Sun Feb 26 15:09:21 PST 2012


On Sun, 26 Feb 2012 21:30:33 +0100, Brad Roberts <braddr at puremagic.com>  
wrote:

> It's not much less of a problem for DMD than any other compiler given  
> that many, if not all, of the same problems crop
> between windows, linux, freebsd, and osx -- even if they are all x86 at  
> the moment.  Only one of those is a glibc based
> platform.  Among the non-windows platforms, all of them strive for some  
> level of posix compatibility.  The major
> differences are more "what subset of posix" not "I did big parts of the  
> posix apis differently".  I believe that
> exposing completely separate trees for each combination of platform and  
> libc implementation is likely to lead to major
> pain down the road.  For what it's worth, I'm not extrapolating based  
> purely on dmd's current state.  I've worked with
> nearly every flavor of unix at one point in time or another, porting  
> large code bases among them.
>
> I do agree that parts of druntime (and almost certainly phobos too)  
> conflate issues and use the occasional api that
> isn't part of posix.  Those are more the exception than the rule and are  
> likely fairly easy to clean up.  The classic
> example is indeed backtrace.  It's use is both non-portable (though man  
> it's a nice api to have) across libc's but also
> very well isolated to one call back function.  Additionally, where it  
> doesn't exist, it almost certainly would be better
> to implement behind a similarly named function call rather than a  
> version block per platform right there in the
> exception handling code.
>
> My 2 cents,
> Brad
>

I agree, keeping different trees in sync will create more issues than
fixing the few functions.


More information about the D-runtime mailing list