Jason Bacon <bacon4000%gmail.com@localhost> writes: > Disabling gcc-inplace-math did not reduce dependencies much on my > CentOS systems. Is it different on NetBSD? I see gcc48 and gcc49 packages installed (NetBSD 7 amd64) that look like: Requires: gsed>=3.0.2 gmp>=5.0.1 mpcomplex>=0.8.2 mpfr>=3.0.0.3 cloog>=0.18.0nb1 isl>=0.11.1 and on another, older system, gcc6 that has no dependencies (but needs gsed to build, at least). I am building all gcc >= 34 currently, on NetBSD 7 amd64, to see what happens. > For 2017Q3, GCC 4.8 seemed to work best on CentOS, but GCC 5 is > close. There still appears to be a lot of work to do toward GCC 6 > compatibility across the whole collection. Below are counts for > successful pbulk builds. Thanks. I'll flip the text to recommend 5 as the newest version that avoids bleeding-edge trouble. Everyone else should feel free to object and post their own data :-) > www/pkgsrc/packages/sharedapps/pkg-2017Q3/Darwin15/All 14162 > www/pkgsrc/packages/sharedapps/pkg-2017Q3/Darwin16/All 14012 > www/pkgsrc/packages/sharedapps/pkg-2017Q3/NetBSD-7.1/All 17986 > www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL6-gcc6/All 15849 > www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL6/All 16459 So is that 4.8 vs 6? > www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL7-gcc5/All 16338 > www/pkgsrc/packages/sharedapps/pkg-2017Q3/RHEL7/All 16413 And this is 4.8 vs 5? The other point is that with a fixed 4.8, rather than our current logic, firefox will fail (I think). In your bulk builds with 4.8, did 4.9 get built and used? Did firefox build? Or did something else fail and prevent it, so you didn't see this effect Or ?? > Maybe this should be dealt with separately, but has any thought been > given to compatibility between gfortran and clang on platforms such as > Darwin and FreeBSD? FreeBSD ports has ways to deal with it, although > they are a little messy. Here's an example of a FreeBSD port that > mixes boost compiled with clang++ and blas/lapack compiled with > gfortran: > https://github.com/outpaddling/freebsd-ports-wip/tree/master/bolt-lmm I have not thought about it. I think it really should be dealt with separately, because I don't see how dealing with it at the same time significantly reduces total effort, and this is complicated enough. > The logic for dealing with compiler and library issues is here, much > of it in Uses/compiler.mk: > > https://github.com/freebsd/freebsd-ports/tree/master/Mk Thanks for the pointers. > I'm inclined to save this for another day, but it might have some > bearing on the choice of a default GCC compiler if we're planning > ahead for that day. I.e. which of gcc48, gcc5, or gcc6 is most > compatible with the base clang on a given platform? Or maybe punt on > this and focus on integrating flang for those platforms when that's > feasible? I view the choice of default compiler for any paticular platform as a minor issue that will get changed in the future as programs in pkgsrc both demand new compiler features and are updated to work with newer compilers. If we say pick 4.8 now and 6 months later decide to change to gcc6, I think that's perfectly fine. I'm only trying to figure out defaults for right now.
Attachment:
signature.asc
Description: PGP signature