Re: discussion seeked for c++ variants in USE_LANGUAGES

[Richard PALO <richard%netbsd.org@localhost>]

Le 10/11/15 17:00, Greg Troxel a écrit :
> 
> Richard PALO <richard%netbsd.org@localhost> 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
> 
> https://mail-index.netbsd.org/tech-pkg/2015/09/25/msg015654.html
> 

oh, I really didn't follow that thread given it was about versions.
(I'm happy so far with GCC_REQD, probably because I use already gcc49)
But I'll take a closer look.

>>> 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.

Yes, that is more or less what I'm trying to point out.

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

Hmm, this must be the problem, because for me - this is the whole point of USE_LANGUAGES  with respect to the flavour of the compiler.
> 
>> 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/gcc.mk... 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?
> 

no, I believe we already balayed that earlier in this thread...

I'm suggesting that if we set gnu* in gcc, we should do the same with clang
as the gnu* stds are supported for compability.

READ: setting the standard with extensions in gcc but turning off extensions
in clang seems counter productive, more or less what joerg intimated as well.
perhaps -Wpedantic could be added for good measure.


>> 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.
> 

see previous

>>> 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?
> 

? normally that is why there is versioning.  for example, I'm using gcc 4.9 
which has:
> richard@omnis:/home/richard/src/pkgsrc/devel$ pvs /opt/pbulk32/gcc49/lib/libstdc++.so
> 	libm.so.2 (SUNW_1.2);
> 	librt.so.1 (SUNW_0.7);
> 	libgcc_s.so.1 (GCC_4.2.0);
> 	libc.so.1 (ILLUMOS_0.8, SUNWprivate_1.1);
> 	libstdc++.so.6;
> 	GLIBCXX_3.4;
> 	GLIBCXX_3.4.1;
> 	GLIBCXX_3.4.2;
> 	GLIBCXX_3.4.3;
> 	GLIBCXX_3.4.4;
> 	GLIBCXX_3.4.5;
> 	GLIBCXX_3.4.6;
> 	GLIBCXX_3.4.7;
> 	GLIBCXX_3.4.8;
> 	GLIBCXX_3.4.9;
> 	GLIBCXX_3.4.10;
> 	GLIBCXX_3.4.11;
> 	GLIBCXX_3.4.12;
> 	GLIBCXX_3.4.13;
> 	GLIBCXX_3.4.14;
> 	GLIBCXX_3.4.15;
> 	GLIBCXX_3.4.16;
> 	GLIBCXX_3.4.17;
> 	GLIBCXX_3.4.18;
> 	GLIBCXX_3.4.19;
> 	GLIBCXX_3.4.20;
> 	CXXABI_1.3;
> 	CXXABI_1.3.1;
> 	CXXABI_1.3.2;
> 	CXXABI_1.3.3;
> 	CXXABI_1.3.4;
> 	CXXABI_1.3.5;
> 	CXXABI_1.3.6;
> 	CXXABI_1.3.7;
> 	CXXABI_1.3.8;
> 	CXXABI_TM_1;

If I look at the OmniOS system supplied gcc 5.1 library:
> richard@omnis:/home/richard/src/pkgsrc/devel$ pvs /usr/lib/libstdc++.so
> 	libm.so.2 (SUNW_1.2);
> 	libgcc_s.so.1 (GCC_4.2.0);
> 	libc.so.1 (ILLUMOS_0.8, SUNWprivate_1.1);
> 	libstdc++.so.6;
> 	GLIBCXX_3.4;
> 	GLIBCXX_3.4.1;
> 	GLIBCXX_3.4.2;
> 	GLIBCXX_3.4.3;
> 	GLIBCXX_3.4.4;
> 	GLIBCXX_3.4.5;
> 	GLIBCXX_3.4.6;
> 	GLIBCXX_3.4.7;
> 	GLIBCXX_3.4.8;
> 	GLIBCXX_3.4.9;
> 	GLIBCXX_3.4.10;
> 	GLIBCXX_3.4.11;
> 	GLIBCXX_3.4.12;
> 	GLIBCXX_3.4.13;
> 	GLIBCXX_3.4.14;
> 	GLIBCXX_3.4.15;
> 	GLIBCXX_3.4.16;
> 	GLIBCXX_3.4.17;
> 	GLIBCXX_3.4.18;
> 	GLIBCXX_3.4.19;
> 	GLIBCXX_3.4.20;
> 	GLIBCXX_3.4.21;
> 	CXXABI_1.3;
> 	CXXABI_1.3.1;
> 	CXXABI_1.3.2;
> 	CXXABI_1.3.3;
> 	CXXABI_1.3.4;
> 	CXXABI_1.3.5;
> 	CXXABI_1.3.6;
> 	CXXABI_1.3.7;
> 	CXXABI_1.3.8;
> 	CXXABI_1.3.9;
> 	CXXABI_TM_1;
> 	CXXABI_FLOAT128;

granted my platform is SunOS using the native and not gnu ld, but that really shouldn't change too much with gnu ld.

The issue with multiple versions is more mixing calls in libraries where the 
ABI has changed.

This article discusses a bit the abi issues: 
http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/

BTW, as I mentioned earlier, I believe too that we should consider explicitly 
set the defaults for 'c' and 'c++' to -std=gnu89 and -std=gnu++98 respectfully 
as the compiler defaults changed recently, at least they have for gcc5.
This, naturally, to avoid surprises to the pkgsrc community having a wide variety of compilers in use.

>> 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.
> 
This means simply I haven't seen any packages requiring the pkgsrc Makefile
to specify -std=c++14 (or gnu++14)... although there are a number of packages
setting -std=c++11 (or gnu++11) so as far as pkgsrc is concerned, I believe it 
to be a moot issue and finally probably best not to add it at the moment.

-- 
Richard PALO