code compiled and linked with -fopenmp will, at run-time, load the first libgomp it finds in the LD_LIBRARY_PATH (on linux). However, this may not be the correct one, causing run-time failure. This problem manifests itself if, for example, using a more recent version of gcc (4.7.0) than the default OS version (4.3.4), when upon running I get mycmd: /usr/lib64/libgomp.so.1: version `OMP_3.0' not found (required by mylib.so) where mycmd was made using gcc 4.7.0 (at /somepath/gcc/4.7.0/bin/gcc) with option -fopenmp both at compiling and linking. This behaviour is at odds with the documentation, according to which -fopenmp arranges for the automatic linking of the [correct] OpenMP library. Note that I can "fix" the problem by adding the path of the correct library, /somepath/gcc/4.7.0/lib64, to the environment variable LD_LIBRARY_PATH. However, this fiddling with the operating system is not desirable and potentially dangerous, as it may break the operating system itself. Instead, the correct library path should be hard-wired into the executable upon making it, i.e. at linking the -fopenmp option should effectuate to (-Wl) -rpath=/somepath/gcc/4.7.0/lib64. Note also that adding the correct path to the LD_RUN_PATH environment variable at compiling and linking (and running) has not the desired effect.
That is a user error, gcc isn't supposed to handle this for you. If you have multiple versions of libgomp.so on your system, just use -Wl,-rpath,/some/path/ or LD_LIBRARY_PATH to point the program at the right version. Like glibc, libgomp is symbol versioned and backward compatible, keeping the same SONAME, so you really want the latest version of the library from all versions needed by programs that link against it.