But if you have alternative ideas on how to address this use case (statically linking a custom libc++ without having to duplicate all the default libs, in particular built-in ones like libbuiltin-rt), I'm happy to hear them, or course :-)
On Jul 23, 2017 3:17 PM, "Nico Weber" <tha...@chromium.org> wrote: On Sun, Jul 23, 2017 at 3:08 PM, Joerg Sonnenberger via Phabricator via cfe-commits <cfe-commits@lists.llvm.org> wrote: > joerg added a comment. > > I don't really like this. That's cool, you don't need to use the flag. > The reason why -lm is added explicitly on many targets is because the C++ > STL typically depends on it and that means for static linking and broken > ELF linkers, it will be necessary to link against it explicitly. > The driver adds -lm at the end, so it'll work if you add your static libc++ flag in user flags, and then -lm gets added at the end. But from what I understand, -lm is also there as a usability thing to make c++ a bit more accessible than c in this regard, not just for the c++ standard library. (Also, if you're trying to statically link your c++ lib, it's possible you have some influence on your linker as well.) > There is also the question on whether any platform we have currently uses > separate STL and ABI libraries and it is not clear whether the flag should > handle both. > Yes, it should handle both. > > > https://reviews.llvm.org/D35780 > > > > _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
