Re: GCC_REQD, the NetBSD system compiler, etc

[David Brownlee <abs%absd.org@localhost>]

On Thu, 23 Sept 2021 at 10:29, Martin Husemann <martin%duskware.de@localhost> wrote:
>
> On Thu, Sep 23, 2021 at 11:23:14AM +0200, Edgar Fuß wrote:
> > > I don't understand this part - which gcc version is later than what?
> > If you build a newer pkgsrc gcc (with base gcc or another pkgsrc gcc),
> > dependencies built on the way are built with the old gcc, which may lead
> > to libstd++-mixing hell. So you would need to build them with a different
> > PREFIX, discard them when the new gcc has been built and start over.
>
> Oh - duh.
>
> Would it be enough to do a regular pkg build of the new compiler, then
> check the .so version of libstdc++ used by that compiler, run a script
> to find all uses of older libstdc++ in PREFIX and show a pkg_delete -r
> invocation that would kill all those pkgs? (And left as an exercise: use
> the users prefered update method to get new versions of the updated pkgs
> back, if needed).
>
> Or do we end up with mixed libstdc++ in the new gcc pkg already?

I think there may be different levels here

1) pkgsrc gcc+deps built with system compiler to different PREFIX,
used as external compiler for pkgsrc
2) pkgsrc gcc+deps built with system compiler, used as pkgsrc compiler
3) pkgsrc gcc+deps built with system compiler, used as pkgsrc
compiler, then some of it rebuilt to avoid any libstd++ mixing issues
4) pkgsrc gcc+deps built with system compiler to different PREFIX,
only used to rebuild pkgsrc gcc+deps

I understand some existing (non NetBSD) bootstraps use #1 or #2.

#3 feels somewhat fragile and a potential whack-a-mole as gcc
dependencies change (Unless something like nia's "use
-static-libstdc++" option can make it go away altogether and make #2
safe for static-libstdc++)

If the end goal is to have the resultant system use the 'new' gcc for
building all packages we run into issues with rebuilding gcc or any of
its dependencies. For that reason I'm more of a fan of #1 or #4 -
while #4 is more compute effort it should be much simpler to make it
robust, even in the case of changing compiler dependencies, plus it
should ensure a binary package of a gcc dependency is not different
based on whether it was built before or after the new gcc

For reference last time I was overriding a NetBSD system pkgsrc gcc to
gcc-8 (so ~all packages were built with gcc8) I had to exclude the
following as they were needed for the initial gcc build:
- archivers/bsdtar
- devel/gmake
- devel/libffi
- devel/libtool-base
- devel/libuuid
- devel/m4
- devel/pkgconf
- devel/readline
- lang/perl5
- lang/python37
- pkgtools/cwrappers
- pkgtools/digest
- sysutils/checkperms
- textproc/gsed

David