Re: pkgsrc frozen for 2017Q2

[Jason Bacon <bacon4000%gmail.com@localhost>]

On 06/30/17 16:45, Jason Bacon wrote:
> On 06/29/17 13:50, Joerg Sonnenberger wrote:
> > On Thu, Jun 29, 2017 at 12:56:24PM -0500, Jason Bacon wrote:
> > > That's not what I meant...  I'm just trying to identify packages 
> > > that need
> > > to be fixed right now.  These packages are not going to build on 
> > > CentOS 6 as
> > > they stand.
> > Pick a GCC version new enough, i.e. 4.9 is a pretty good bet. Set
> > GCC_REQD=4.9 in mk.conf with PKGPATH check for all but lang/gcc49 and
> > requirements. That should normally be digest, cwrappers, checkpers and
> > maybe gmake.
> >
> > Joerg
>
> I bootstrapped two pristine -current installations on CentOS 6 
> machines.  I'm testing with 4.8 because a 4.9 requirement seems to be 
> very uncommon in pkgsrc and CentOS 7 ships with 4.8.5, so we can use 
> the base compiler instead of installing a heavy dep just to go forward 
> 1 minor version.
>
> One one, I added the following to gcc.mk:
>
> .if !empty(USE_LANGUAGES:Mc++11)
> GCC_REQD+=      4.8
> .endif
>
> On the other, I modified mk.conf so that everything possible will be 
> built with GCC 4.8.  Below is the minimum required to avoid circular 
> dependencies.
>
> .if empty(PKGPATH:Mlang/gcc48) && \
>     empty(PKGPATH:Mpkgtools/cwrappers) && \
>     empty(PKGPATH:Mdevel/nbpatch) && \
>     empty(PKGPATH:Mpkgtools/digest) && \
>     empty(PKGPATH:Msysutils/checkperms) && \
>     empty(PKGPATH:Mlang/perl5) && \
>     empty(PKGPATH:Mdevel/p5-gettext) && \
>     empty(PKGPATH:Mconverters/help2man) && \
>     empty(PKGPATH:Mdevel/autoconf) && \
>     empty(PKGPATH:Mconverters/p5-Unicode-EastAsianWidth) && \
>     empty(PKGPATH:Mdevel/libtool-base) && \
>     empty(PKGPATH:Marchivers/pax) && \
>     empty(PKGPATH:Mlang/gcc49-libs) && \
>     empty(PKGPATH:Mdevel/ncurses) && \
>     empty(PKGPATH:Mmisc/p5-Locale-libintl) && \
>     empty(PKGPATH:Mtextproc/p5-Text-Unidecode) && \
>     empty(PKGPATH:Mdevel/gtexinfo) && \
>     empty(PKGPATH:Mdevel/gmp) && \
>     empty(PKGPATH:Mmath/mpfr) && \
>     empty(PKGPATH:Mmath/cloog) && \
>     empty(PKGPATH:Mmath/isl) && \
>     empty(PKGPATH:Mmath/mpcomplex)
>
> GCC_REQD+=4.8
>
> .endif
>
> I'll be attempting numerous builds over the next few days and will 
> share the results here.
>
> Regards,
>
>     JB
So far I've built googletest, R, Octave, GCC 4.8, 4.9, and 5 and a few 
biology packages, 279 packages in all.

At least within the GCC 4.x family, making c++11 imply GCC_REQD doesn't 
seem to cause any ABI issues.  I'm curious as to why the -std=c++11 flag 
is passed down to dependencies, though.  Was this even intentional?

The only issue I've run into with either approach is dependencies 
inheriting the -std=c++11 flag where I have

.if !empty(USE_LANGUAGES:Mc++11)
GCC_REQD+=      4.8
.endif

I fixed a few of these by simply adding USE_LANGUAGES=c++11, forcing 
them to build with 4.8 as well.

After a while, following another suggestion, I changed this to:

.if !empty(USE_LANGUAGES:Mc++)
GCC_REQD+=      4.8
.endif

There have been no build failures since.

I think making c++ in general imply GCC_REQD is an elegant solution as 
it causes all C++ code to be built with the same compiler (unless 
there's an explicit override in the package).  C-only packages can still 
be built with any compiler (which should not cause any major issues), 
and Fortran is handled separately by already-existing controls.  I 
always use PKGSRC_FORTRAN=gfortran, so mine should end up using the same 
GCC package as C++ by default.  Implementing this approach is a minimal 
change to the infrastructure, and it only pulls in a gcc dependency when 
there's a real benefit.  It's opaque to end-users; doesn't change the 
bootstrap process or require editing mk.conf afterward.

Based on what I've seen, I think either of these solutions will work 
well and create very few problems, though.  The only down side I'm 
seeing to the mk.conf solution is some heavy dependencies like perl 
being built with the old compiler, and the need for end users to make 
manual changes after bootstrapping.  Both of these are solvable, though.

    JB

--
Earth is a beta site.