NetBSD Problem Report #58648

From www@netbsd.org  Tue Aug 27 00:32:18 2024
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)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 7A8131A9241
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 27 Aug 2024 00:32:18 +0000 (UTC)
Message-Id: <20240827003217.866CA1A9242@mollari.NetBSD.org>
Date: Tue, 27 Aug 2024 00:32:17 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: private shared libraries should go in /usr/lib/private, not /usr/lib
X-Send-Pr-Version: www-1.0

>Number:         58648
>Category:       lib
>Synopsis:       private shared libraries should go in /usr/lib/private, not /usr/lib
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 27 00:35:00 +0000 2024
>Last-Modified:  Wed Aug 28 04:50:01 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The LibBSD Private Foundation
>Environment:
>Description:
NetBSD base ships with various shared libraries that are used internally by programs and daemons included in NetBSD but that really shouldn't be exposed as libraries -- this leads to unnecessary conflicts, e.g. with libsqlite3 or libssh.

Currently the only mechanism we have for hiding these is to statically link them, even if they are reused by multiple programs in base, like like libgmp.

We should be able to use shared libraries in base programs without also exposing them to pkgsrc.
>How-To-Repeat:
struggle with pkgsrc conflicts
>Fix:
1. Introduce /usr/lib/private.
2. Rule: Nothing in /usr/lib outside /usr/lib/private can link against anything in it.  We can enforce this by simply not putting /usr/lib/private in any rpaths when linking libraries, and adding it only to the executables that do use /usr/lib/private.
3. Move various libraries such as libsqlite3 and libssh under /usr/lib/private.

>Audit-Trail:
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org, gnats-admin@NetBSD.org
Subject: Re: lib/58648: private shared libraries should go in
 /usr/lib/private, not /usr/lib
Date: Tue, 27 Aug 2024 11:29:10 +0200

 On Tue, 27 Aug 2024 00:35:01 +0000 (UTC), campbell+netbsd@mumble.net=20
 wrote:
 > 1. Introduce /usr/lib/private.

 How about something like /usr/libpriv, similar to /usr/lib{data,exec}?

 Cheerio,
 Hau"bikeshedding"ke

 --=20
 Hauke Fath                        <hauke@Espresso.Rhein-Neckar.DE>
 Linn=E9weg 7
 64342 Seeheim-Jugenheim
 Germany

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/58648: private shared libraries should go in
 /usr/lib/private, not /usr/lib
Date: Tue, 27 Aug 2024 11:44:23 +0200

 Can we create a full list of the affected binaries and applications using
 them?

 Maybe something like

 	/lib/private/{bind,ssh,dhcp,..}/

 would make sense (but if the overall count is small it won't). And
 obviously there can't be name clashes (at least with the current
 state).

 Martin

From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 campbell+netbsd@mumble.net
Subject: Re: lib/58648: private shared libraries should go in
 /usr/lib/private, not /usr/lib
Date: Tue, 27 Aug 2024 09:33:30 -0400

 > On Aug 27, 2024, at 5:40=E2=80=AFAM, gnats-admin@netbsd.org wrote:
 >=20
 > The following reply was made to PR lib/58648; it has been noted by =
 GNATS.
 >=20
 > From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
 > To: gnats-bugs@netbsd.org
 > Cc: lib-bug-people@netbsd.org, gnats-admin@NetBSD.org
 > Subject: Re: lib/58648: private shared libraries should go in
 > /usr/lib/private, not /usr/lib
 > Date: Tue, 27 Aug 2024 11:29:10 +0200
 >=20
 > On Tue, 27 Aug 2024 00:35:01 +0000 (UTC), =
 campbell+netbsd@mumble.net=3D20
 > wrote:
 >> 1. Introduce /usr/lib/private.
 >=20
 > How about something like /usr/libpriv, similar to /usr/lib{data,exec}?
 >=20

 I was even thinking /usr/private/lib /usr/private/include etc.

 christos

From: matthew green <mrg@eterna23.net>
To: Christos Zoulas <christos@zoulas.com>
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, campbell+netbsd@mumble.net,
    gnats-bugs@netbsd.org
Subject: re: lib/58648: private shared libraries should go in /usr/lib/private, not /usr/lib
Date: Wed, 28 Aug 2024 04:58:21 +1000

 > I was even thinking /usr/private/lib /usr/private/include etc.

 don't want to *install* headers.  they're not for development,
 not even with comp set installed.

 those will remain private in the build itself, we only want this
 to have a shared copy of relatively large libraries like gmp and
 pals..


 .mrg.

From: Christos Zoulas <christos@zoulas.com>
To: matthew green <mrg@eterna23.net>
Cc: lib-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 campbell+netbsd@mumble.net,
 gnats-bugs@netbsd.org
Subject: Re: lib/58648: private shared libraries should go in
 /usr/lib/private, not /usr/lib
Date: Tue, 27 Aug 2024 15:01:33 -0400

 > On Aug 27, 2024, at 2:58=E2=80=AFPM, matthew green <mrg@eterna23.net> =
 wrote:
 >=20
 >> I was even thinking /usr/private/lib /usr/private/include etc.
 >=20
 > don't want to *install* headers.  they're not for development,
 > not even with comp set installed.
 >=20
 > those will remain private in the build itself, we only want this
 > to have a shared copy of relatively large libraries like gmp and
 > pals..
 >=20

 But you need the headers for autoconf to find stuff and for other
 internal users of the libraries. This is how we ended up with the
 gdb gmp/mpfr/mpc mess copying headers (because some are
 in the same dir as config.h and we can't just -I/path/to/gmpdoth).

 christos=

From: Taylor R Campbell <riastradh@NetBSD.org>
To: Christos Zoulas <christos@zoulas.com>
Cc: matthew green <mrg@eterna23.net>, lib-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	gnats-bugs@netbsd.org
Subject: Re: lib/58648: private shared libraries should go in
	/usr/lib/private, not /usr/lib
Date: Tue, 27 Aug 2024 19:31:07 +0000

 > Date: Tue, 27 Aug 2024 15:01:33 -0400
 > From: Christos Zoulas <christos@zoulas.com>
 >=20
 > > On Aug 27, 2024, at 2:58=E2=80=AFPM, matthew green <mrg@eterna23.net> w=
 rote:
 > >=20
 > >> I was even thinking /usr/private/lib /usr/private/include etc.
 > >=20
 > > don't want to *install* headers.  they're not for development,
 > > not even with comp set installed.
 > >=20
 > > those will remain private in the build itself, we only want this
 > > to have a shared copy of relatively large libraries like gmp and
 > > pals..
 >=20
 > But you need the headers for autoconf to find stuff and for other
 > internal users of the libraries. This is how we ended up with the
 > gdb gmp/mpfr/mpc mess copying headers (because some are
 > in the same dir as config.h and we can't just -I/path/to/gmpdoth).

 These must never be taken from the host system's libraries, so there
 is no need to install them.  They must always be taken from what we
 built out of src; otherwise if you have, e.g., a too-old gmp in /usr,
 you can't use build.sh to build a NetBSD with newer gmp/gdb/gcc/&c.

 If `build.sh tools' even looks for a systemwide gmp.h or libgmp.so,
 that's a serious bug in our build system.

 The point is that absolutely nothing in an installed system should
 ever look at /usr/lib/private, _except_ for executables that are
 included in that system and linked against those libraries.

From: matthew green <mrg@eterna23.net>
To: Christos Zoulas <christos@zoulas.com>
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, campbell+netbsd@mumble.net,
    gnats-bugs@netbsd.org
Subject: re: lib/58648: private shared libraries should go in /usr/lib/private, not /usr/lib
Date: Wed, 28 Aug 2024 14:46:07 +1000

 > But you need the headers for autoconf to find stuff and for other
 > internal users of the libraries. This is how we ended up with the
 > gdb gmp/mpfr/mpc mess copying headers (because some are
 > in the same dir as config.h and we can't just -I/path/to/gmpdoth).

 we can make that a "special mknative" feature.

 don't install them for normal builds.  it's only going to make
 it 100% likely something will find and use them and the whole
 point of this is to stop that happening.


 .mrg.

Home	PR Database Search