MAINT, BLD: symbol visibility warnings on MacOS ARM static lib with clang c++17

[tylerjereddy]

trafficstars

With meson 1.4.0, on latest main (bd42f896a), via FC=gfortran-12 python dev.py test -j 8 I see the build output warning below, though the full suite passes otherwise. Using Apple clang version 15.0.0 (clang-1500.3.9.4).

../scipy/_lib/highs/src/util/HighsDataStack.h:27:34: note: expanded from macro 'IS_TRIVIALLY_COPYABLE'
#define IS_TRIVIALLY_COPYABLE(T) __has_trivial_copy(T)
                                 ^
29 warnings generated.
[1477/1477] Linking target scipy/optimize/_highs/_highs_wrapper.cpython-311-darwin.so
ld: warning: direct access in function '__pyx_pymod_exec__highs_wrapper(_object*)' from file 'scipy/optimize/_highs/_highs_wrapper.cpython-311-darwin.so.p/meson-generated__highs_wrapper.cpp.o' to global weak symbol 'std::__1::piecewise_construct' from file 'scipy/optimize/_highs/libhighs.a(.._..__lib_highs_extern_filereaderlp_reader.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
<snip more similar warnings>

Looks like static library symbol visibility is a bit annoying to fix on MacOS perhaps: https://stackoverflow.com/questions/2222162/how-to-apply-fvisibility-option-to-symbols-in-static-libraries

Bisected to commit below, C++ standards fun I guess. Perhaps gh-19255 will help with this, but not fully sure what's going on over there.

10c2a45586d8a169a0407efc90753ebfc0dbd626 is the first bad commit
commit 10c2a45586d8a169a0407efc90753ebfc0dbd626
Author: Lucas Colley <[email protected]>
Date:   Fri Jan 5 14:10:28 2024 +0000

    BLD: set default `cpp_std` to `c++17`
    [wheel build] [skip circle]

 meson.build                              | 2 +-
 scipy/io/_fast_matrix_market/meson.build | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

[lucascolley]

Ah, I suppose I missed these warnings during that PR due to all of the other warnings which are there atm... I did notice this recently.

[rgommers]

We should get gh-19255 merged before worrying about this I think (unless this is very easy to fix), since that changes how the relevant HiGHS code is built and used.

[andyfaff]

is there anyone to ping on this, multiple warnings whilst building on macOS.

[rgommers]

Well, we merged gh-19255 recently, and then had to revert it. A second attempt here will help.

I'll note that while the __has_trivial_copy went away, it did also bring in new warnings. Those are more easily silenced - I already took care of most of those upstream in HiGHS. The C++ code in HiGHS isn't very clean unfortunately, so with each bump we may have to spend some extra effort in fixing things up.

[rgommers]

I was not seeing this locally with conda-forge compilers, but it should be fixed by gh-20919. The build is clean for me on macOS except for a single warning about nm from libsf_error_state.dylib, which is tracked in gh-20740.