http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57123
Bug #: 57123
Summary: code compiled and linked with -fopenmp does not load
the correct omp library at run-time
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w...@leicester.ac.uk
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.
