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