Build issue with Mac M1

[hughcars]

Building glvis from source, I'm having an issue with a linker error:

[ 96%] Linking CXX executable glvis
/opt/homebrew/Cellar/cmake/3.29.4/bin/cmake -E cmake_link_script CMakeFiles/glvis-exe.dir/link.txt --verbose=1
/opt/homebrew/opt/llvm/bin/clang++ -O3 -DNDEBUG -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names "CMakeFiles/glvis-exe.dir/glvis.cpp.o" -o glvis   -L/opt/homebrew/Cellar/sdl2/2.30.3/lib  -Wl,-rpath,/opt/homebrew/Cellar/sdl2/2.30.3/lib lib/libglvis.a share/libglvis_logo.a /Users/hughcars/AWS/mfem/build/libmfem.a /Users/hughcars/AWS/hypre/src/hypre/lib/libHYPRE.a /Users/hughcars/AWS/metis-5.1.0/lib/libmetis.a /opt/homebrew/Cellar/open-mpi/5.0.3_1/lib/libmpi.dylib -framework OpenGL /opt/homebrew/Cellar/sdl2/2.30.3/lib/libSDL2.dylib /opt/homebrew/lib/libGLEW.2.2.0.dylib -framework OpenGL /opt/homebrew/lib/libpng.dylib /Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/lib/libz.tbd /opt/homebrew/lib/libfreetype.dylib /opt/homebrew/lib/libfontconfig.dylib -framework Cocoa
Undefined symbols for architecture arm64:
  "std::exception_ptr::__from_native_exception_pointer(void*)", referenced from:
      std::__1::promise<SdlWindow::Handle>::~promise() in libglvis.a[14](sdl_main.cpp.o)
  "___cxa_init_primary_exception", referenced from:
      std::__1::promise<SdlWindow::Handle>::~promise() in libglvis.a[14](sdl_main.cpp.o)
ld: symbol(s) not found for architecture arm64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [glvis] Error 1
make[1]: *** [CMakeFiles/glvis-exe.dir/all] Error 2
make: *** [all] Error 2

This is with a local mfem build that works. Attached is a build log. Having to build from source to have a debug build for ncmesh debugging. Any help appreciated. I think it might be a clash between the OS provided clang and the llvm one furnished by brew.

build.log

[v-dobrev]

We primarily use and test with Apple clang on Mac, so I'd recommend using that.

I have not used Homebrew clang, so I'm not sure how easy it is to get that to work. Looking at the build.log, I don't know what to make of the error -- the missing symbol is from a file (sdl_main.cpp) compiled with the same compiler as the one used for linking. I'd assume that the linker will automatically link with the c++ standard library that it uses when generating code during compilation -- I'm not sure why this is not happening here.

[tzanio]

@hughcars, were you able to resolve this?

[hughcars]

Not yet. I've managed to side step it so far by looking in the crash message for the mfem method that fails, then manually calling that from within mfem. Ultimately this strategy is going to run out of road though so I'll have to figure this out. I have to use the brew clang mostly because of using llvm for other libraries, so I'm not sure I can get away with just using apple clang instead. Based on Veselin's comment, I suspect it might be that somehow it's finding something built with apple clang when it should have brew or vice versa.

[v-dobrev]

You can try building GLVis and MFEM separately from your normal MFEM build -- for this you can use Apple clang. GLVis built this way can work with data sent from any other MFEM build, e.g. a build with a different compiler and with different optional libraries. GLVis does not use anything parallel from MFEM, so you don't loose anything by building serial MFEM for use by GLVis. Also, most optional packages that can be used by MFEM do not add any functionality to GLVis so building without them is perfectly fine. The one exception here, that I can think of, is NetCDF which adds support for reading NetCDF meshes which then allows GLVis to read these meshes too.

[tzanio]

can we close this @hughcars ?

[hughcars]

Changing to using apple clang isn't a particularly practical workflow, as I end up needing 3 builds of mfem locally (one inside of Palace, one for development of mfem patches, and then one for glvis). I have instead opted for reading the apple error backtraces when glvis crashes, and then calling the failing mfem methods directly to debug them, which has been fruitful. The separate builds can be particularly troublesome if I have to edit things within mfem in order to fix the glvis interaction, as that means developing with apple clang becomes necessary rather than llvm which is needed for all my other building.

Given I've unblocked myself can close this given support for llvm clang is not planned.

[v-dobrev]

@hughcars, if you find a solution for the LLVM clang issues on Mac, we can probably add these fixes to GLVis and/or MFEM, if you want.