David Holland <dholland-pkgtech%netbsd.org@localhost> writes: > On Sun, Dec 31, 2017 at 11:25:30AM -0600, Jason Bacon wrote: > > 3. I'm unclear about the meaning of "The minimum version inferred from the > > language tag will be combined with any GCC_REQD declarations to find a > > minimum version for a specific package. If that is greater than > > PKGSRC_GCC_VERSION (programs using only C) or PKGSRC_GXX_VERSION, package > > building will fail." > > AIUI: > > - the package says USE_LANGUAGES+=c++03 > - the package says GCC_REQD=4.8 > > The minimum gcc version for c++03 is (I forget, but let's pretend it's > 4.2); combining this with 4.8 makes 4.8 the minimum required version. > > If PKGSRC_GXX_VERSION is 4.7, meaning the gcc version we're using for > C++ is 4.7, the build will abort, because we're using 4.7 but the > package needs 4.8. If PKGSRC_GXX_VERSION is 5.0, the build won't fail > and we'll compile with 5.0. Yes, that's exactly what I meant. (This is the consensus from the previous lengthy discussions.) > > 4. Can someone provide a specific example of how the > > PKGSRC_GCC_BOOTSTRAP=yes might cause a problem?? I think building > > dependencies with the system compiler and linking against them with a newer > > pkgsrc compiler should be fine in almost all cases, and a recursive > > PKGSRC_GCC_BOOTSTRAP variable should ensure consistency in gcc and > > dependency builds (unless I'm overlooking something). > > and > >> Correction: Tagging packages individually would ensure consistent builds, > > not the recursive PKGSRC_GCC_BOOTSTRAP variable.? My thoughts got jumbled > > here.? For example, with the recursive variable, bzip2 could be built with > > the system compiler or pkgsrc compiler depending on what build depends on > > it.? Tagging bzip2 explicitly would ensure that it's always built with the > > system compiler, if I'm understanding the proposal correctly. > > Yes. > > There's another issue though: sometimes it's ok to have a few packages > built with a different compiler, assuming they work; for example, on > NetBSD-6 where there's nothing particularly wrong with the system > compiler other than it changing slower than the C++ standard. There > are other times though when you would rather avoid the bootstrap > compiler as much as possible, e.g. if you had to compile it > specifically too and it's just wasting disk space by sitting around, > or if it's a pile, or if the stuff built with it doesn't actually > interoperate with stuff built with the real compiler. > > I think it would be good to make sure this scenario works. It can > certainly be handled by bootstrapping multiple pkgsrc trees, but > that's messy and hopefully there's an easier way. Right now packages randomly have GCC_REQD and the version situation is uncontrolled. We are talking about having two defines, for C and C++, with people being able to choose their poison. I think that's strictly better than where we are now (or equal, if pkgsrc gcc does not build), and we should move to that situation, and then people can debate/propose the next step. > Also I have a feeling that on various vintage platforms bootstrapping > to gcc5 will require multiple stages... If there is support for gcc5 emitting code for that platform (coypu@'s point), then we should be able to build a compiler package cross. pkgsrc more or less has cross support, if the package itself does, and the cross part seems tractable. Perhaps we could make binary packages from the NetBSD tools build, too. But I don't want to get hung up on this; figuring out these things is not in the necessary path to progress, and it's obvious that this issue is already too hard.
Attachment:
signature.asc
Description: PGP signature