[MacPorts] #68810: OpenBLAS: libopenblas.0.dylib cannot find symbol _xerbla_

[MacPorts]

#68810: OpenBLAS: libopenblas.0.dylib cannot find symbol _xerbla_
-----------------------+-------------------------
  Reporter:  erikbs    |      Owner:  NicosPavlov
      Type:  defect    |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:
Resolution:            |   Keywords:
      Port:  OpenBLAS  |
-----------------------+-------------------------

Comment (by erikbs):

 > produce a usable object file when
 {{{
 cd
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/build/driver/others
 && /opt/local/bin/clang-mp-16
 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/OpenBLAS-0.3.25
 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/build
 -pipe -O3 -DNDEBUG -I/opt/local/include -arch x86_64  -DHAVE_C11 -Wall
 -m64 -mavx2 -mavx -msse -msse2 -msse3 -mssse3 -msse4.1 -fPIC
 -DSMALL_MATRIX_OPT -DNO_AVX512 -DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=8
 -DMAX_PARALLEL_NUMBER=1 -DMAX_STACK_ALLOC=2048 -DNO_AFFINITY
 -DVERSION="\"0.3.25\"" -DBUILD_SINGLE -DBUILD_DOUBLE -DBUILD_COMPLEX
 -DBUILD_COMPLEX16 -arch x86_64 -mmacosx-version-min=10.9 -MD -MT
 driver/others/CMakeFiles/driver_others.dir/xerbla.c.o -MF
 CMakeFiles/driver_others.dir/xerbla.c.o.d -o
 CMakeFiles/driver_others.dir/xerbla.c.o -c
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/OpenBLAS-0.3.25/driver/others/xerbla.c
 }}}
 > does not

 Turns out that it actually does … If I manually run this command when the
 build fails (to regenerate `xerbla.c.o`) and then resume the build using
 `port install -o`, everything works just fine. I can even do
 {{{
 sudo port install -s -o openblas +gcc13 +lapack +native
 sudo rm
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/build/driver/others/CMakeFiles/driver_others.dir/xerbla.c.o*
 sudo port install -s -o openblas +gcc13 +lapack +native
 }}}
 to make it complete successfully.

 Thinking that there must have been something with the build order that
 caused things to fail, I copied the object file from both runs to a
 temporary location to compare them. The result confused me:
 {{{
 md5 */xerbla.c.o
 MD5 (verkar/xerbla.c.o) = 57ac55a93b3cde59adeaaccb658f6206
 MD5 (verkar_ikkje/xerbla.c.o) = 57ac55a93b3cde59adeaaccb658f6206
 }}}
 The files are identical. And sure enough, a simple `touch <..>/xerbla.c.o`
 (instead of `rm`) also makes the build succeed! In fact, after
 experimenting with timestamps, it seems that it is enough if
 `./driver/others/CMakeFiles/driver_others.dir/xerbla.c.o` is newer than
 `./interface/CMakeFiles/interface.dir/CMakeFiles/xerbla.c.o`. `man ar`
 revealed that this is the expected behaviour for the `-u` option.

 My preliminary conclusion is that it is *not* weak linking that is the
 solution on older Mac OS X versions, but rather one of these options:
 1. Ensure that the the correct `xerbla.c.o` is either linked first or
 compiled last
 2. Make `ar` update `xerbla.c.o` even though the modification time is
 older than the existing entry. This can be done by using `ar -rs` instead
 of `ar -ru`.

 Luckily `xerbla.c.o` is linked separately and not as part of a bulk
 operation, so we can safely change `ar -ru` to `ar -rs` without
 consequences for other object files (I found about 75 .o files that are
 not unique in the build tree).

 I have submitted a pull request to OpenBLAS:
 https://github.com/OpenMathLib/OpenBLAS/pull/4353

-- 
Ticket URL: <https://trac.macports.org/ticket/68810#comment:7>
MacPorts <https://www.macports.org/>
Ports system for macOS