Jason Bacon <bacon4000%gmail.com@localhost> writes: > On 06/29/17 06:48, Greg Troxel wrote: >> Joerg Sonnenberger <joerg%bec.de@localhost> writes: >> >>> On Wed, Jun 28, 2017 at 08:12:04PM -0400, Greg Troxel wrote: >>>> That sounds like a framework bug. USE_LANGUAGES=c++11 is supposed to >>>> ensure that the complier used is capable of c++11. >>> No, it doesn't. That wouldn't work as it results in random mixing of GCC >>> versions used with different ABIs. You have to preselect a version that >>> supports all the C++ ABIs you need. >> While again agreeing on the ABI issue, I see in mk/compiler.mk that >> USE_LANGUAGES is documented to select an appropriate compiler, which is >> the only reasonable expectation. >> >> So it's a bug that if the compiler being used is not adequate, an error >> isn't thrown early on along the lines of "chosen version of gcc X does >> not supported required language c++11" and the build not even attempted. >> > I think the immediate question is how many packages like googletest > are broken, perhaps because the maintainer thought this would select > an appropriate compiler? It's not really that googletest is broken. It's that the combination of C++ not being a single stable language C++ not having a stable ABI people using old compilers how the mk/ framework is people not setting a global GCC_REQD is broken. So it's not clear that googletest should be "fixed". At some point pkgsrc got GCC_REQD, and my memory is that it was about avoiding versions with bugs that tripped on particular packages. Then c++11 happened, and packages started using it before non-c++11 compilers faded away. This hasn't yet been dealt with in a fully organized manner. I think it's wrong to have each package that uses c++11 also have to encode GCC_REQD, from an abstraction viewpoint. There is also the point that for soundness, all c++ programs on a machine must be compiled with the same compiler. (Actually, each dependency tree must be compiled with the same compiler, but I don't think there are any non-trivial situations where the more complicated rule is a net win. Do you believe that this notion is incorrect? I ask because you are pursuing a path (adding GCC_REQD to individual programs) that leads to this problem. In your case, as I understand it, you are wanting to use code that is in a new language on an operating system that intentionally has old software. This mixing of old and new, in my view, basically does not work. But, with pkgsrc, you can use a new compiler for pkgsrc, and have a new world of pkgsrc and the old world of base, more or less disconnected from each other (the multi-tree approach above). I think we should be removing GCC_REQD from packages when the only reason is to force a compiler with c++11 or c++14. GCC_REQD would then become unusual. Have you tried putting GCC_REQD in your mk.conf, and rebuilding everything? What's wrong with that approach for you? That's a serious question, because one of the paths forward is to essentially put that in the platform file for systems with old compilers. (Here, I'm defining old by "fails to build a non-trivial number of packages that need c++11".) The other path is to add in GCC_REQD=4.8 (or 6) for all packages with c++ (not c++11, but any c++, to avoid ABI mixing). I think it's a serious question whether people are better off: 1) using old system gcc for C and newish pkgsrc gcc for C++ 2) using newish pkgsrc gcc for everything In favor of 1 is that if you don't want to build C++, you are spared building a compiler. In favor of 2 is that it probably avoids a bunch of fairly minor, hard to track down problems that we don't know about. In asking you if you've tried GCC_REQD=4.8 in mk.conf, I'm basically asking you to be a test case for option 2, and if that hurts. Given that you want to build C++ stuff, you have to build the compiler anyway, so it seems like it wouldn't be a problem.
Attachment:
signature.asc
Description: PGP signature