NetBSD Problem Report #57715

From www@netbsd.org  Tue Nov 21 03:33:11 2023
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 33DDE1A9238
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 21 Nov 2023 03:33:11 +0000 (UTC)
Message-Id: <20231121033310.3DF051A9239@mollari.NetBSD.org>
Date: Tue, 21 Nov 2023 03:33:10 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: gcc packages in x86_64/9.x_2023Q3 spuriously have REQUIRES=/usr/lib/libstdc++.so.7
X-Send-Pr-Version: www-1.0

>Number:         57715
>Category:       pkg
>Synopsis:       gcc packages in x86_64/9.x_2023Q3 spuriously have REQUIRES=/usr/lib/libstdc++.so.7
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 21 03:35:01 +0000 2023
>Originator:     Taylor R Campbell
>Release:        x86_64/9.x_2023Q3
>Organization:
The NetBSD Pkgbuildation
>Environment:
>Description:
The gcc packages in the x86_64 package repository for 9.x from the 2023Q3 branch have been built with spurious REQUIRES=/usr/lib/libstdc++.so.7, making them impossible to install.

The amd64-nb9 package builder has some bizarre symlinks in /chroot/usr/lib that might explain this, although I don't know why these symlinks exist:

amd64-nb9$ cd /chroot/slave1/usr/lib && ls -ld *libstdc++*
-r--r--r--  1 root  wheel   4564266 May 30  2020 libstdc++.a
lrwxr-xr-x  1 root  wheel        16 May 30  2020 libstdc++.so -> libstdc++.so.9.0
lrwxr-xr-x  1 root  wheel        43 Apr  8  2022 libstdc++.so.5 -> /usr/pkg/emul/netbsd/usr/lib/libstdc++.so.5
lrwxr-xr-x  1 root  wheel        45 Apr  8  2022 libstdc++.so.5.0 -> /usr/pkg/emul/netbsd/usr/lib/libstdc++.so.5.0
lrwxr-xr-x  1 root  wheel        43 Apr 24  2022 libstdc++.so.6 -> /usr/pkg/emul/netbsd/usr/lib/libstdc++.so.6
lrwxr-xr-x  1 root  wheel        45 Apr 24  2022 libstdc++.so.6.0 -> /usr/pkg/emul/netbsd/usr/lib/libstdc++.so.6.0
lrwxr-xr-x  1 root  wheel        16 Mar 12  2017 libstdc++.so.7 -> libstdc++.so.7.3
lrwxr-xr-x  1 root  wheel        45 Apr  8  2022 libstdc++.so.7.1 -> /usr/pkg/emul/netbsd/usr/lib/libstdc++.so.7.1
-r--r--r--  1 root  wheel   1318682 Mar 12  2017 libstdc++.so.7.3
lrwxr-xr-x  1 root  wheel        43 Mar 30  2022 libstdc++.so.8 -> /usr/pkg/emul/netbsd/usr/lib/libstdc++.so.8
lrwxr-xr-x  1 root  wheel        45 Mar 30  2022 libstdc++.so.8.0 -> /usr/pkg/emul/netbsd/usr/lib/libstdc++.so.8.0
lrwxr-xr-x  1 root  wheel        16 May 30  2020 libstdc++.so.9 -> libstdc++.so.9.0
-r--r--r--  1 root  wheel   2042576 May 30  2020 libstdc++.so.9.0
-r--r--r--  1 root  wheel   4813338 May 30  2020 libstdc++_p.a
-r--r--r--  1 root  wheel  14850750 Mar 12  2017 libstdc++_pic.a

My best guess is that the libstdc++.so.7.3 symlink is a relic of a former netbsd-8 installation -- and for some reason we're not using a clean netbsd-9 chroot in the builder.  I have no idea what the /usr/pkg/emul symlinks are doing in /usr/lib.
>How-To-Repeat:
pkg_info -B https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/x86_64/9.0_2023Q3/All/gcc13-13.2.0.tgz

(or pkg_add and watch it fail)
>Fix:
Yes, please!

1. Rebuild the packages in a clean chroot.
2. Figure out why libstdc++.so.7 is leaking into the gcc packages even if the chroot isn't a clean netbsd-9 install -- after all, users might reasonably have upgraded from netbsd-8.  The libstdc++.so symlink points to libstdc++.so.9.0, so it shouldn't be getting picked up here.

Home	PR Database Search