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

[Niclas Rosenvik <nros%netbsd.org@localhost>]

On Fri, 17 Nov 2023 13:28:17 +0100
"Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost> wrote:

> 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.
> 
Nice catch, we do have _OPSYS_LIB_DIRS so maybe the list should be
based on that, I will work up a possible fix. 


> 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
> 
>

I was thinking more in the lines of greg, add the pkgconfig
check to libtirpc and libnsl packages builtin.mk and buildlink these
packages to python only on linux. But there seems to be a need to check
if glibc has nis support as you mention.
I have been surfing around on pythons github page and they seem to have
removed the nis module from git[1], it won't be in python 3.13. See PEP
594.

Niclas