ldc
ldc copied to clipboard
ldc-developers
Implement --cppstdlib
This flag allows user to select from GCC/Clang C++ runtimes
on Linux similar to --stdlib on clang.
AFAICS, llvm::triple does not have support for this.
Even clang has a separate flag for it.
I'd prefer that this be done upstream and then adapted for LDC as a) DMD will need this too, and b) target.d and the command line processing for target specific things has changed a lot recently and this will only add to that.
I'd prefer that this be done upstream and then adapted for LDC as a) DMD will need this too, and b) target.d and the command line processing for target specific things has changed a lot recently and this will only add to that.
Is there a consensus over this?
Sorry for the late reply, but this PR popped up while I was on vacation. - I'm not a big fan of a new switch, nor of extending the 'triple' in some LDC-specific, non-LLVM-compatible way. Mainly because it's only useful for the few core.stdcpp modules and the according CppRuntime_* versions they require. If it was about linking only, that's already covered via -Xcc=--stdlib=... etc. The problem with the druntime modules is that they are precompiled using a specific CppRuntime_*, so a user cannot simply take a prebuilt LDC package and change the C++ runtime on the fly and expect everything to work; druntime has to be recompiled.
Extracting the few C++ stdlib bindings into a separate dub package, with e.g. dub configurations enabling to switch between libstdc++ and libc++ would IMO make much more sense.
Wrt. triples in general, even a C++ runtime addition wouldn't define a target platform sufficiently. We have to guess the used C compiler (gcc/clang) in some ABI-specific parts, where clang skips empty-struct parameters while gcc doesn't etc.
Sorry for the late reply, but this PR popped up while I was on vacation. - I'm not a big fan of a new switch, nor of extending the 'triple' in some LDC-specific, non-LLVM-compatible way. Mainly because it's only useful for the few
core.stdcppmodules and the accordingCppRuntime_*versions they require. If it was about linking only, that's already covered via-Xcc=--stdlib=...etc. The problem with the druntime modules is that they are precompiled using a specificCppRuntime_*, so a user cannot simply take a prebuilt LDC package and change the C++ runtime on the fly and expect everything to work; druntime has to be recompiled.Extracting the few C++ stdlib bindings into a separate dub package, with e.g. dub configurations enabling to switch between libstdc++ and libc++ would IMO make much more sense.
I agree about not adding this to the triple.
Splitting the stdlib bindings into a separate package makes sense, I think so too, but still requires a compiler change to not set a CppRuntime_* version at all and let the user explicitly -d-version=.. it (e.g. inside ldc2.conf file).
Adding a commandline flag or removing the hardcoded CppRuntime_* version (and put it in ldc2.conf by default) are the only short term solutions I see.
I fully agree with you guys, but Andrei didn't: https://github.com/dlang/druntime/pull/2286#issuecomment-416704437 I guess I will have to email him.
@kinke : I just found out that no CppRuntime is defined on Musl. Is that on purpose ?
Just no idea about the dominant C++ library for musl, uclibc, some BSDs… - I preferred defining none over a wild guess, in the hopes that people using such platforms would notice and open according PRs when trying to use core.stdcpp, instead of seeing crashes if the guess was bad. [Here, just in case: https://github.com/ldc-developers/ldc/blob/780d2966e99ebac168f7bd79ef8f1e5512573fd9/driver/main.cpp#L782]
Will do that soon (currently testing https://github.com/bosagora/docker-agora-builder/commit/e7fab4679eaff5c8149665a1385fd0ab4881d76f )