tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Selecting a C++ compiler

Jason Bacon <> 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


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

> 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:


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/

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

Home | Main Index | Thread Index | Old Index