[gentoo-dev] Re: How to support C++11 in libraries?
On Thu, 19 Dec 2013 10:18:55 +0100 Michał Górny wrote: > And that brings another issue in Gentoo -- gcc-config. AFAIR this tool > is completely insane and switches libstdc++ along with gcc version. > As a result, after switching to a gcc version with different C++ ABI, > installed software gets broken. And you can't really fix it without > going through the broken-system state or some hackery. This hasn't been true for a while now. The latest version of libstdc++ is always used, no matter what version is selected. I can't remember when this was changed but we've gone through a couple GCC stabilizations since. I have no opinion on how to support C++-11, except that it can't be globally enabled. We have to support compilers that predate the standard. I wouldn't like any pkg-config hackery like ICU tried to pull a while back, but now that we have a version of gcc that at least understands the flag in stable at least it wouldn't instantly break everything. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Commit into profiles fails
On Fri, Dec 20, 2013 at 08:19:08PM +0200, Alon Bar-Lev wrote: > Long time since I done this... maybe something had been changed. FYI this is fixed. The CVS server had an unexpected reboot, and one of the sysctls for grsec was missing, so it was being too secure. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Commit into profiles fails
On 12/20/2013 07:50 PM, Johannes Huber wrote: > Am Freitag, 20. Dezember 2013, 20:19:08 schrieb Alon Bar-Lev: >> Hi, >> >> Long time since I done this... maybe something had been changed. >> >> $ cvs commit -m "thirdpartymirrors: fixup gnupg mirros, bug#494842, thanks >> to Ben Kohler" >> cvs commit: cannot exec /var/cvsroot/CVSROOT/cvslogdate: Permission denied >> cvs commit: cannot exec /var/cvsroot/CVSROOT/checkgroup.pl: Permission >> denied >> cvs commit: Pre-commit check failed >> cvs [commit aborted]: correct above errors first! >> >> It looks like something is wrong in remote, but I see people succeed in >> committing today... >> >> What's wrong? >> >> Thanks, >> Alon > > Hi Alon, > > its not only you. Seems something is broken on infra side or its the pre- > christmas present, the git migration. > > Greetings > maybe worth opening a bug (assuming there is no one already) or talk to #gentoo-infra? -- Regards, Markos Chandras
Re: [gentoo-dev] Commit into profiles fails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/12/13 02:50 PM, Johannes Huber wrote: > Am Freitag, 20. Dezember 2013, 20:19:08 schrieb Alon Bar-Lev: >> Hi, >> >> Long time since I done this... maybe something had been changed. >> >> $ cvs commit -m "thirdpartymirrors: fixup gnupg mirros, >> bug#494842, thanks to Ben Kohler" cvs commit: cannot exec >> /var/cvsroot/CVSROOT/cvslogdate: Permission denied cvs commit: >> cannot exec /var/cvsroot/CVSROOT/checkgroup.pl: Permission >> denied cvs commit: Pre-commit check failed cvs [commit aborted]: >> correct above errors first! >> >> It looks like something is wrong in remote, but I see people >> succeed in committing today... >> >> What's wrong? >> >> Thanks, Alon > > Hi Alon, > > its not only you. Seems something is broken on infra side or its > the pre- christmas present, the git migration. > > Greetings > Antarus is working on it, fyi all. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlK0lXQACgkQ2ugaI38ACPAKDgD8D4JbQwkV7NaopsfAOi5EecZP 3F+TXTrDaYrOHWlQw9kA/RyJNnokb5dvjBh5kT5roBA3YfQVf/qKH6vhI82x/KBG =X8Te -END PGP SIGNATURE-
Re: [gentoo-dev] Commit into profiles fails
Am Freitag, 20. Dezember 2013, 20:19:08 schrieb Alon Bar-Lev: > Hi, > > Long time since I done this... maybe something had been changed. > > $ cvs commit -m "thirdpartymirrors: fixup gnupg mirros, bug#494842, thanks > to Ben Kohler" > cvs commit: cannot exec /var/cvsroot/CVSROOT/cvslogdate: Permission denied > cvs commit: cannot exec /var/cvsroot/CVSROOT/checkgroup.pl: Permission > denied > cvs commit: Pre-commit check failed > cvs [commit aborted]: correct above errors first! > > It looks like something is wrong in remote, but I see people succeed in > committing today... > > What's wrong? > > Thanks, > Alon Hi Alon, its not only you. Seems something is broken on infra side or its the pre- christmas present, the git migration. Greetings -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Commit into profiles fails
Hi, Long time since I done this... maybe something had been changed. $ cvs commit -m "thirdpartymirrors: fixup gnupg mirros, bug#494842, thanks to Ben Kohler" cvs commit: cannot exec /var/cvsroot/CVSROOT/cvslogdate: Permission denied cvs commit: cannot exec /var/cvsroot/CVSROOT/checkgroup.pl: Permission denied cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! It looks like something is wrong in remote, but I see people succeed in committing today... What's wrong? Thanks, Alon
[gentoo-dev] Re: How to support C++11 in libraries?
Jan Kundrát wrote: >> And no, the languages are _not_ "source-incompatible". That would be a >> scandal! > > You might argue about this, but that doesn't change these facts. I think nobody had doubts that *theoretical* such examples can be constructed (I even mentioned the case of name collission on which your example builds). The question is how often does this occur in *real-world* projects. > does not change the fact that there *is* code out there Your example is not "code out there". I would bet that the name collission case hits less than 1% of existing projects. If name collissions would be the only case, it would not even be worth to discuss these things. The more restrictive syntax for string concatenation (mentioned in some bug posted in this thread) is a more realistic issue, but at least in this case, the project has already fixed the problem. Again: Numbers are needed; somebody (preferrably somebody with a fast machine, so I am out ;) ) has to try to compile w/test the whole ~x86/~amd64 tree with CXXFLAGS=-std=c++11, and only then one can seriously discuss how "source-incompatible" the languages really are. My guess is still that you will observe less problems than with a minor gcc upgrade, but it is only a guess, of course.
[gentoo-dev] Re: How to support C++11 in libraries?
Jan Kundrát wrote: > On Friday, 20 December 2013 10:00:43 CEST, Martin Vaeth wrote: >> The example with string reference-counters which you gave is IMHO >> typical; > > You have not considered the implications of the updated requirements It seems you are changing the topic: We were talking about downward-compatibility of source code. There is no doubt that the C++11 requirements need a new ABI: > without breaking the ABI [...] > but I do not expect that the end result will allow linking a translation > unit built for C++98 by GCC <= 4.8 with one built for C++11 by the new > compiler. That's why it might be a good idea to translate with C++11 by default. No old units <-> no problem ;) Again: It is clear that this route is possible only if the number of packages breaking with such a default is small, and fixes are simple. Which needs to be examined by "experiment" and not by theoretical considerations.
Re: [gentoo-dev] How to support C++11 in libraries?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/12/13 06:56 AM, Sven Eden wrote: > > So basically C++11 <-> C++03 is no problem at all (unless you > *export* certain symbols [2]), but combining C++11 from different > gcc versions is nowhere guaranteed to work. > > Cheers > > Sven > > > [1] : https://lwn.net/Articles/552831/ [2] : > http://gcc.gnu.org/wiki/Cxx11AbiCompatibility > Aha... so what we should probably be doing then is filtering out - --std=c++11 until gcc-4.9 or whatever version is released, that will standardize things, so that we don't end up with systems that have a mix-and-match. And probably alert users using earlier versions of gcc that if they enable --std=c++11, they should expect to 'emerge -e @world' on any compiler switch. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlK0XdEACgkQ2ugaI38ACPB2WgEAtnLeonyTFCF5cMEIi0kSIHZ/ RZcgjzRbojT3YejvMmkA/2v/qC7Cy58QAgz7oEC5z+KvPUVBJ79Ana0+rrPoq9TM =pn2S -END PGP SIGNATURE-
Re: [gentoo-dev] How to support C++11 in libraries?
2013/12/20 Jan Kundrát :
> On Friday, 20 December 2013 12:56:43 CEST, Sven Eden wrote:
>>
>> And no, the languages are _not_ "source-incompatible". That would be a
>> scandal!
>
>
> You might argue about this, but that doesn't change these facts. This is
> absolutely valid C++98 program:
>
> jkt@svist ~ $ cat foo.cpp int main() {
>auto int foo;
>return 0;
> }
> jkt@svist ~ $ g++ -std=c++98 -pedantic foo.cpp
> jkt@svist ~ $ echo $?
> 0
>
> ...which will *not* build under the C++11 mode:
>
> jkt@svist ~ $ g++ -std=c++0x foo.cpp
> foo.cpp: In function ‘int main()’:
> foo.cpp:2:14: error: two or more data types in declaration of ‘foo’
>
> Yes, -Wc++0x-compat warns about this, yes, it's included in -Wall, but it
> does not change the fact that there *is* code out there which does conform
> to C++98 standard, does *not* try to "outsmart the compiler", and which will
> not build in the C++11 mode. Do we really have to be having this discussion?
The C++ Committee considered this exact case in relation to the new
meaning of `auto` and decided that such code doesn't really exist in
the wild. You won't hit auto-related issues in almost all packages in
Portage I guess.
There are more obscure cases of incompatibility though, with more
obscure error messages, like with autogenerated move ctors and the
likes. I've hitted it myself a couple of times in more or less complex
template code, but can't think of an example off the top of my head
unfortunately.
--
Georg Rudoy
LeechCraft — http://leechcraft.org
Re: [gentoo-dev] How to support C++11 in libraries?
On Friday, 20 December 2013 12:56:43 CEST, Sven Eden wrote:
And no, the languages are _not_ "source-incompatible". That would be a
scandal!
You might argue about this, but that doesn't change these facts. This is
absolutely valid C++98 program:
jkt@svist ~ $ cat foo.cpp
int main() {
auto int foo;
return 0;
}
jkt@svist ~ $ g++ -std=c++98 -pedantic foo.cpp
jkt@svist ~ $ echo $?
0
...which will *not* build under the C++11 mode:
jkt@svist ~ $ g++ -std=c++0x foo.cpp
foo.cpp: In function ‘int main()’:
foo.cpp:2:14: error: two or more data types in declaration of ‘foo’
Yes, -Wc++0x-compat warns about this, yes, it's included in -Wall, but it
does not change the fact that there *is* code out there which does conform
to C++98 standard, does *not* try to "outsmart the compiler", and which
will not build in the C++11 mode. Do we really have to be having this
discussion?
Cheers,
Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Friday, 20 December 2013 10:00:43 CEST, Martin Vaeth wrote: The example with string reference-counters which you gave is IMHO typical; one would really need to write strange code to make it work *with* reference counters but break without. Hard to believe that this happens in practice. What *will* happen in practice is that the execution speed changes (probably getting slower, but there might also be exceptions). You have not considered the implications of the updated requirements. With std::string, this might be hard to understand within all the layers of template wrapping, but consider std::list instead. The "old" (C++98/C++03) std::list is implemented by containing exactly one member, the struct _List_node_base. This struct has exactly two pointers inside, one for the next item and one for the last. This layout cannot be changed without breaking the binary compatibility; it is effectively made public because GCC's standard library does not use the PIMPL idiom. Now, this particular layout (which we just established cannot be changed without breaking the ABI) means that std::list::size() has O(n) time cost simply because it has to traverse the whole list to compute the number of items. The C++11 standard, however, mandates the time complexity to be O(1). This means that there will be a very visible change, at least for std::list. I won't speculate on how the upstream is going to solve this, but I do not expect that the end result will allow linking a translation unit built for C++98 by GCC <= 4.8 with one built for C++11 by the new compiler. Jan
Re: [gentoo-dev] How to support C++11 in libraries?
Am Donnerstag, 19. Dezember 2013, 16:23:08 schrieb Jan Kundrát: > On Thursday, 19 December 2013 16:00:13 CEST, Ian Stakenvicius wrote: > > A change in profiles? 14.0/* adds that to the default CXXFLAGS in > > base, new stage3's etc are all rolled with this. We recommend > > migration to 14.0 profile and have a check somewhere about > > "-std=c++11" missing from CXXFLAGS in case it's overridden in > > make.conf, so users put it in place? > > Before you invest any more time in this, please understand that C++98 and > C++11 are source-incompatible. There is no way to expect that a package > builds fine when you throw -std=c++11 on it. And even if you patched them > all, you are breaking an unknown number of 3rd party software over which > you have exactly zero control. No. If you do something against the standard that is working due to lack of control when compiling with -std=c++98, then your source code is severly broken. Most developers will use C++03 (plus tr1) anyway, won't they? And no, the languages are _not_ "source-incompatible". That would be a scandal! But if you have your C++98/03 code, and do what most developers do and let your console be flooded with warnings you ignore, you must not be surprised, if the compilation fails when you decide to throw "-std=c++11 -Wall -Wextra -Wpedantic -fsanitize=address -fsanitize=thread" with gcc 4.8.2 at it. There is absolutely no reason to expect a compilation to fail with C++11, if it went well with C++03 and "-Wall -Wextra -pedantic". If you try to outsmart your compiler, it will get it's revenge very soon and very hard. And according to [1] it goes even further: Quote: > If you use C++11 then in general you can combine C++11 code built with GCC > 4.X and C++03 code built with any GCC, but there is not the same guarantee > that you can combine with C++11 code built with GCC 4.Y or GCC 4.Z, because > the C++11 features are not all stable yet (e.g. for GCC 4.9 I'm about to add > a new virtual function to a base class in .) This is why C++11 > support is still labelled "experimental", because it would be worse to claim > it's stable and then have to break the ABI. So basically C++11 <-> C++03 is no problem at all (unless you *export* certain symbols [2]), but combining C++11 from different gcc versions is nowhere guaranteed to work. Cheers Sven [1] : https://lwn.net/Articles/552831/ [2] : http://gcc.gnu.org/wiki/Cxx11AbiCompatibility signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: How to support C++11 in libraries?
Jan Kundrát wrote: > > Before you invest any more time in this, please understand that C++98 and > C++11 are source-incompatible. The question is what impact this theoretical incompatibility in a few corner cases has in practice. > There is no way to expect that a package builds fine when you > throw -std=c++11 on it. Yes, but the same is true for any gcc upgrade. I repeat that numbers are necessary: If practice shows that there is only a few packages in the tree needing a few trivial patches then the same can be assumed about 3rd party software. The situation is rather different if it turns out that almost nothing runs without severe patches. Nobody can know the answer without actually trying. However, I would be very surprised if the latter is true: The example with string reference-counters which you gave is IMHO typical; one would really need to write strange code to make it work *with* reference counters but break without. Hard to believe that this happens in practice. What *will* happen in practice is that the execution speed changes (probably getting slower, but there might also be exceptions).
