tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Selecting C and C++ compilers (was: Selecting a C++ compiler)
Wow, looks like we're making progress. Thanks for researching the dependency
rules.
> The last bit seems sufficient,
I don't think so (because of your third point). If an executable implemented
in C using a library with a C interface, but implemented in C++ needs to be
linked with the C++ version, then that's an additional requirement, no?
If I read your "C++ libraries" below as "libraries implemented in C++" that
that point covers this.
> but complicated.
I don't think so, either.
I can just duplicate the single-version-for-C++ logic, giving a
single-version-for-C logic and assure the latter version is not higher
than the former.
> So I think we ought to have a single chosen version of gcc for C.
Yes. And it appears we're doing it wrong, currently.
> I think the only two sensible choices are 1) the version used for C++ and
> 2) the base system version, preferring base if that doesn't lead to trouble.
While I aggree there's no point in a different choice, I guess it doen't
simplify the code in any way if we stick to that.
Ah, reading futher down the thread, there may indeed be a use case for a
third version: If your base GCC is incapable of compiling your C++ GCC,
then you may need an intermediate C GCC that your base GCC is able to
compile and that itself is able to compile your C++ GCC.
> C programs with GCC_REQD will also have to fail rather than upgrade,
That my to-be-copied logic would do.
> C++ libraries will have to set USE_LANGUAGES=c++ in their
> buildlink3.mk, to force the C compiler to be the chosen C++ one.
> Probably that's abuse and we need a new variable.
Would it be acceptable to have them simply add GCC_CXX_VERSION to GCC_REQD
or do you prefer an additional variable?
> The other thing to consider is bootstrapping.
I'll reply to that in another mail.
Home |
Main Index |
Thread Index |
Old Index