Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement --cppstdlib #3711

Closed
wants to merge 1 commit into from
Closed

Conversation

omerfirmak
Copy link
Contributor

This flag allows user to select from GCC/Clang C++ runtimes
on Linux similar to --stdlib on clang.

@thewilsonator
Copy link
Contributor

cc @Geod42

This will probably will be implemented upstream too

@Geod24
Copy link
Contributor

Geod24 commented May 3, 2021

I think that should be done through mtriple tho, if possible at all ?

@omerfirmak
Copy link
Contributor Author

AFAICS, llvm::triple does not have support for this.
Even clang has a separate flag for it.

@Geod24
Copy link
Contributor

Geod24 commented May 4, 2021

Then I guess -cppstdlib it is. What do you think @kinke ?

@thewilsonator
Copy link
Contributor

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.

driver/main.cpp Outdated Show resolved Hide resolved
@omerfirmak
Copy link
Contributor Author

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?

This flag allows user to select from GCC/Clang C++ runtimes
on Linux.
@kinke
Copy link
Member

kinke commented May 30, 2021

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.

@JohanEngelen
Copy link
Member

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.

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.

@Geod24
Copy link
Contributor

Geod24 commented May 31, 2021

I fully agree with you guys, but Andrei didn't: dlang/druntime#2286 (comment)
I guess I will have to email him.

@Geod24
Copy link
Contributor

Geod24 commented Jun 11, 2021

@kinke : I just found out that no CppRuntime is defined on Musl. Is that on purpose ?

@kinke
Copy link
Member

kinke commented Jun 11, 2021

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]

@Geod24
Copy link
Contributor

Geod24 commented Jun 11, 2021

Will do that soon (currently testing bosagora/docker-agora-builder@e7fab46 )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants