[Meson] Fix how we link the OpenMP library

[amontoison]

No description provided.

[amontoison]

@nimgould
I try to compile on Mac with the options of Clang and I remarked two specific routines OpenMP are not found when we compile with 64-bit integer:

[00:44:19] Undefined symbols for architecture arm64:
[00:44:19]   "_omp_set_max_active_levels_8_", referenced from:
[00:44:19]       ___spral_ssids_single_64_MOD_pop_omp_settings in meson-generated_single_ssids.f90.o
[00:44:19]   "_omp_set_num_threads_8_", referenced from:
[00:44:19]       ___spral_ssids_fkeep_single_64_MOD_inner_factor_cpu._omp_fn.0 in meson-generated_single_fkeep.f90.o

I am wondering if our issue on Mac is not related to how libgomp and libomp collapsed on this platform.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 43.34%. Comparing base (5c29ddf) to head (b5007ee).
Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #379      +/-   ##
==========================================
- Coverage   43.39%   43.34%   -0.05%     
==========================================
  Files         313      313              
  Lines      161943   161943              
  Branches    56197    56197              
==========================================
- Hits        70269    70194      -75     
- Misses      74098    74180      +82     
+ Partials    17576    17569       -7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nimgould]

Thanks for persevering with this @amontoison

I have looked to see what flags are passed to the C test of sls (which calls ssids) on the mac. It seems that the linking is via the fortran (not C) compiler gfortram, and the
-fopenmp flag is used. As I said before, the C tests run fine in both 32 and 64 bit integer

[nimgould]

Specifically, the linking for the C test is via

gfortran-14 -O -g -Wall -Wno-uninitialized -fcheck=all,no-recursion -fbacktrace -fno-var-tracking-assignments -I/Users/nimg/fortran/optrove_git/galahad/modules/mac64.osx.gfo/double_64 -I/Users/nimg/fortran/optrove_git/cutest/modules/mac64.osx.gfo/double_64 -fopenmp -o run_sls /Users/nimg/fortran/optrove_git/galahad/objects/mac64.osx.gfo/double_64/slsct_double_64.o -L/Users/nimg/fortran/optrove_git/galahad/objects/mac64.osx.gfo/double_64 -lgalahad_c -lhsl_c -lgalahad -lhsl -lgalahad_spral -lstdc++ -lhwloc -L/opt/homebrew/Cellar/hwloc/2.11.2/lib -lgalahad_mkl_pardiso -lgalahad_pardiso -lgalahad_wsmp -lmetis64_nodend -lgalahad_pastix -lgalahad_mumps -lgalahad_mpi -lgalahad_umfpack -lgalahad_lapack -lgalahad_blas

[amontoison]

Nick, the link flag for the C++ library should be -lc++ and not -lstdc++ on Mac.

You should also add by default the OpenMP library that you want to link. It's -lgomp with the GNU compilers.

On Mac, with some compilers like clang you need -lomp at the link phase.

-fopenmp should be only used as a compilation option and not a link option.
It only activates the omp macros during the compilation.

[nimgould]

OK, but then why does it work with the options I gave on the Mac? It seems to find the omp linbraries without further prompting; the manual suggests that -fopenmp is used to provide the omp libraries t link time.. Are you using gfortran to do the linking?
-lstdc++ is the correct library to link gfortran and c++

[nimgould]

It also appears that -fopenmp inserts -lgomp when linking

[amontoison]

It also appears that -fopenmp inserts -lgomp when linking

Yes, but not on all platforms. It's why we should specify -lgomp or -lomp or -liomp5 depending on the compiler at link phase.

-lstdc++ is the not the correct option on Mac if you compile with Clang. We should use the default one on this platform, which is -lc++.

[nimgould]

I'm confused, we are talking about gfortran on a Mac, not any platform, and it works for me here.

I have not tested with clang/flang, indeed I am not sure we have that on our system, or whether ssids and flang work together yet. They didn't last year. flang is really sub beta at the moment, it fails on simple things.

I'll try your options when I next fire up our mac, but as I asid, they are not needed for this specific case

[amontoison]

This discussion could help to understand the issue:
JuliaPackaging/Yggdrasil#8869 (comment)

Off-topic: I'm watching the "Crunch" right now (France - England in rugby 🏉 ).
The match is at Twickenham 🍿

[nimgould]

I can confirm that changing from -lsdtc++ to -lc++ does NOT work -

Undefined symbols for architecture arm64:
"std::__throw_length_error(char const*)", referenced from:
void std::vector<hwloc_obj*, std::allocator<hwloc_obj*>>::_M_realloc_append<hwloc_obj*>(hwloc_obj*&&) in libgalahad_spral.a10
_spral_hw_topology_guess in libgalahad_spral.a10
spral::ssids::cpu::SmallLeafSymbolicSubtree::SmallLeafSymbolicSubtree(long long, long long, long long, long long const*, long long const*, long long const*, long long const*, long long const*, long long const*, spral::ssids::cpu::SymbolicSubtree const&) in libgalahad_spral.a13

(etc, etc, etc)

However -lgomp is fine (but as I mentioned, this is invoked by -fopenmp anyway, so no point in changing standard gfortran things)

I am not a rugby fan, but I gather that France came second yesterday. My claim to fame is that I perfomed multiple times on the sacred Twickenham turf; we had the annual south-west London schools athletics competetions there, and I was in the relay team that broke the 4x100 metres under 12s relay recond in 1968! Of coure there was only a crowd of a few hundred parents ...