Build errors in Python packages with compiled extensions
John Kennedy
warlock at phouka.net
Wed Dec 23 01:27:07 UTC 2020
On Tue, Dec 22, 2020 at 08:47:35PM +0100, Christian Ullrich wrote:
> Hello,
>
> I have started to notice poudriere builds of Python ports with compiled extensions failing:
>
> [00:00:11] /usr/bin/strip /wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so
> [00:00:11] strip: open /wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so failed: No such file or directory
>
> The reason is that setuptools puts a version tag (aka cache tag) into the .so's name; in this case it is actually _cffi_backend.cpython-38.so . The strip command, on the other hand, is in the port Makefile's post-install target and has the file name as above, without the version.
>
> This tag is to be available in Uses/python.mk as $PYMAGICTAG, e.g. "cpython-38".
>
> I'm not sure whether I'm not doing something wrong that causes the tag to end up in the .so file names. The last update to devel/py-setuptools was a while ago (to 44.0 in January 2020), and someone would probably have noticed since. On the other hand, this _is_ poudriere, so the build environments are pretty well isolated.
>
> Anyone know what is going on?
Not just you. As soon as I upgraded python38 from 3.8.6_1 -> 3.8.7, I ran
into the same kind of problems... my local poudriere build failed 7 python
packages and skipped another 96. I don't have the exact same setup, but it
happened on both -CURRENT and releng/12.2.
So, ports rev 558913 ~Tue Dec 22 14:58:05 2020 +0000.
I opened up bug 252057.
More information about the freebsd-ports
mailing list