libstdc++ dependency mis-detection in gcc packages?

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

I wanted to update unbound (from updated pkgsrc), but by mistake I
had not updated the pkgsrc/lang/ directory, so pkgsrc could not find
lang/gcc12/version.mk.  I mis-interpreted that as if it actually
wanted to install gcc12, which turned out to not be the case, and
this sent me down this rabbit hole:

dr2# uname -a
NetBSD dr2.uninett.no 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug  4 15:30:37 UTC 2022  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
dr2# egrep '^ht' /usr/pkg/etc/pkgin/repositories.conf 
https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/9.0_2022Q4/All

(yes, the presence of the _2022Q4 suffix is there because I think
that "upstream" (we) are IMHO all too often too slow in switching
the 9.0 symlink around, and it's therefore for now "stuck" at
that version, thereby creating a local maintenance issue.)

dr2# pkgin in gcc12
calculating dependencies...done.
/usr/lib/libstdc++.so.7, needed by gcc12-12.2.0 is not present in this system.

1 package to install:
  gsed-4.9

0 to refresh, 0 to upgrade, 1 to install
90M to download, 409M to install
the following packages have unmet requirements:   gcc12-12.2.0


proceed ? [Y/n] n
dr2# ls -l /usr/lib/libstdc++.so.*
lrwxr-xr-x  1 root  wheel       16 Aug  4  2022 /usr/lib/libstdc++.so.9 -> libstdc++.so.9.0
-r--r--r--  1 root  wheel  2030264 Aug  4  2022 /usr/lib/libstdc++.so.9.0
dr2# 

It doesn't look like gcc12 is depending on pkgsrc gcc10.  But ...
what creates this dependency?  I know from prior skirmishes with
pkgsrc that pkgsrc gcc is evidently using a different numbering
scheme for libstdc++ than the base system, and that pkgsrc gcc has
its own libstdc++ scurried away in one of its own private library
directories, and that this is possibly the source of this problem.

gcc10 shows the same issue, BTW:

dr2# pkgin in gcc10
calculating dependencies...done.
/usr/lib/libstdc++.so.7, needed by gcc10-10.4.0 is not present in this system.

1 package to install:
  gsed-4.9

0 to refresh, 0 to upgrade, 1 to install
78M to download, 396M to install
the following packages have unmet requirements:   gcc10-10.4.0


proceed ? [Y/n] n
dr2#
dr2# pkg_info | grep pkgin
pkgin-22.10.0nb1    Apt / yum like tool for managing pkgsrc binary packages
dr2# 

How to fix?  Fall back to source build of gcc12?  That would be a
(slightly annoying and time-consuming) local workaround for this
particular system, but it's really too bad that this warning will
deter folks from installing / upgrading.  So what is the proper fix
for this issue?

The gcc10 package contains

/usr/pkg/gcc10/lib/libstdc++.a
/usr/pkg/gcc10/lib/libstdc++.la
/usr/pkg/gcc10/lib/libstdc++.so
/usr/pkg/gcc10/lib/libstdc++.so.7
/usr/pkg/gcc10/lib/libstdc++.so.7.28
/usr/pkg/gcc10/lib/libstdc++.so.7.28-gdb.py
/usr/pkg/gcc10/lib/libstdc++fs.a
/usr/pkg/gcc10/lib/libstdc++fs.la

and pkg_summary.gz for this says:

PKGNAME=gcc10-10.4.0
...
PROVIDES=/usr/pkg/gcc10/lib/libstdc++.so
PROVIDES=/usr/pkg/gcc10/lib/libstdc++.so.7
PROVIDES=/usr/pkg/gcc10/lib/libstdc++.so.7.28
...
REQUIRES=/usr/lib/libstdc++.so.7
...

But ... is the last one accurate?  I suspect not.

The entry for the gcc12 package similarly contains

PKGNAME=gcc12-12.2.0
...
PROVIDES=/usr/pkg/gcc12/lib/libstdc++.so
PROVIDES=/usr/pkg/gcc12/lib/libstdc++.so.7
PROVIDES=/usr/pkg/gcc12/lib/libstdc++.so.7.30
...
REQUIRES=/usr/lib/libstdc++.so.7
...

However, if I just ignore the warning and install gcc12 anyway:

dr2# pkgin in gcc12
calculating dependencies...done.
/usr/lib/libstdc++.so.7, needed by gcc12-12.2.0 is not present in this system.

1 package to install:
  gsed-4.9

0 to refresh, 0 to upgrade, 1 to install
90M to download, 409M to install
the following packages have unmet requirements:   gcc12-12.2.0


proceed ? [Y/n] y
gsed-4.9.tgz                                  100%  216KB 216.1KB/s   00:00    
gcc12-12.2.0.tgz                              100%   90MB   3.6MB/s   00:25    
installing gsed-4.9...
pkg_install warnings: 0, errors: 0
reading local summary...
processing local summary...
marking gcc12-12.2.0 as non auto-removable
dr2# 

the following two commands

pkg_info -L gcc12 | grep /libexec/ | xargs ldd | grep libstdc
pkg_info -L gcc12 | grep /bin/ | xargs ldd | grep libstdc

gives absolutely nothing except for a few "magic number is bad" for
the shell scripts installed in those directories.

...and the unbound package build appears to work as intended (the
unbound build completed successfully), although auditing / verifying
that it actually did use gcc12 I find an obstacle instead:

dr2: {63} ls -l work/.cwrapper/bin/gcc
lrwxr-xr-x  1 he  125  37 May  2 11:24 work/.cwrapper/bin/gcc -> /usr/pkg/libexec/cwrappers/cc-wrapper
dr2: {64} 
dr2: {64} work/.cwrapper/bin/gcc --version
gcc: CWRAPPERS_CONFIG_DIR is missing from environment
dr2: {65}

That's annoying.  No default?

Looking around in work, I find:

dr2: {76} grep exec work/.cwrapper/config/cc
exec_path=/usr/pkgsrc/net/unbound/work/.cwrapper/bin/cc
exec=/usr/pkgsrc/net/unbound/work/.gcc/bin/gcc
append_executable=-pie
dr2: {77} 

and

dr2: {77} ls -l /usr/pkgsrc/net/unbound/work/.gcc/bin/gcc
lrwxr-xr-x  1 he  125  12 May  2 11:24 /usr/pkgsrc/net/unbound/work/.gcc/bin/gcc -> /usr/bin/gcc
dr2: {78} 

and that's definately not gcc12:

dr2: {78} /usr/bin/gcc --version
gcc (nb4 20200810) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

dr2: {79} 

I guess all that pkgsrc really wanted was (from compiler/gcc.mk):

_GCC_DIST_NAME:=        gcc12
.include "../../lang/${_GCC_DIST_NAME}/version.mk"

to get GCC12_DIST_VERSION defined?


So, at the end of my rant:

1) do we have any improvement points for symlink switching when new
   binary build results for a new pkgsrc branch become available?
   Do we have any tooling to assist in that decision?  Implicitly
   teaching users to switch to version-specific suffixes by being
   "too slow" in this action seems like bad idea, as it tends to
   create a user system maintenance issue.  (This is obviously the
   least important point.)

2) The main point: is the pkgin warning for the gcc12 and gcc10
   package installation spurious?  Is the bug with the generation of
   pkg_summary?  We really should not emit a warning which seems to
   indicate "this will not work" when it evidently does anyway.
   Teaching users to ignore warnings is bad practice.

Regards,

- Håvard