tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: discussion seeked for c++ variants in USE_LANGUAGES

Richard PALO <> writes:

> Le 09/11/15 14:38, Greg Troxel a écrit :
>> I object, at least for now, becuase this is inconsistent with the
>> emerging consensus from the ongoing discussion.
> I guess I missed something, I can't find but two observations from
> joerg and one from you not mentioning any of the below... sorry:[

See the big thread at

>> As I understand it, the biggest issue is that one cannot really use
>> multiple C++ compilers on a given system at the same time.  Then, given
>> that c++11 is now more or less normal, we should just let the c++ value
>> imply c++11, and more or less consider any pre-c++11 C++ compiler to be
>> defective.
>> So that more or less means that if the system gcc is 4.8 (4.7?) or
>> newer, then we use it, otherwise we force 4.8, but via a variable that
>> the user can set to pick a different value, intended to be set once,
>> conceptually at bootsrap time.
> I believe this is even potentially worse now that you can [easily] switch c++ 
> libraries with clang. 

Yes, it may be.

> Is it non trivial to mix libstdc++ and libc++, even with the same compiler? 

I am not sure.  But overall there seems to be a notion that one has to
choose a compiler/library and then stick with it.

> I still feel there is need to be able to easily set -std= just like c99 does.

That is perhaps a separable issue.

> Perhaps one of the real issues is that the patchset updates GCC_REQD
> based upon these settings...
> I remind I only added upon existing scripts... 
> I'd be happy to yank updating GCC_REQD from the proposed patchset... 
> Although judging from your comments, there seems to be quite a bit
> that perhaps needs to be revisted in compiler/ but that's
> beside the point here.

Agreed; this is all in need of major revisions.

> Also, just to get back to the patchset, since clang supports the
> -std=gnu*, perhaps both gcc and clang should use the -std=gnu* form.

Are you suggesting allowing gnu99 in USE_LANGUAGES, as a dialect?

> Is there any palpable reason to disable extensions if the package
> itself doesn't?  Joerg's comment seems to go follow this reasoning.

I could see wanting to disable them if the language with extensions
isn't defined, but I'm not sure that's useful.

>> I don't follow how having c++11 and c++14 both is going to lead to
>> working packages as a non-trivial number of packages need them and link
>> with each other.
> I believe these have mostly to do with the features expected in the compiler.
> ABI issues are *already* a subject since post c++98... no difference,really.

What I meant is if one uses gcc 4.8 for some and 5.1 for some, how is
that going to work?  And if we dont' mix versions, what does "requiring
c++14" mean?

> Having both c++11 and c++14 means that they are simply available to packages that
> need them, not necessarily to enforce using them. That said, I have no 
> personal need requiring it now, it was mainly for completeness.

I really don't understand what that means in practice in terms of
compiler selection.

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index