I’m not a cmake expert, but I didn’t see any support anywhere in the LLVM OpenMP directories for creating a static library to be used by statically-linked executables. I want this for use on Cray platforms, where statically-linked binaries are preferred.
Are there cmake build options that can be used with the current build system to create a statically-linked library? If not, is there a cmake expert on this list willing to add such support so that static libraries are either created by default or can be added by setting a cmake variable?
John, take this with a grain of salt (because I haven’t tried it). In each of the respective source directories, grep the “CMakeLists.txt” build script. Look for “add_library” and change the second argument from SHARED to STATIC.
Stand by and I’ll try this in our tree…..
John D. Leidel
I’m going to just share Jim Cownie’s standard disclaimer here Just as a reminder to proceed with caution.
“Compiling a static OpenMP library is, in general, a very bad idea.
It can easily lead to both awful performance (due to over-subscription) and incorrect program execution when you use any libraries which also use OpenMP.
Imagine that your static instance of the OpenMP runtime starts one thread/core. Now you call into some other library which has its own statically linked OpenMP runtime. That runtime knows nothing about the threads you have already created, so it creates a whole new set. Now you have double over-subscription. Ouch.
Or, suppose you execute an omp atomic statement in a case where it is implemented using a static lock inside the runtime. If you have two runtimes, you have two different locks, and its possible for atomicity not to be enforced between code that uses the two different OpenMP runtimes.
For correctness and performance you need to ensure that there’s only one OpenMP runtime in a process. As soon as you create a static OpenMP runtime you make it very easy for that not to be the case.
So, I’m sure it’s possible (heck, “It’s only software”), but it’s not made easy because doing it is a really bad idea.
Thanks for passing along Jim's advice. I agree with Jim’s reasons why shared libraries are often the best choice. However, for creating statically-linked executables, they are not a choice.