Re: Mandates explicit -std=c++XY for c++ projects

[Wouter Verhelst]

On Tue, Oct 10, 2017 at 09:26:07AM -0400, Michael Stone wrote:
> On Tue, Oct 10, 2017 at 02:16:36PM +0100, Dimitri John Ledkov wrote:
> > On 10 October 2017 at 14:07, Gert Wollny  wrote:
> > > I think nobody would object if you set the flag to -std=c++98 for a
> > > certain package, especially if upstream is dead or unwilling to move to
> > > a newer standard, but I wouldn't want to see it as the default.
> > > 
> > 
> > We, as a distribution, are better than that. Please provide URLs to
> > FTBFS with c++11 bug report that is of concern for you, and I will try
> > to look into it to fix the FTBFS with a distro patch.
> 
> I would hope that debian wouldn't fork a package specifically to change the
> c++ standards version over upstream objections. That sounds like a long term
> maintainence nightmare in itself.

Actually, in most cases that I've seen, upstream cares more about *also*
supporting older standards (for the benefit of users using older
distributions whose default compiler doesn't yet support the newer
standard) than they care about the default standard in use.

I think this question originated from a desire to manage C++ ABIs
better. It's true that introducing a new C++ compiler which defaults to
a different ABI will cause issues if not handled properly. However, we
already have plenty of tooling in place to manage ABI differences, and I
don't think this adds much.

Currently, when the default C++ compiler changes ABI, what's needed is a
coordinated transition where every C++ library package is updated in
turn. Adding a default C++ ABI at the package level does not change
that, and therefore I don't think we need to introduce it.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Mandates explicit -std=c++XY for c++ projects

[Mathieu Malaterre]

On Tue, Oct 10, 2017 at 3:05 PM, Matthias Klose  wrote:
> On 10.10.2017 12:38, Mathieu Malaterre wrote:
>> Mathias,
>>
>> On Tue, Oct 10, 2017 at 12:25 PM, Matthias Klose  wrote:
>>> On 10.10.2017 11:42, Mathieu Malaterre wrote:
 On Tue, Oct 10, 2017 at 11:38 AM, Matthias Klose  wrote:
> On 10.10.2017 08:45, Mathieu Malaterre wrote:
>> Dear all,
>>
>> Since the GCC 6 release [1], the default mode for C++ is now
>> -std=gnu++14 instead of -std=gnu++98. What this means is that upon
>> (re)compilation a library written for c++98 will be recompiled using a
>> different c++ standard (c++14 in this case), unless of course the
>> upstream package explicitly set the -std= flags with the appropriate
>> c++ version.
>>
>> The ISO committee generally describe the change in between different
>> standards [2] and in some case, one can find examples of subtle change
>> in behaviors [3] and [4].
>>
>> With this mind I'd like to make mandatory the -std=c++XY flags when
>> compiling either a c++ library or a stand-alone c++ program:
>>
>> 1. Either upstream define the explicit -std=c++XY flags by mean of its
>> build system,
>> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
>> pass the appropriate version of the c++ standard. In which case this
>> should be documented in the README.Debian file.
>> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
>>
>> If there is a consensus on the following change, I'll go ahead and
>> also file a bug for lintian to scan the compilation logs in search for
>> missing -std=c++ expression when g++ command line are issued.
>
> I don't think this is a good idea, and I'm still trying to understand what
> problem you are trying to solve.  It took a while until GCC had stable 
> c++11
> support, and now you want to fallback to a 20 year old standard by 
> default?

 As said above, this is simply a fallback, I am fine with any value as
 long as I can see it in the log clearly.

 My point was about making the flag *explicit*, whatever value is
 chosen, so that upon recompilation we gets the same symbols, the same
 behavior, no FTBFS (because of deprecated feature).
>>>
>>> Various libraries do error out on deprecated functions/macros, which you can
>>> override by preprocessor macros.  This is usually done in the package.  Why
>>> should that be different for the compiler?
>>>
> It would be better to spend some time to prepare for -std=gnu++17 instead 
> ;)

 So you have no major objection against my proposal,
>>>
>>> No, I have objections, because after a while this will become a debt to 
>>> maintain ...
>>
>> Thanks for taking the time to answer.
>>
>> As with Gert's answer, I fail to understand your point: You would
>> prefer to see packages being (re)compiled *without* an explicit -std=
>> flag, so that it always gets recompiled using whatever is the current
>> c++ standard used by gcc, correct ?
>
> yes, that's what we do with every package, so why do you want to have an
> exception here?

True. That was the root of my confusion, a change in the c++ language
is simply just like a change in the API (or ABI).

 I feared you may
 have an issue with mixed combination of stdc++ runtime lib (not sure
 exactly how this is handled at low level).
>>>
>>> There's only one runtime library in use. Yes, there are more or less subtle
>>> issues which we address by library package renames for issues we cannot or 
>>> do
>>> not want to handle by renaming libstdc++ itself.  But it's always the same
>>> runtime library used, independent of the standard.
>>
>> Ah nice.
>>
>> I may be slamming open door, but could you confirm that you see no
>> objection in maintaining a complex stdc++ package where the c++98 ABI
>> (eg. std::string) will not be used by any packages in the near future.
>
> yes, if you either make sure that everything using this library is using 
> c++98,
> or that this library provides a layer that it can interact with both
> std::string[c++89] and std::string[c++11].  However afaik no upstream besides
> libstdc++ has done that.  Again, I don't mind doing that on a package level, 
> but
> it shouldn't be any fallback to use an old standard.

Great, this means users can compile a project using a mixture of both ABI.

All these defeat the reason for my initial proposal :)

Thanks all for your comments,
-M

Re: Mandates explicit -std=c++XY for c++ projects

[Michael Stone]

On Tue, Oct 10, 2017 at 05:36:47PM +0100, Dimitri John Ledkov wrote:

On 10 October 2017 at 14:26, Michael Stone  wrote:

On Tue, Oct 10, 2017 at 02:16:36PM +0100, Dimitri John Ledkov wrote:


On 10 October 2017 at 14:07, Gert Wollny  wrote:


I think nobody would object if you set the flag to -std=c++98 for a
certain package, especially if upstream is dead or unwilling to move to
a newer standard, but I wouldn't want to see it as the default.



We, as a distribution, are better than that. Please provide URLs to
FTBFS with c++11 bug report that is of concern for you, and I will try
to look into it to fix the FTBFS with a distro patch.



I would hope that debian wouldn't fork a package specifically to change the
c++ standards version over upstream objections. That sounds like a long term
maintainence nightmare in itself.



Which upstream? URLs to upstream bug reports would be considered by me as well.


Well, the hypothetical you responded to said "especially if upstream is 
dead or unwilling to move to a newer standard". So, in context, I think 
there's more to consider than "can someone pound out a quick patch".


Mike Stone

Re: Mandates explicit -std=c++XY for c++ projects

[Dimitri John Ledkov]

On 10 October 2017 at 14:26, Michael Stone  wrote:
> On Tue, Oct 10, 2017 at 02:16:36PM +0100, Dimitri John Ledkov wrote:
>>
>> On 10 October 2017 at 14:07, Gert Wollny  wrote:
>>>
>>> I think nobody would object if you set the flag to -std=c++98 for a
>>> certain package, especially if upstream is dead or unwilling to move to
>>> a newer standard, but I wouldn't want to see it as the default.
>>>
>>
>> We, as a distribution, are better than that. Please provide URLs to
>> FTBFS with c++11 bug report that is of concern for you, and I will try
>> to look into it to fix the FTBFS with a distro patch.
>
>
> I would hope that debian wouldn't fork a package specifically to change the
> c++ standards version over upstream objections. That sounds like a long term
> maintainence nightmare in itself.
>

Which upstream? URLs to upstream bug reports would be considered by me as well.

I am happy to talk to them and upstream patches that would be
acceptable to them.

Most build systems to build-time configuration to check if compiler's
default standards version is at least this much, and if not does it
support this much, and in that case it adds flags to force
higher/newer standards version. This sometimes causes integration
issues downstream in the distributions, but that bit is totally within
the realm of the distribution to fix / ignore / work-around as needed.

> If upstream is dead that's a different story, but should really involve
> serious thought about whether becoming upstream is better than removing the
> package.
> Mike Stone
>

-- 
Regards,

Dimitri.

Re: Mandates explicit -std=c++XY for c++ projects

[Michael Stone]

On Tue, Oct 10, 2017 at 02:16:36PM +0100, Dimitri John Ledkov wrote:

On 10 October 2017 at 14:07, Gert Wollny  wrote:

I think nobody would object if you set the flag to -std=c++98 for a
certain package, especially if upstream is dead or unwilling to move to
a newer standard, but I wouldn't want to see it as the default.



We, as a distribution, are better than that. Please provide URLs to
FTBFS with c++11 bug report that is of concern for you, and I will try
to look into it to fix the FTBFS with a distro patch.


I would hope that debian wouldn't fork a package specifically to change 
the c++ standards version over upstream objections. That sounds like a 
long term maintainence nightmare in itself.


If upstream is dead that's a different story, but should really involve 
serious thought about whether becoming upstream is better than removing 
the package. 


Mike Stone

Re: Mandates explicit -std=c++XY for c++ projects

[Dimitri John Ledkov]

On 10 October 2017 at 14:07, Gert Wollny  wrote:
> Hello Mathieu,
>
> Am Dienstag, den 10.10.2017, 11:45 +0200 schrieb Mathieu Malaterre:
> [...]
> I don't think there is much to gain from it. Whenever there is a
> change
>> > in the major version of gcc/g++ many bugs show up and all involved
>> > really do a great job fixing these. IMHO switching from an older
>> > C++ standard to a newer one is no different. In fact, I think that
>> > this forced change is an excellent incentive to review older
>> > packages.
>>
>> Right. I have the exact opposite view: why compile a c++ project
>> using c++11 flags while it was written for c++98...
>
> Like I pointed out I think it is somewhat the same like with new
> compilers: New compilers interpret the standard more strict, optimize
> differently, and hence, we get build failures and test failures that we
> need to fix. The same it is when moving from one standard to the next.
>
> You also consider that upstream is active and willing to migrate from
>> c++98 toward c++11 (for example), I had the exact opposite example in
>> mind.
> I think nobody would object if you set the flag to -std=c++98 for a
> certain package, especially if upstream is dead or unwilling to move to
> a newer standard, but I wouldn't want to see it as the default.
>

We, as a distribution, are better than that. Please provide URLs to
FTBFS with c++11 bug report that is of concern for you, and I will try
to look into it to fix the FTBFS with a distro patch.

> [...]
>> > I think we should strife for all packages using the
>> > same C++ standard, and this should be the default of the currently
>> > used C++ compiler. Forcing a lower standard on a package as a
>> > maintainer I would consider only as a (temporal) workaround to fix
>> > RC bugs, and preferable only for leaf packages.
>>
>> I do not see you point clearly. Let me rephrase it then: You would
>> like to see no explicit -std=c++ in the build logs, so as to
>> guarantee we always compile a c++ project using whatever default c++
>> standard is being used by the current gcc version. Is this a correct
>> rephrasing ?
> Yes.
>
> I wouldn't mind, though, if there was some output from the compiler
> that indicates what standard was used to compile a package, but that's
> different from setting a standard explicitly.
>
> Best,
> Gert
>

-- 
Regards,

Dimitri.

Re: Mandates explicit -std=c++XY for c++ projects

[Dimitri John Ledkov]

On 10 October 2017 at 07:45, Mathieu Malaterre  wrote:
> Dear all,
>
> Since the GCC 6 release [1], the default mode for C++ is now
> -std=gnu++14 instead of -std=gnu++98. What this means is that upon
> (re)compilation a library written for c++98 will be recompiled using a
> different c++ standard (c++14 in this case), unless of course the
> upstream package explicitly set the -std= flags with the appropriate
> c++ version.
>
> The ISO committee generally describe the change in between different
> standards [2] and in some case, one can find examples of subtle change
> in behaviors [3] and [4].
>
> With this mind I'd like to make mandatory the -std=c++XY flags when
> compiling either a c++ library or a stand-alone c++ program:
>
> 1. Either upstream define the explicit -std=c++XY flags by mean of its
> build system,
> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
> pass the appropriate version of the c++ standard. In which case this
> should be documented in the README.Debian file.
> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
>
> If there is a consensus on the following change, I'll go ahead and
> also file a bug for lintian to scan the compilation logs in search for
> missing -std=c++ expression when g++ command line are issued.

I wholeheartedly object. A given debian release has a defined default
ABI with a minimum CPU requirements per architecture. Currently, in
sid, it is C++11 abi. The way ABI works is that it forward compatible,
but not backwards. Therefore generally binaries compiled on older
releases are copied forward to newer releases and work fine (as long
as the depencies are still satisfiable, sans ocational bugs). Note
there are ABI fixes too, such that something compiled with c++98
standard in sid, is not guaranteed to have the same code generated nor
work with older runtime (e.g. old-stable). It does work for simplistic
cases however.

If you target and older release, and need a backport of a newer
software package it not acceptable to demand lowing std version in sid
such that packages are instalabble in older releases. As a
distribution, we cannot guarantee that to work.

In general, software should be written portable, and the default
standards version should be in use which is currently dictated by the
default compiler and thus maintainers of the default compilers in
Debian.

Specifically, there are many software packages in the archive that
compile correctly with both newer and older standards, and do
configure/compile time checking and take advantange of the newly
available standards features, instead of using embedded copies of code
/ adding additional libraries. There are many packages that use c++11
features, instead of including and linking boost libraries. Similarly
for C, there are packages that use standards available
alignment/padding/atomic functions, instead of using hand-crafted
embedded (often buggy in corner cases). Overall, it leads to software
packages reusing more shared code, as more things are available in the
standards (or streamlined in standards).

boost will continue to compile with the default C++ standards version,
and thus reverse-dependencies are also expected to use the matching /
default standards version. I have been pondering to provide stdc++98
and stdc++11 abi builds of boost, but that is a lot of code
duplication for effectively diminishing returns over time.

Encoding stdc++ version in the packages, will make them
non-binNMU-safe and thus will start to require sourcefull upload for
boost transitions which is a lot of packages.

If you have any examples of things failing to build due to change from
98 to 11 in unstable, I'd rather volunteer to fix that, rather than
hardcode the world to use old standards.

Using lowest common denominator will results in inefficient, large,
under-optimised binaries. One really should recompile software for
each distribution release toolchain.

-- 
Regards,

Dimitri.

Re: Mandates explicit -std=c++XY for c++ projects

[Gert Wollny]

Hello Mathieu, 

Am Dienstag, den 10.10.2017, 11:45 +0200 schrieb Mathieu Malaterre:
[...]
I don't think there is much to gain from it. Whenever there is a
change
> > in the major version of gcc/g++ many bugs show up and all involved
> > really do a great job fixing these. IMHO switching from an older
> > C++ standard to a newer one is no different. In fact, I think that
> > this forced change is an excellent incentive to review older
> > packages.
> 
> Right. I have the exact opposite view: why compile a c++ project
> using c++11 flags while it was written for c++98...

Like I pointed out I think it is somewhat the same like with new
compilers: New compilers interpret the standard more strict, optimize
differently, and hence, we get build failures and test failures that we
need to fix. The same it is when moving from one standard to the next. 

You also consider that upstream is active and willing to migrate from
> c++98 toward c++11 (for example), I had the exact opposite example in
> mind.
I think nobody would object if you set the flag to -std=c++98 for a
certain package, especially if upstream is dead or unwilling to move to
a newer standard, but I wouldn't want to see it as the default.

[...]
> > I think we should strife for all packages using the
> > same C++ standard, and this should be the default of the currently
> > used C++ compiler. Forcing a lower standard on a package as a
> > maintainer I would consider only as a (temporal) workaround to fix
> > RC bugs, and preferable only for leaf packages.
> 
> I do not see you point clearly. Let me rephrase it then: You would
> like to see no explicit -std=c++ in the build logs, so as to
> guarantee we always compile a c++ project using whatever default c++
> standard is being used by the current gcc version. Is this a correct
> rephrasing ?
Yes. 

I wouldn't mind, though, if there was some output from the compiler
that indicates what standard was used to compile a package, but that's
different from setting a standard explicitly. 

Best,
Gert 

Re: Mandates explicit -std=c++XY for c++ projects

[Matthias Klose]

On 10.10.2017 12:38, Mathieu Malaterre wrote:
> Mathias,
> 
> On Tue, Oct 10, 2017 at 12:25 PM, Matthias Klose  wrote:
>> On 10.10.2017 11:42, Mathieu Malaterre wrote:
>>> On Tue, Oct 10, 2017 at 11:38 AM, Matthias Klose  wrote:
 On 10.10.2017 08:45, Mathieu Malaterre wrote:
> Dear all,
>
> Since the GCC 6 release [1], the default mode for C++ is now
> -std=gnu++14 instead of -std=gnu++98. What this means is that upon
> (re)compilation a library written for c++98 will be recompiled using a
> different c++ standard (c++14 in this case), unless of course the
> upstream package explicitly set the -std= flags with the appropriate
> c++ version.
>
> The ISO committee generally describe the change in between different
> standards [2] and in some case, one can find examples of subtle change
> in behaviors [3] and [4].
>
> With this mind I'd like to make mandatory the -std=c++XY flags when
> compiling either a c++ library or a stand-alone c++ program:
>
> 1. Either upstream define the explicit -std=c++XY flags by mean of its
> build system,
> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
> pass the appropriate version of the c++ standard. In which case this
> should be documented in the README.Debian file.
> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
>
> If there is a consensus on the following change, I'll go ahead and
> also file a bug for lintian to scan the compilation logs in search for
> missing -std=c++ expression when g++ command line are issued.

 I don't think this is a good idea, and I'm still trying to understand what
 problem you are trying to solve.  It took a while until GCC had stable 
 c++11
 support, and now you want to fallback to a 20 year old standard by default?
>>>
>>> As said above, this is simply a fallback, I am fine with any value as
>>> long as I can see it in the log clearly.
>>>
>>> My point was about making the flag *explicit*, whatever value is
>>> chosen, so that upon recompilation we gets the same symbols, the same
>>> behavior, no FTBFS (because of deprecated feature).
>>
>> Various libraries do error out on deprecated functions/macros, which you can
>> override by preprocessor macros.  This is usually done in the package.  Why
>> should that be different for the compiler?
>>
 It would be better to spend some time to prepare for -std=gnu++17 instead 
 ;)
>>>
>>> So you have no major objection against my proposal,
>>
>> No, I have objections, because after a while this will become a debt to 
>> maintain ...
> 
> Thanks for taking the time to answer.
> 
> As with Gert's answer, I fail to understand your point: You would
> prefer to see packages being (re)compiled *without* an explicit -std=
> flag, so that it always gets recompiled using whatever is the current
> c++ standard used by gcc, correct ?

yes, that's what we do with every package, so why do you want to have an
exception here?

>>> I feared you may
>>> have an issue with mixed combination of stdc++ runtime lib (not sure
>>> exactly how this is handled at low level).
>>
>> There's only one runtime library in use. Yes, there are more or less subtle
>> issues which we address by library package renames for issues we cannot or do
>> not want to handle by renaming libstdc++ itself.  But it's always the same
>> runtime library used, independent of the standard.
> 
> Ah nice.
> 
> I may be slamming open door, but could you confirm that you see no
> objection in maintaining a complex stdc++ package where the c++98 ABI
> (eg. std::string) will not be used by any packages in the near future.

yes, if you either make sure that everything using this library is using c++98,
or that this library provides a layer that it can interact with both
std::string[c++89] and std::string[c++11].  However afaik no upstream besides
libstdc++ has done that.  Again, I don't mind doing that on a package level, but
it shouldn't be any fallback to use an old standard.

Matthias

Re: Mandates explicit -std=c++XY for c++ projects

[Michael Stone]

On Tue, Oct 10, 2017 at 12:38:03PM +0200, Mathieu Malaterre wrote:

As with Gert's answer, I fail to understand your point: You would
prefer to see packages being (re)compiled *without* an explicit -std=
flag, so that it always gets recompiled using whatever is the current
c++ standard used by gcc, correct ?


Yes. Just as I expect packages to compile with the current gcc--even 
though we know that changing gcc version always causes at least some new 
bugs. The bugs get fixed, the world moves on. In the case that a 
particular package needs a specific set of build flags, they can be 
added on a per-package basis. If there's a package that can't build with 
the current compiler, and nobody has enough interest in the package and
ability to fix the bugs, then the package is probably a good candidate 
for removal anyway.


Mike Stone

Re: Mandates explicit -std=c++XY for c++ projects

[Mathieu Malaterre]

Mathias,

On Tue, Oct 10, 2017 at 12:25 PM, Matthias Klose  wrote:
> On 10.10.2017 11:42, Mathieu Malaterre wrote:
>> On Tue, Oct 10, 2017 at 11:38 AM, Matthias Klose  wrote:
>>> On 10.10.2017 08:45, Mathieu Malaterre wrote:
 Dear all,

 Since the GCC 6 release [1], the default mode for C++ is now
 -std=gnu++14 instead of -std=gnu++98. What this means is that upon
 (re)compilation a library written for c++98 will be recompiled using a
 different c++ standard (c++14 in this case), unless of course the
 upstream package explicitly set the -std= flags with the appropriate
 c++ version.

 The ISO committee generally describe the change in between different
 standards [2] and in some case, one can find examples of subtle change
 in behaviors [3] and [4].

 With this mind I'd like to make mandatory the -std=c++XY flags when
 compiling either a c++ library or a stand-alone c++ program:

 1. Either upstream define the explicit -std=c++XY flags by mean of its
 build system,
 2. Or the package maintainers needs to explicit change the CXXFLAGS to
 pass the appropriate version of the c++ standard. In which case this
 should be documented in the README.Debian file.
 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98

 If there is a consensus on the following change, I'll go ahead and
 also file a bug for lintian to scan the compilation logs in search for
 missing -std=c++ expression when g++ command line are issued.
>>>
>>> I don't think this is a good idea, and I'm still trying to understand what
>>> problem you are trying to solve.  It took a while until GCC had stable c++11
>>> support, and now you want to fallback to a 20 year old standard by default?
>>
>> As said above, this is simply a fallback, I am fine with any value as
>> long as I can see it in the log clearly.
>>
>> My point was about making the flag *explicit*, whatever value is
>> chosen, so that upon recompilation we gets the same symbols, the same
>> behavior, no FTBFS (because of deprecated feature).
>
> Various libraries do error out on deprecated functions/macros, which you can
> override by preprocessor macros.  This is usually done in the package.  Why
> should that be different for the compiler?
>
>>> It would be better to spend some time to prepare for -std=gnu++17 instead ;)
>>
>> So you have no major objection against my proposal,
>
> No, I have objections, because after a while this will become a debt to 
> maintain ...

Thanks for taking the time to answer.

As with Gert's answer, I fail to understand your point: You would
prefer to see packages being (re)compiled *without* an explicit -std=
flag, so that it always gets recompiled using whatever is the current
c++ standard used by gcc, correct ?

>> I feared you may
>> have an issue with mixed combination of stdc++ runtime lib (not sure
>> exactly how this is handled at low level).
>
> There's only one runtime library in use. Yes, there are more or less subtle
> issues which we address by library package renames for issues we cannot or do
> not want to handle by renaming libstdc++ itself.  But it's always the same
> runtime library used, independent of the standard.

Ah nice.

I may be slamming open door, but could you confirm that you see no
objection in maintaining a complex stdc++ package where the c++98 ABI
(eg. std::string) will not be used by any packages in the near future.

Re: Mandates explicit -std=c++XY for c++ projects

[Matthias Klose]

On 10.10.2017 11:42, Mathieu Malaterre wrote:
> On Tue, Oct 10, 2017 at 11:38 AM, Matthias Klose  wrote:
>> On 10.10.2017 08:45, Mathieu Malaterre wrote:
>>> Dear all,
>>>
>>> Since the GCC 6 release [1], the default mode for C++ is now
>>> -std=gnu++14 instead of -std=gnu++98. What this means is that upon
>>> (re)compilation a library written for c++98 will be recompiled using a
>>> different c++ standard (c++14 in this case), unless of course the
>>> upstream package explicitly set the -std= flags with the appropriate
>>> c++ version.
>>>
>>> The ISO committee generally describe the change in between different
>>> standards [2] and in some case, one can find examples of subtle change
>>> in behaviors [3] and [4].
>>>
>>> With this mind I'd like to make mandatory the -std=c++XY flags when
>>> compiling either a c++ library or a stand-alone c++ program:
>>>
>>> 1. Either upstream define the explicit -std=c++XY flags by mean of its
>>> build system,
>>> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
>>> pass the appropriate version of the c++ standard. In which case this
>>> should be documented in the README.Debian file.
>>> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
>>>
>>> If there is a consensus on the following change, I'll go ahead and
>>> also file a bug for lintian to scan the compilation logs in search for
>>> missing -std=c++ expression when g++ command line are issued.
>>
>> I don't think this is a good idea, and I'm still trying to understand what
>> problem you are trying to solve.  It took a while until GCC had stable c++11
>> support, and now you want to fallback to a 20 year old standard by default?
> 
> As said above, this is simply a fallback, I am fine with any value as
> long as I can see it in the log clearly.
> 
> My point was about making the flag *explicit*, whatever value is
> chosen, so that upon recompilation we gets the same symbols, the same
> behavior, no FTBFS (because of deprecated feature).

Various libraries do error out on deprecated functions/macros, which you can
override by preprocessor macros.  This is usually done in the package.  Why
should that be different for the compiler?

>> It would be better to spend some time to prepare for -std=gnu++17 instead ;)
> 
> So you have no major objection against my proposal,

No, I have objections, because after a while this will become a debt to 
maintain ...

> I feared you may
> have an issue with mixed combination of stdc++ runtime lib (not sure
> exactly how this is handled at low level).

There's only one runtime library in use. Yes, there are more or less subtle
issues which we address by library package renames for issues we cannot or do
not want to handle by renaming libstdc++ itself.  But it's always the same
runtime library used, independent of the standard.

Matthias

Re: Mandates explicit -std=c++XY for c++ projects

[Mathieu Malaterre]

Hi Gert !

On Tue, Oct 10, 2017 at 11:31 AM, Gert Wollny  wrote:
> Am Dienstag, den 10.10.2017, 08:45 +0200 schrieb Mathieu Malaterre:
>
> [...]
> With this mind I'd like to make mandatory the -std=c++XY flags when
>> compiling either a c++ library or a stand-alone c++ program:
>>
>> 1. Either upstream define the explicit -std=c++XY flags by mean of
>> its build system,
>> 2. Or the package maintainers needs to explicit change the CXXFLAGS
>> to pass the appropriate version of the c++ standard. In which case
>> this should be documented in the README.Debian file.
>
> I don't think there is much to gain from it. Whenever there is a change
> in the major version of gcc/g++ many bugs show up and all involved
> really do a great job fixing these. IMHO switching from an older C++
> standard to a newer one is no different. In fact, I think that this
> forced change is an excellent incentive to review older packages.

Right. I have the exact opposite view: why compile a c++ project using
c++11 flags while it was written for c++98...
You also consider that upstream is active and willing to migrate from
c++98 toward c++11 (for example), I had the exact opposite example in
mind.

>> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
>
> Why would you pick such an old standard as the default? Also note that
> at least with boost there were instances where the ABI changed
> depending on whether C++11 or higher was enabled or not. - Also for
> that reason I think we should strife for all packages using the same
> C++ standard, and this should be the default of the currently used C++
> compiler. Forcing a lower standard on a package as a maintainer I would
> consider only as a (temporal) workaround to fix RC bugs, and preferable
> only for leaf packages.

I do not see you point clearly. Let me rephrase it then: You would
like to see no explicit -std=c++ in the build logs, so as to guarantee
we always compile a c++ project using whatever default c++ standard is
being used by the current gcc version. Is this a correct rephrasing ?

-M

Re: Mandates explicit -std=c++XY for c++ projects

[Matthias Klose]

On 10.10.2017 08:45, Mathieu Malaterre wrote:
> Dear all,
> 
> Since the GCC 6 release [1], the default mode for C++ is now
> -std=gnu++14 instead of -std=gnu++98. What this means is that upon
> (re)compilation a library written for c++98 will be recompiled using a
> different c++ standard (c++14 in this case), unless of course the
> upstream package explicitly set the -std= flags with the appropriate
> c++ version.
> 
> The ISO committee generally describe the change in between different
> standards [2] and in some case, one can find examples of subtle change
> in behaviors [3] and [4].
> 
> With this mind I'd like to make mandatory the -std=c++XY flags when
> compiling either a c++ library or a stand-alone c++ program:
> 
> 1. Either upstream define the explicit -std=c++XY flags by mean of its
> build system,
> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
> pass the appropriate version of the c++ standard. In which case this
> should be documented in the README.Debian file.
> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
> 
> If there is a consensus on the following change, I'll go ahead and
> also file a bug for lintian to scan the compilation logs in search for
> missing -std=c++ expression when g++ command line are issued.

I don't think this is a good idea, and I'm still trying to understand what
problem you are trying to solve.  It took a while until GCC had stable c++11
support, and now you want to fallback to a 20 year old standard by default?

It would be better to spend some time to prepare for -std=gnu++17 instead ;)

Matthias

Re: Mandates explicit -std=c++XY for c++ projects

[Mathieu Malaterre]

On Tue, Oct 10, 2017 at 11:38 AM, Matthias Klose  wrote:
> On 10.10.2017 08:45, Mathieu Malaterre wrote:
>> Dear all,
>>
>> Since the GCC 6 release [1], the default mode for C++ is now
>> -std=gnu++14 instead of -std=gnu++98. What this means is that upon
>> (re)compilation a library written for c++98 will be recompiled using a
>> different c++ standard (c++14 in this case), unless of course the
>> upstream package explicitly set the -std= flags with the appropriate
>> c++ version.
>>
>> The ISO committee generally describe the change in between different
>> standards [2] and in some case, one can find examples of subtle change
>> in behaviors [3] and [4].
>>
>> With this mind I'd like to make mandatory the -std=c++XY flags when
>> compiling either a c++ library or a stand-alone c++ program:
>>
>> 1. Either upstream define the explicit -std=c++XY flags by mean of its
>> build system,
>> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
>> pass the appropriate version of the c++ standard. In which case this
>> should be documented in the README.Debian file.
>> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
>>
>> If there is a consensus on the following change, I'll go ahead and
>> also file a bug for lintian to scan the compilation logs in search for
>> missing -std=c++ expression when g++ command line are issued.
>
> I don't think this is a good idea, and I'm still trying to understand what
> problem you are trying to solve.  It took a while until GCC had stable c++11
> support, and now you want to fallback to a 20 year old standard by default?

As said above, this is simply a fallback, I am fine with any value as
long as I can see it in the log clearly.

My point was about making the flag *explicit*, whatever value is
chosen, so that upon recompilation we gets the same symbols, the same
behavior, no FTBFS (because of deprecated feature).

> It would be better to spend some time to prepare for -std=gnu++17 instead ;)

So you have no major objection against my proposal, I feared you may
have an issue with mixed combination of stdc++ runtime lib (not sure
exactly how this is handled at low level).

Re: Mandates explicit -std=c++XY for c++ projects

[Gert Wollny]

Am Dienstag, den 10.10.2017, 08:45 +0200 schrieb Mathieu Malaterre:

[...]
With this mind I'd like to make mandatory the -std=c++XY flags when
> compiling either a c++ library or a stand-alone c++ program:
>
> 1. Either upstream define the explicit -std=c++XY flags by mean of
> its build system,
> 2. Or the package maintainers needs to explicit change the CXXFLAGS
> to pass the appropriate version of the c++ standard. In which case
> this should be documented in the README.Debian file.

I don't think there is much to gain from it. Whenever there is a change
in the major version of gcc/g++ many bugs show up and all involved
really do a great job fixing these. IMHO switching from an older C++
standard to a newer one is no different. In fact, I think that this
forced change is an excellent incentive to review older packages.

> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98

Why would you pick such an old standard as the default? Also note that
at least with boost there were instances where the ABI changed
depending on whether C++11 or higher was enabled or not. - Also for
that reason I think we should strife for all packages using the same
C++ standard, and this should be the default of the currently used C++
compiler. Forcing a lower standard on a package as a maintainer I would
consider only as a (temporal) workaround to fix RC bugs, and preferable
only for leaf packages.

Best,
Gert

Re: Mandates explicit -std=c++XY for c++ projects

[Mathieu Malaterre]

Ansgar,

On Tue, Oct 10, 2017 at 9:17 AM, Mathieu Malaterre  wrote:
> Ansgar,
>
> On Tue, Oct 10, 2017 at 9:11 AM, Ansgar Burchardt  wrote:
>> Mathieu Malaterre writes:
>>> With this mind I'd like to make mandatory the -std=c++XY flags when
>>> compiling either a c++ library or a stand-alone c++ program:
>>>
>>> 1. Either upstream define the explicit -std=c++XY flags by mean of its
>>> build system,
>>> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
>>> pass the appropriate version of the c++ standard. In which case this
>>> should be documented in the README.Debian file.
>>> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
>>
>> So if the upstream build system adds '-std=c++14' and CXXFLAGS is set to
>> '-std=gnu++98', one gets '-std=c++14 -std=gnu++98' and building the
>> package no longer works?  That doesn't sound good to me.
>
> My bad, I assumed this would be the opposite, just like the -O3 vs
> -O2, so the latest flags would be considered. Let me double check with
> a cmake package.

So I verified with a CMake package where:

$ cat CMakeLists.txt
[...]
set(CMAKE_CXX_STANDARD 98)

I have then set:

$ cat debian/rules
[...]
export DEB_CXXFLAGS_MAINT_APPEND = -std=c++14

This leads:

cd /tmp/gdcm-2.8.2/obj-x86_64-linux-gnu/Source/Common && /usr/bin/c++
 -DgdcmCommon_EXPORTS
-I/tmp/gdcm-2.8.2/obj-x86_64-linux-gnu/Source/Common
-I/tmp/gdcm-2.8.2/Source/Common
-I/tmp/gdcm-2.8.2/Source/DataStructureAndEncodingDefinition
-I/tmp/gdcm-2.8.2/obj-x86_64-linux-gnu/Testing/Source/Data
-I/tmp/gdcm-2.8.2/Testing/Source/Data -I/tmp/gdcm-2.8.2/Utilities  -g
-O2 -fdebug-prefix-map=/tmp/gdcm-2.8.2=. -fstack-protector-strong
-Wformat -Werror=format-security -std=c++14 -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC   -std=gnu++98 -o
CMakeFiles/gdcmCommon.dir/gdcmBoxRegion.cxx.o -c
/tmp/gdcm-2.8.2/Source/Common/gdcmBoxRegion.cxx

So the upstream flag -std=gnu++98 (since it comes last) is properly considered.

Was this the setup you had in mind ?

Thanks for your comments,

Re: Mandates explicit -std=c++XY for c++ projects

[Mathieu Malaterre]

[continued]

On Tue, Oct 10, 2017 at 9:11 AM, Ansgar Burchardt  wrote:
> Mathieu Malaterre writes:
>> With this mind I'd like to make mandatory the -std=c++XY flags when
>> compiling either a c++ library or a stand-alone c++ program:
>>
>> 1. Either upstream define the explicit -std=c++XY flags by mean of its
>> build system,
>> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
>> pass the appropriate version of the c++ standard. In which case this
>> should be documented in the README.Debian file.
>> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
>
> So if the upstream build system adds '-std=c++14' and CXXFLAGS is set to
> '-std=gnu++98', one gets '-std=c++14 -std=gnu++98' and building the
> package no longer works?  That doesn't sound good to me.
>
> Why should CXXFLAGS be documented in README.Debian?  (Or in fact
> anywhere outside of d/rules?)  They aren't interesting for users of the
> package.

Sorry missed that question. I simply based my comment based on:

* https://www.debian.org/doc/debian-policy/#libraries

[...]
Any exception to this rule should be discussed on the mailing list
debian-devel@lists.debian.org, and the reasons for compiling with the
-fPIC flag must be recorded in the file README.Debian. [3]
[...]

Again I have no strong opinion on that. Having is set in the d/rules
is relatively clear. I just wanted to make it clear just like the
-fPIC flag.

Re: Mandates explicit -std=c++XY for c++ projects

[Andrey Rahmatullin]

On Tue, Oct 10, 2017 at 09:12:45AM +0200, Mathieu Malaterre wrote:
> > lintian doesn't scan build logs, it scans source and binary packages.
> 
> Right. I always forgot that. What is the mechanism used for
> shlib-calls-exit, does it rely on source parsing ?
No, it just looks at the imported symbols :)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Mandates explicit -std=c++XY for c++ projects

[Mathieu Malaterre]

Ansgar,

On Tue, Oct 10, 2017 at 9:11 AM, Ansgar Burchardt  wrote:
> Mathieu Malaterre writes:
>> With this mind I'd like to make mandatory the -std=c++XY flags when
>> compiling either a c++ library or a stand-alone c++ program:
>>
>> 1. Either upstream define the explicit -std=c++XY flags by mean of its
>> build system,
>> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
>> pass the appropriate version of the c++ standard. In which case this
>> should be documented in the README.Debian file.
>> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
>
> So if the upstream build system adds '-std=c++14' and CXXFLAGS is set to
> '-std=gnu++98', one gets '-std=c++14 -std=gnu++98' and building the
> package no longer works?  That doesn't sound good to me.

My bad, I assumed this would be the opposite, just like the -O3 vs
-O2, so the latest flags would be considered. Let me double check with
a cmake package.

> Why should CXXFLAGS be documented in README.Debian?  (Or in fact
> anywhere outside of d/rules?)  They aren't interesting for users of the
> package.
>
> I also don't think we should default to an ancient C++ standard.  All
> maintained software should hopefully work with C++11 or later by now...

Indeed, that is a key point why I wanted to discuss that. I am fine
changing the point (3) with -std=gnu++14, instead of -std=gnu++98.

Re: Mandates explicit -std=c++XY for c++ projects

[Mathieu Malaterre]

On Tue, Oct 10, 2017 at 9:05 AM, Julien Cristau  wrote:
> On Tue, Oct 10, 2017 at 08:45:49 +0200, Mathieu Malaterre wrote:
>
>> Dear all,
>>
>> Since the GCC 6 release [1], the default mode for C++ is now
>> -std=gnu++14 instead of -std=gnu++98. What this means is that upon
>> (re)compilation a library written for c++98 will be recompiled using a
>> different c++ standard (c++14 in this case), unless of course the
>> upstream package explicitly set the -std= flags with the appropriate
>> c++ version.
>>
>> The ISO committee generally describe the change in between different
>> standards [2] and in some case, one can find examples of subtle change
>> in behaviors [3] and [4].
>>
>> With this mind I'd like to make mandatory the -std=c++XY flags when
>> compiling either a c++ library or a stand-alone c++ program:
>>
>> 1. Either upstream define the explicit -std=c++XY flags by mean of its
>> build system,
>> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
>> pass the appropriate version of the c++ standard. In which case this
>> should be documented in the README.Debian file.
>> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
>>
> It might be useful to explain what problem you think that would fix.
> The above sounds to me like a step backwards.

You removed the links. But I assumed you saw there were removed and
deprecated features. Which means using this explicit mechanism a
Debian package will not FTBFS -say- whenever the next GCC release jump
from -std=gnu++14 to -std=gnu++17. This also clearly defines the ABI
of the shared libraries which IMHO is also a good things (with regards
to symbols). And to a lesser extend the subttle difference in between
c++98 / c++11 and C++14 are clearly avoided (while I admit no sane
person will provide a c++ project using an examples from the provided
SO links I sent).

>> If there is a consensus on the following change, I'll go ahead and
>> also file a bug for lintian to scan the compilation logs in search for
>> missing -std=c++ expression when g++ command line are issued.
>>
> lintian doesn't scan build logs, it scans source and binary packages.

Right. I always forgot that. What is the mechanism used for
shlib-calls-exit, does it rely on source parsing ?

Re: Mandates explicit -std=c++XY for c++ projects

[Ansgar Burchardt]

Mathieu Malaterre writes:
> With this mind I'd like to make mandatory the -std=c++XY flags when
> compiling either a c++ library or a stand-alone c++ program:
>
> 1. Either upstream define the explicit -std=c++XY flags by mean of its
> build system,
> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
> pass the appropriate version of the c++ standard. In which case this
> should be documented in the README.Debian file.
> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98

So if the upstream build system adds '-std=c++14' and CXXFLAGS is set to
'-std=gnu++98', one gets '-std=c++14 -std=gnu++98' and building the
package no longer works?  That doesn't sound good to me.

Why should CXXFLAGS be documented in README.Debian?  (Or in fact
anywhere outside of d/rules?)  They aren't interesting for users of the
package.

I also don't think we should default to an ancient C++ standard.  All
maintained software should hopefully work with C++11 or later by now...

Ansgar

Re: Mandates explicit -std=c++XY for c++ projects

[Julien Cristau]

On Tue, Oct 10, 2017 at 08:45:49 +0200, Mathieu Malaterre wrote:

> Dear all,
> 
> Since the GCC 6 release [1], the default mode for C++ is now
> -std=gnu++14 instead of -std=gnu++98. What this means is that upon
> (re)compilation a library written for c++98 will be recompiled using a
> different c++ standard (c++14 in this case), unless of course the
> upstream package explicitly set the -std= flags with the appropriate
> c++ version.
> 
> The ISO committee generally describe the change in between different
> standards [2] and in some case, one can find examples of subtle change
> in behaviors [3] and [4].
> 
> With this mind I'd like to make mandatory the -std=c++XY flags when
> compiling either a c++ library or a stand-alone c++ program:
> 
> 1. Either upstream define the explicit -std=c++XY flags by mean of its
> build system,
> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
> pass the appropriate version of the c++ standard. In which case this
> should be documented in the README.Debian file.
> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
> 
It might be useful to explain what problem you think that would fix.
The above sounds to me like a step backwards.

> If there is a consensus on the following change, I'll go ahead and
> also file a bug for lintian to scan the compilation logs in search for
> missing -std=c++ expression when g++ command line are issued.
> 
lintian doesn't scan build logs, it scans source and binary packages.

Cheers,
Julien