Re: compiler.mk inclusion in buildlink3.mk causes problems

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Sun, Apr 13, 2025 at 11:40:43PM +0200, Thomas Klausner wrote:
 > These two patches introduce hard-to-diagnose problems in the bulk
 > builds.
 >
 > [changes to libheif and openal-soft bl3s to pick an old version
 > when using an old compiler]
 > 
 > ===> Creating toolchain wrappers for blender-4.2.4nb2
 > ERROR: gcc12-libs>=12.1.0 is not installed; can't buildlink files.
 > *** Error code 1

and in reply:

On Sun, Apr 13, 2025 at 11:03:55PM +0000, nia wrote:
 > These files no longer include compiler.mk on NetBSD.


That isn't really going to fix the problem, or rather, it papers over
it.

If you build some of your C++ libs with gcc12 you need to build them
all with gcc12, or you end up with multiple versions of libstdc++
linked at once and things go down the drain. Therefore, anything that
results in a different C++ compiler being selected in two different
places (which is the root cause of the problem cited) is fundamentally
wrong.

Handling this properly is difficult for pkgsrc because resolving it
requires nonlocal reasoning -- you need to inspect the compiler
requirements of all the packages you have and/or propose to build,
then pick a compiler that satisfies them all. There's nothing we have
in pkgsrc that's capable of handling this kind of analysis.

Generally what we've done in the past when this kind of problem has
come up (e.g. minimum versions for builtin packages, particularly X
packages) is be aggressively conservative: if anything in pkgsrc
depends on having the newer thing, make everyone build the newer
thing.

This obviously doesn't fly for the C++ compiler, so we've been putting
bandaids on it for some time now and limping along. The recent
outbreak of C++20 requirements has brought the situation to a head,
though, which is why we now have hacks like the ones cited above. So I
think it's time we tried to figure out a real solution.

Ideally also this would be a solution for other related problems, like
forcing ancient platforms to build new X libs in case someone tries to
also build modern apps that'll never be runnable, but a solution that
works just for the compiler choice would be a good starting point.


...before I go on, does anyone disagree that this is a problem that
needs to be solved?


-- 
David A. Holland
dholland%netbsd.org@localhost