[PATCH] D58320: [Darwin] Introduce a new flag, -flink-builtins-rt that forces linking of the builtins library.

Tue Feb 19 16:38:26 PST 2019

aemerson added a comment.

In D58320#1402254 <https://reviews.llvm.org/D58320#1402254>, @peter.smith wrote:

> The implementation changes in the Darwin toolchain look fine to me, although with respect to the command line option I think Petr Hosek's message on cfe-dev is interesting:
>
> > GCC implements -nolibc which could be used to achieve the same effect when combined with -nostartfiles (and -nostdlib++ when compiling C++). I'd prefer that approach not only because it improves compatibility with with GCC, but also because it matches existing flag scheme which is subtractive rather than additive (i.e. -nodefaultlibs, -nostdlib, -nostdlib++, -nostartfiles). Clang already defines this flag but the only toolchain that currently supports it is DragonFly.
>
> Looking at https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html (quoted here for convenience)
>
> > -nostartfiles
> >  Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib, -nolibc, or -nodefaultlibs is used.
> > -nolibc
> >  Do not use the C library or system libraries tightly coupled with it when linking. Still link with the startup files, libgcc or toolchain provided language support libraries such as libgnat, libgfortran or libstdc++ unless options preventing their inclusion are used as well. This typically removes -lc from the link command line, as well as system libraries that normally go with it and become meaningless when absence of a C library is assumed, for example -lpthread or -lm in some configurations. This is intended for bare-board targets when there is indeed no C library available.
>
> It does seem like these options accomplish what -flink_builtins_rt do with the added advantage of being more portable with gcc. If they don't work for you it will be worth double checking with Petr.

Thanks for taking a look. I've replied on the thread for the problem that approach presents.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58320/new/

https://reviews.llvm.org/D58320