Re: lib/58648: private shared libraries should go in /usr/lib/private, not /usr/lib

[gnats-admin%netbsd.org@localhost]

The following reply was made to PR lib/58648; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: matthew green <mrg%eterna23.net@localhost>, lib-bug-people%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
	gnats-bugs%netbsd.org@localhost
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@localhost>
 >=20
 > > On Aug 27, 2024, at 2:58=E2=80=AFPM, matthew green <mrg%eterna23.net@localhost> 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.