Re: libstdc++ and gcc versions (Re: [NetBSD 10.99.12 amd64] multimedia/phonon-qt5

[Stephen Borrill <netbsd%precedence.co.uk@localhost>]

On Mon, 7 Apr 2025, Jonathan Perkin wrote:
> * On 2025-04-07 at 11:24 BST, Stephen Borrill wrote:
>
> > On Mon, 7 Apr 2025, Jonathan Perkin wrote:
> > > * On 2025-04-06 at 23:40 BST, Makoto Fujiwara wrote:
> > >
> > > > | What I do is to use the same gcc version for all packages. So if one of
> > > > | them requires gcc12, I set GCC_REQD+= 12 in /etc/mk.conf. It will be a
> > > > | while before you need to increase that number but when that happens you
> > > > | probably have to rebuild them all.
> > > >
> > > > This is what I'm thinking. Various packages ask for different gcc 
> > > > versions.
> > > > It will result that serveral versions of gcc will be packaged. But if the 
> > > > only
> > > > one version is packaged for that run, it may be straight out some mixed
> > > > (libstdc++) versions.
> > > >
> > > > Can this be automated ? (hopefully at least pbulk scan)
> > > > -> I may be wrong,
> > > >
> > > > Let me rewrite:
> > > > At particular package, serveral version of gcc may be packaged, because
> > > > of depending packages ask for different level, but if the only one at 
> > > > most
> > > > required is included .... (?)
> > >
> > > It's not possible to automate, because you will run into circular 
> > > dependencies.
> >
> > Something like this will stop the circular dependency:
> >
> > .if \\
> >        \${OPSYS} == "NetBSD" && \${OPSYS_VERSION} < 100000 && \\
> >        empty(PKGPATH:Mdevel/gmake) && \\
> >        empty(PKGPATH:Mlang/gcc10) && \\
> >        empty(PKGPATH:Mlang/gcc10-libs) && \\
> >        empty(PKGPATH:Mlang/perl5) && \\
> >        empty(PKGPATH:Mpkgtools/cwrappers) && \\
> >        empty(PKGPATH:Mpkgtools/digest) && \\
> >        empty(PKGPATH:Mpkgtools/mktools) && \\
> >        empty(PKGPATH:Mtextproc/gsed)
> > GCC_REQD+=10
> > .endif
>
> Yeh I know, that's the approach I designed well over a decade ago and which 
> others have copied in the meantime.

Sure, I'm not trying to teach you to suck coals to Newcastle; it was a 
more a datapoint for the mailing lists.

> The problem is that the list of packages 
> changes depending on your OS, environment, and pkgsrc settings.  For my 
> environment it's:
>
>  https://github.com/TritonDataCenter/pkgbuild/blob/master/include/gcc-libs.mk#L28-L49
>
> and some dependencies are handled differently, e.g. by setting 
> TOOLS_PLATFORM.foo to an external tool rather than requiring the dependency, 
> so we can't just hard code a single list.  This is what work such as this:
>
>  https://github.com/TritonDataCenter/pkgsrc/commit/2513814a12de74882183d4333aaedc50f86021fb
>
> is designed to help.

Looks great!

> I don't know what PHP issue you were seeing but, as I'm sure people are 
> thoroughly sick of hearing by now, I've been doing this for a very very long 
> time in very large-scale production deployments, and have never had it cause 
> problems that weren't compiler bugs.

Ironically the only response I got to my PHP issue was from you. :-/

https://mail-index.netbsd.org/pkgsrc-users/2025/01/31/msg040975.html

I was trying to standardize on GCC 10 for an future upgrade to -10, but 
using GCC 10 for everything didn't work on -9 (it's fine on -10, of 
course).

With 2025Q1, MySQL 8 brings in GCC 10, but nothing else (from my list of 
packages).

--
Stephen