Re: Please help testing/debugging math/openblas (and variants) on Darwin

Am Sun, 01 Mar 2026 03:47:11 +0000
schrieb Brian Callahan <[email protected]>:

> Built fine for me on
> 
> Darwin Brians-MBP-2 22.6.0 Darwin Kernel Version 22.6.0: Tue Jul 15 
> 08:22:28 PDT 2025; root:xnu-8796.141.3.713.2~2/RELEASE_X86_64 x86_64

OK. So we can diff with Adam's setup now.

> => Checking file-check results for openblas-0.3.31  
> ERROR: ************************************************************
> ERROR: The following files are in 
> /Users/briancallahan/pkgsrc/math/openblas/work/.destdir/opt/pkg but not 
> in the PLIST:
> ERROR: 
>   /Users/briancallahan/pkgsrc/math/openblas/work/.destdir/opt/pkg/lib/libopenblas..0.dylib
> *** Error code 1

OK, two points:

1. This is an error in my patching. I committed 0.3.31nb1 now to fix
   the double dot in there. Does it just work now for you, Brian?

2. Do we have magic translation of PLIST that makes 

lib/lib${OPENBLAS_VARIANT}.a
lib/lib${OPENBLAS_VARIANT}.so
lib/lib${OPENBLAS_VARIANT}.so.0

work on Darwin as if it would read

lib/lib${OPENBLAS_VARIANT}.a
lib/lib${OPENBLAS_VARIANT}.dylib
lib/lib${OPENBLAS_VARIANT}.0.dylib

? Current PLIST does not mention dylibs. Did it ever work on Darwin
with disabled checking of PLIST only?


Alrighty then,

Thomas


PS: It irks me a lot having to put PKGREVISIONS in all packages using
the common source, Makefile.common and patch set when I change one of
the common patches. Feels error-prone and redundant. Plus: In this case,
theoretically only the Darwin packages would need a pkgrev, as others
are unchanged … I thought revbump.py (why the .py suffix for a tool in
PATH?) could be related, but it's only for depending packages that need
rev bumped for some reason, not linked packages through a common
Makefile. Plus: It of course doesn't recognize openblas dependencies,
as this is hidden behind blas.bl3. Though, it sees one, which seems to
be a bug in that package. Plus, there seems to be another bug:

$ revbump.py -p /path/to/pkgsrc/ -n math/openblas
math/openblas
ames/naev

This should read games/naev. Somehow a g went missing. But also, it
probably should not depend on math/openblas directly, omitting the
option for a multithreaded variant, for example. One needs to fix it to
depend on blas.bl3 and enable choice. I don't really see me testing the
build of that game, though. No time for that.


-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg