Re: using pkg-config modules from host (Re: wip/py-numpy + blas)

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Fri, 17 Nov 2023 12:10:54 +0100
schrieb Niclas Rosenvik <nros%netbsd.org@localhost>:

> look at mk/buildlink3/find-pkgconfig-files.mk ,
> they are all listed there.

Oh, thanks.

> libtirpc(devel/libtirpc) is already in pkgsrc and just
> need pkg-config stuff in its builtin.mk.
> libnsl is not in pkgsrc and would this not conflict with nsl in
> solaris/illumos??

I suspect libnsl is only needed on systems where it is present in the
system. Of course a Linux/glibc base could have the library as such but
no development files installed for it, but without libc and associated
development files, pkgsrc wouldn't work at all.

This is complicated by older glibc installs that do have the respective
functionality without added libnsl.

The python311 package needs to depend on libnsl (+libtirpc?) if and
only if those are present in the system already. And only then
PLIST.nis=yes.

I wonder if a package with a builtin.mk is the right thing in that
case, anyway.

Regarding the search directories:

BUILTIN_PKGCONFIG_DIRS?=	/usr/lib/pkgconfig				\
				/usr/share/pkgconfig				\
				/usr/libdata/pkgconfig				\
				/usr/lib/x86_64-linux-gnu/pkgconfig		\
				/usr/lib/aarch64-linux-gnu/pkgconfig		\
				/usr/lib/arm-linux-gnueabi/pkgconfig		\
				/usr/lib/arm-linux-gnueabihf/pkgconfig		\
				/usr/lib/i386-linux-gnu/pkgconfig		\
				/usr/lib/mips64el-linux-gnuabi64/pkgconfig	\
				/usr/lib/mipsel-linux-gnu/pkgconfig		\
				/usr/lib/powerpc64le-linux-gnu/pkgconfig	\
				/usr/lib/s390x-linux-gnu/pkgconfig


I'll probably want to extend/override that in case I build pkgsrc with
a custom toolchain (compiler + MPI libraries, maybe also Intel MKL
stuff). But also: It occurs to me that on a true multiarch install, it should
not matter that /usr/lib/x86_64-linux-gnu/ exists besides
/usr/lib/mips64el-linux-gnuabi64 despite running on a MIPS cpu. Pkgsrc
would pick up the wrong library .pc file, as it always prefers
x86_64-linux-gnu (and ignores x86_64-linux-musl, for example).

This static list works for the vast majority of cases, but anywhere
someone really does what multiarch promises to make possible, share a
common /usr among different machine types, it will break things.

Anyhow … I hacked now this which seems to fix lang/python311 on an
Ubuntu system:

Index: Makefile
===================================================================
RCS file: /cvsroot/pkgsrc/lang/python311/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- Makefile	10 Nov 2023 16:55:32 -0000	1.20
+++ Makefile	17 Nov 2023 12:23:48 -0000
@@ -112,6 +112,17 @@
 .if ${OPSYS} != "Linux"
 PLIST.dbm=	yes
 .endif
+
+# On glibc systems, those two libs must be locatable via pkg-config for
+# the python configure to utilize them to build the NIS module.
+BUILTIN_FIND_PKGCONFIG_FILES_VAR:=	TIRPC_PC NSL_PC
+BUILTIN_FIND_PKGCONFIG_FILES.TIRPC_PC:=	libtirpc.pc
+BUILTIN_FIND_PKGCONFIG_FILES.NSL_PC:=	libnsl.pc
+.include "../../mk/buildlink3/find-pkgconfig-files.mk"
+.if ${NSL_PC} != __nonexistent__ && ${TIRPC_PC} != __nonexistent__
+PLIST.nis=	yes
+.endif
+
 .for incdir in ${_OPSYS_INCLUDE_DIRS}
 .  if (exists(${incdir}/rpc/rpc.h) || exists(${incdir}/tirpc/rpc/rpc.h))
 HAVE_RPC_H=	yes
@@ -207,6 +218,11 @@
 CHECK_WRKREF_SKIP+=	lib/python${PY_VER_SUFFIX}/__pycache__/_sysconfigdata*
 CHECK_WRKREF_SKIP+=	lib/python${PY_VER_SUFFIX}/config-${PY_VER_SUFFIX}/Makefile

+pre-configure:
+.if ${PLIST.nis:Uno} == yes
+	${LN} -sf ${TIRPC_PC:Q} ${NSL_PC:Q} ${BUILDLINK_DIR}/lib/pkgconfig
+.endif
+
 # Avoid error: Cannot generate ./Include/opcode.h, python not found !
 post-configure:
	touch ${WRKSRC}/Include/opcode.h


Thoughts? (The pkglint complaints are unrelated to these changes.)

If that's the way to do it, I imagine automating the hackish symlink
part.


Alrighty then,

Thomas


-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg