Allow builds that do not dynamically link libopenmc
Created by: smharper
@bforget pointed out that the instructions in our docs are currently insufficient for a clean install. The hanging point is that the linker has a hard time finding libopenmc.so. At first, I thought we could just fix that by copying the library to /usr/local/lib, but it turns out that directory surprisingly isn't covered by ldd by default.
This PR makes it so that by default our executable is built without dynamically linking to libopenmc.so. Unfortunately, this means that every object has to be compiled twice (as far as I can tell, CMake doesn't allow us to use the same object file for multiple targets). But it makes it so that our users don't have to know about LD_LIBRARY_PATH (and I don't have to know about its equivalents on OSX/Windows) in order to get a basic install running.
Another benefit: error messages for things like segfaults are much more helpful when the executable isn't dynamically linked to libopenmc. For example:
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: #0 0x7F8BF721EC07 #1 0x7F8BF721DE00 #2 0x7F8BF566E4AF #3 0x7F8BF85D8F46 #4 0x7F8BF8378B74 #5 0x7F8BF85DAEFF #6 0x7F8BF85ADD82 #7 0x7F8BF607F99E #8 0x7F8BF85ABEB9 #9 0x40110C in MAIN__ at main.F90:30 Floating point exception (core dumped)
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: #0 0x7F2840574C07 #1 0x7F2840573E00 #2 0x7F283E9C44AF #3 0x6DC243 in __surface_header_MOD_z_cylinder_distance at surface_header.F90:614 #4 0x4825C6 in __geometry_MOD_distance_to_boundary at geometry.F90:796 (discriminator 16) #5 0x6DE156 in __tracking_MOD_transport at tracking.F90:128 #6 0x6B1C60 in openmc_run._omp_fn.4 at simulation.F90:96 (discriminator 1) #7 0x7F283F3D599E #8 0x6B01E9 in openmc_run at simulation.F90:88 #9 0x40663C in MAIN__ at main.F90:30 Floating point exception (core dumped)