Open hughcars opened 1 month ago
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.
@hughcars, were you able to resolve this?
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.
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.
Building glvis from source, I'm having an issue with a linker error:
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