dev-lang/python-3.6.1-r1 fails to build with glibc 2.26 or rpc disabled Reproducible: Always
(In reply to Flo Gravo from comment #0) > dev-lang/python-3.6.1-r1 fails to build with glibc 2.26 or rpc disabled > > Reproducible: Always add "-I/usr/include/tirpc/" to CFLAGS & CXXFLAGS
How about adding append-cflags "-I/usr/include/tirpc" to the ebuild?
(In reply to Flo Gravo from comment #2) > How about adding > append-cflags "-I/usr/include/tirpc" > to the ebuild? I think that'll work too. IMO, using env & package.env is much easier
Don't forget to add net-libs/libtirpc to the DEPENDS too, if you patch the ebuild.
(In reply to Shane Peelar from comment #4) > Don't forget to add net-libs/libtirpc to the DEPENDS too, if you patch the > ebuild. for glibc-2.26 it's not necessary.
Just FYI, I'm pretty sure this bug applies to all versions of python, on all libc versions. Based off of the mailing list discussion, libtirpc and ntirpc need to be supported as well as the glibc sunrpc version, so simply appending to CFLAGS is not enough. No issue is encountered with musl on my end until libtirpc was installed for a different package, so I'm assuming there's an autodetect in the python configure that can tell that I have the libtirpc.pc file in pkgconfig, but it can't tell where the actual headers are, even though the path is set in the Cflags variable of the pkgconfig file.
Yeah. Other versions of python are also affected.
@everyone, * yes, this affects all python verions, if you have either glibc[-rpc] or >=glibc-2.26. * the workaround for the moment is to install net-libs/libtirpc and add -I/usr/include/tirpc somewhere to CFLAGS * I'm waiting because this affects many packages and I want a uniform solution, so it needs some discussion. See https://wiki.gentoo.org/wiki/Project:Toolchain/RPC_implementation News will be posted here. Please keep in mind that glibc-2.26 is still unkeyworded, meaning, if you try to use it you get to keep the pieces.
@python: pretty please; I dont think anything will still change in the plans. For glibc-2.26 support, each python needs at least the || ( net-libs/libnsl <sys-libs/glibc-2.26 ) dependency plus the mechanism for switching the RPC implementation and dependencies (see linked wiki page). [This only affects the nis module, I *think*, so disabling that might be another way out, but I'm pretty sure above libraries will be pulled in by something in @system anyway.] Right now in my @system chroot dev-lang/python is the only thing that doesnt rebuild.
AFAIU we're talking of an automagic dep here, so we should either add a USE flag and figure out a way to make it conditional, or dep unconditionally.
From setup.py: # Sun yellow pages. Some systems have the functions in libc. if (host_platform not in ['cygwin', 'qnx6'] and find_file('rpcsvc/yp_prot.h', inc_dirs, []) is not None): if (self.compiler.find_library_file(lib_dirs, 'nsl')): libs = ['nsl'] else: libs = [] exts.append( Extension('nis', ['nismodule.c'], libraries = libs) ) else: missing.append('nis') I would guess that glibc still installs rpcsvc/yp_prot.h for some reason. Was that intentional, or an oversight?
(In reply to Mike Gilbert from comment #11) > I would guess that glibc still installs rpcsvc/yp_prot.h for some reason. > Was that intentional, or an oversight? (~amd64 chroot) porto ~ # equery belongs rpcsvc/yp_prot.h * Searching for rpcsvc/yp_prot.h ... net-libs/libnsl-1.1.0 (/usr/include/rpcsvc/yp_prot.h) The problem is that the headers are split over various packages. That particular header is provided (for >=glibc-2.26) by net-libs/libnsl, which is the actual NIS/NIS+/... code (not the underlying rpc code). And net-libs/libnsl is already pulled into @system by something else. net-libs/libnsl again uses net-libs/libtirpc (which, e.g., provides rpc/rpc.h as /usr/include/tirpc/rpc/rpc.h).
So what file(s) do we need to check for to ensure that python will build with NIS support (optionally)? Would adding a check for rpc/rpc.h suffice? I would like a solution we can submit upstream, and we can tweak it for Gentoo after.
(In reply to Mike Gilbert from comment #13) > So what file(s) do we need to check for to ensure that python will build > with NIS support (optionally)? Would adding a check for rpc/rpc.h suffice? > > I would like a solution we can submit upstream, and we can tweak it for > Gentoo after. The way I understand it you need to make sure two parts are present (compare also my g-dev mail): 1) RPC implementation, sunrpc or libtirpc A good header to check is IMHO <rpc/rpc.h> (it's by default in /usr/include for sunrpc and in /usr/include/tirpc for libtirpc; libtirpc provides a .pc file as well); for libtirpc you need to link -ltirpc 2) NIS implementation, libnsl (either internal to glibc, or separate) That's what the existing check for <rpcsvc/yp_prot.h> tests for; in both cases it goes into /usr/include by default, and in both cases the library is -lnsl (different soversion though).
Thanks. I'll see if I can work on some solution. Also, copying Arfrever since he is usually helpful with python build system patches.
Created attachment 500566 [details, diff] patch, use "git am" to apply, fixes python:3.6 only Here's what could be a workable solution. @python, if you're happy with this I can extend it to the newest ~arch of each slot. Not really upstreamable in this form though, since without the ebuild logic it introduces bad automagic. With the ebuilds and the conditional patching it should be fine.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=56760ce3a29757b6cf00b585a9a1d480fdaf312f commit 56760ce3a29757b6cf00b585a9a1d480fdaf312f Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2017-11-11 16:07:33 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2017-11-11 16:07:46 +0000 dev-lang/python: disable the nis module This fails to build with glibc-2.26. Bug: https://bugs.gentoo.org/631488 Package-Manager: Portage-2.3.13_p1, Repoman-2.3.3_p81 dev-lang/python/files/2.7-disable-nis.patch | 21 ++ dev-lang/python/files/3.6-disable-nis.patch | 21 ++ dev-lang/python/python-2.7.14-r1.ebuild | 366 ++++++++++++++++++++++++++++ dev-lang/python/python-3.4.6-r1.ebuild | 358 +++++++++++++++++++++++++++ dev-lang/python/python-3.5.4-r1.ebuild | 363 +++++++++++++++++++++++++++ dev-lang/python/python-3.6.3-r1.ebuild | 343 ++++++++++++++++++++++++++ 6 files changed, 1472 insertions(+)}
Created attachment 503600 [details] failed build log (with enabled nis module) Example build log. libtirpc is installed (with rpc/rpc.h in /usr/include/tirpc), libnsl is installed and provides /usr/include/rpcsvc/yp_prot.h
(In reply to Larry the Git Cow from comment #17) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=56760ce3a29757b6cf00b585a9a1d480fdaf312f > > commit 56760ce3a29757b6cf00b585a9a1d480fdaf312f > Author: Mike Gilbert <floppym@gentoo.org> > AuthorDate: 2017-11-11 16:07:33 +0000 > Commit: Mike Gilbert <floppym@gentoo.org> > CommitDate: 2017-11-11 16:07:46 +0000 > > dev-lang/python: disable the nis module > Confirmed that the new versions (without nis module) build and install fine with sys-libs/glibc-2.26-r3
*** Bug 639458 has been marked as a duplicate of this bug. ***
*** Bug 639738 has been marked as a duplicate of this bug. ***
I stabilized the relevant ebuilds.
*** Bug 639800 has been marked as a duplicate of this bug. ***
