Python 3.8 build, bombs out with error

[Kubilay Kocak]

On 16/05/2021 7:35 am, David Mehler wrote:
> Hello,
> 
> Trying to build Python 3.8 with my poudriere and it's bombing out with an error.
> 
> tail -n 20 /usr/local/poudriere/data/logs/bulk/latest-per-pkg/python38/3.8.9/122-default.log
> rm -r /wrkdirs/usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/__pycache__
> install  -m 0644 ./Misc/python.man
> /wrkdirs/usr/ports/lang/python38/work/stage/usr/local/man/man1/python3.8.1
> if test "xno" != "xno"  ; then  case no in  upgrade)
> ensurepip="--altinstall --upgrade" ;;  install|*)
> ensurepip="--altinstall" ;;  esac;
> LD_LIBRARY_PATH=/wrkdirs/usr/ports/lang/python38/work/Python-3.8.9
> ./python -E -m ensurepip  $ensurepip
> --root=/wrkdirs/usr/ports/lang/python38/work/stage/ ;  fi
> /bin/rm -f /wrkdirs/usr/ports/lang/python38/work/stage/usr/local/lib/libpython3.so
>                                               #
> Upstream Issue: https://bugs.python.org/issue17975
> for i in /wrkdirs/usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/*.so;
> do  /usr/bin/strip $i; done
>                   # Strip shared extensions
> install  -m 0644
> /wrkdirs/usr/ports/lang/python38/work/Python-3.8.9/Tools/gdb/libpython.py
>   /wrkdirs/usr/ports/lang/python38/work/stage/usr/local/lib/libpython3.8.so.1.0-gdb.py
> ====> Compressing man pages (compress-man)
> ===========================================================================
> =======================<phase: package        >============================
> ===>  Building package for python38-3.8.9
> pkg-static: Unable to access file
> /wrkdirs/usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_ctypes.cpython-38.so:No
> such file or directory
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/lang/python38
> =>> Cleaning up wrkdir
> ===>  Cleaning for python38-3.8.9
> build of lang/python38 | python38-3.8.9 ended at Sat May 15 13:15:31 EDT 2021
> build time: 00:00:52
> !!! build failure encountered !!!
> 
> Is there something I can do to fix this?
> 

There will be an error earlier in the build when attempting to build the 
ctypes shared extension, which, if it fails due to an error, will result 
in the shared extension being named to <name>_failed.so resulting in the 
packaging error observed.

That build or linking error will isolate the cause