DragonFly ToolChain Patch

Hi,

the attached patch enables a DragonFly target in the clang driver,
allowing us at DragonFly to use llvm/clang properly without relying
heavily on gcc.

While so far the patch has been working, if anybody spots a mistake
please say so! It will probably not be the last revision of it but
nonetheless I would prefer if it could be commited upstream as it avoids
having to keep a dragonfly-local patch which has to be handed to anyone
using llvm/clang on df.

I've also added an option to Options.def (-nolibc). We rely on it at
DragonFly although it is not standard. I'm not sure what the policy on
this is, but I would think that it doesn't hurt comitting that upstream,
too.

Cheers,
Alex

clang_dragonfly_toolchain_0.1.patch (14.4 KB)

Hi Alex,

Thanks for the patch, I will review & get this in ASAP (but possibly not till Monday).

Hi,

the attached patch enables a DragonFly target in the clang driver,
allowing us at DragonFly to use llvm/clang properly without relying
heavily on gcc.

While so far the patch has been working, if anybody spots a mistake
please say so! It will probably not be the last revision of it but
nonetheless I would prefer if it could be commited upstream as it avoids
having to keep a dragonfly-local patch which has to be handed to anyone
using llvm/clang on df.

I’ve also added an option to Options.def (-nolibc). We rely on it at
DragonFly although it is not standard. I’m not sure what the policy on
this is, but I would think that it doesn’t hurt comitting that upstream,
too.

What do you mean by non-standard? I assume it is part of gcc on DragonFly, or does DragonFly maintain a patch to add support for this?

  • Daniel

Hi Daniel,

When I said non-standard I just meant that it is not supported by
upstream gcc, just by our own gcc version that ships with our base
system (regarding -nolibc). This change was decided many years ago and
since then we've always been shipping a gcc with that flag enabled.

For easiness sake it would be great if clang could just adopt that flag
as it doesn't clash with anything else.

Cheers,
Alex

Applied with a few formatting tweaks, thanks!

Hi Daniel,

When I said non-standard I just meant that it is not supported by
upstream gcc, just by our own gcc version that ships with our base
system (regarding -nolibc). This change was decided many years ago and
since then we’ve always been shipping a gcc with that flag enabled.

For easiness sake it would be great if clang could just adopt that flag
as it doesn’t clash with anything else.

Ok, this is fine with me. It doesn’t hurt anyone else, although it would be nice at some point if we had a way to document / automatically reject options which were only useful for one platform or another.

  • Daniel