pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: py313-pybind11 build fails on netbsd-11/amd64?
On Sat, 14 Mar 2026, Greg Troxel wrote:
> "John D. Baker" <jdbaker%consolidated.net@localhost> writes:
>
> > Having updated to pkgsrc-HEAD prior to the freeze leading to pkgsrc-2026Q1,
> > I've updated my usual complement of packages for netbsd-11 (11.0_RC2) for
> > NetBSD/amd64 except for "graphics/py313-Pillow" because its dependency,
> > "devel/py313-pybind11" fails to build as follows:
>
> What architecture? Are you using i386?
This is amd64 (x86_64):
$ uname -a
NetBSD plex760.technoskunk.fur 11.0_RC2 NetBSD 11.0_RC2 (PLEX760) #19: Wed Mar 4 22:06:19 CST 2026 sysop%plex760.technoskunk.fur@localhost:/r0/build/netbsd-11/obj/amd64/sys/arch/amd64/compile/PLEX760 amd64
> I today built pybind11 on NetBSD 10 amd64 and I just built it on NetBSD
> 11 (11.0_RC2) amd64.
>
> I am confused that pybind11 is depending on scikit.
$ pwd
/x/pkgsrc/devel/py-pybind11
$ make show-all-depends
depends:
pkg TOOL_DEPENDS= \
cmake>=3.15:../../devel/cmake \
cwrappers>=20150314:../../pkgtools/cwrappers \
mktools-[0-9]*:../../pkgtools/mktools \
py313-build>=0:../../devel/py-build \
py313-installer>=0.7.0nb1:../../misc/py-installer \
py313-scikit-build-core>=0.11.2:../../devel/py-scikit-build-core \
# end of TOOL_DEPENDS (sorted)
pkg BUILD_DEPENDS= # empty
pkg TEST_DEPENDS= \
py313-test-[0-9]*:../../devel/py-test \
# end of TEST_DEPENDS (sorted)
pkg DEPENDS= \
python313>=3.13.0:../../lang/python313 \
python313>=3.13:../../lang/python313 \
# end of DEPENDS (sorted)
def _DEPENDS_FILE= /tmp/pkgsrc/devel/py-pybind11/work/.depends
def _RDEPENDS_FILE= /tmp/pkgsrc/devel/py-pybind11/work/.rdepends
> I just built py313-Pillow (N 11 amd64) and that went fine, and had no
> deps on numpy/scikit/scipy, just graphics format libs. That was on
> 2025Q4. It builds fine on pkgsrc-HEAD on N 10 amd64.
$ pwd
/x/pkgsrc/graphics/py-Pillow
$ make show-all-depends
depends:
pkg TOOL_DEPENDS= \
cwrappers>=20150314:../../pkgtools/cwrappers \
glib2-tools-[0-9]*:../../devel/glib2-tools \
mktools-[0-9]*:../../pkgtools/mktools \
pkgconf-[0-9]*:../../devel/pkgconf \
py313-build>=0:../../devel/py-build \
py313-installer>=0.7.0nb1:../../misc/py-installer \
py313-setuptools>=78:../../devel/py-setuptools \
# end of TOOL_DEPENDS (sorted)
pkg BUILD_DEPENDS= \
py313-pybind11>=2.5.0:../../devel/py-pybind11 \
# end of BUILD_DEPENDS (sorted)
pkg TEST_DEPENDS= \
ghostscript-[0-9]*:../../print/ghostscript \
netpbm-[0-9]*:../../graphics/netpbm \
py313-numpy-[0-9]*:../../math/py-numpy \
py313-olefile-[0-9]*:../../devel/py-olefile \
py313-test-[0-9]*:../../devel/py-test \
py313-test-cov-[0-9]*:../../devel/py-test-cov \
py313-test-timeout-[0-9]*:../../devel/py-test-timeout \
# end of TEST_DEPENDS (sorted)
pkg DEPENDS= \
freetype2>=2.1.3:../../graphics/freetype2 \
freetype2>=2.13.0:../../graphics/freetype2 \
freetype2>=2.13.2nb1:../../graphics/freetype2 \
lcms2>=2.2:../../graphics/lcms2 \
libavif>=1.0.3:../../graphics/libavif \
libimagequant>=4.2.0:../../graphics/libimagequant \
libjpeg-turbo>=1.1.0:../../graphics/libjpeg-turbo \
libwebp>=0.2.0:../../graphics/libwebp \
libwebp>=0.6.0:../../graphics/libwebp \
openjpeg>=2.1.0:../../graphics/openjpeg \
openjpeg>=2.1.0:../../graphics/openjpeg \
python313>=3.13.0:../../lang/python313 \
python313>=3.13:../../lang/python313 \
raqm>=0.10.1:../../graphics/raqm \
raqm>=0.10.3nb1:../../graphics/raqm \
tiff>=3.6.1:../../graphics/tiff \
tiff>=4.7.0nb3:../../graphics/tiff \
# end of DEPENDS (sorted)
def _DEPENDS_FILE= /tmp/pkgsrc/graphics/py-Pillow/work/.depends
def _RDEPENDS_FILE= /tmp/pkgsrc/graphics/py-Pillow/work/.rdepends
> Are you sure your tree matches pkgsrc HEAD?
It's been a day or so since I last updated, but I can be sure to
use "-A" again the next time to be sure there are no tags from
pkgsrc-2025Q4 hanging around.
If that doesn't work, move "distfiles" and "wip" aside, nuke it and check
it out again from scratch.
> As for the mismatch, on i386 we build for i486. But there are cpuflags
> sometimes, and there's atomic64.mk, and that might end up with a higher
> cpu type that might enable some vector stuff, and then some other lib
> might not use atomic64 and not use that same vector stuff. That's some
> blend of speculation, rambling, and a clue; don't take it too seriously.
I'm not (yet) building anything for i386(i486), but when I do, this may
become relevant.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Home |
Main Index |
Thread Index |
Old Index