[cfe-dev] [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path
Peyton, Jonathan L
jonathan.l.peyton at intel.com
Wed May 13 09:29:33 PDT 2015
We understand that iomp is undesirable. What we don’t know is what name is desirable.
What name is desirable instead of iomp? Do we want to link via…
-lnotintelomp ( just kidding ☺ )
… Some other name? I get the feeling someone outside of Intel should make this choice.
From: openmp-dev-bounces at cs.uiuc.edu [mailto:openmp-dev-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth
Sent: Wednesday, May 13, 2015 10:59 AM
To: Jack Howarth; cfe-dev; openmp-dev at dcs-maillist2.engr.illinois.edu
Subject: Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path
I think that openmp should work much more like libc++ than like the sanitizers. It has a reasonably stable API and even supports the libgomp APIs and so it should be in the normal library tree just like libc++.
However, the CMake build of the openmp needs a lot of work. =/ It doesn't match the patterns and structures of any of our other runtime libraries.
I think openmp needs to much more closely model its CMake build on libc++'s before we do anything more. Currently I can't even reasonably include it in my builds because it clobbers un-prefixed variable names and doesn't re-use any of the LLVM CMake logic.
Also, I'll point out that the CMake build completely and universally uses the term 'iomp'. This trend really needs to reverse....
On Wed, May 13, 2015 at 8:32 AM Jack Howarth <howarth.mailing.lists at gmail.com<mailto:howarth.mailing.lists at gmail.com>> wrote:
I believe we have a gap in clang's library search path with the
enabling of the openmp support via the proposed patch at...
Currently, in tree cmake builds of the openmp library using
-DCMAKE_INSTALL_PREFIX to install the llvm build in a buried
subdirectory will place the libiomp5.dylib shared library in a
directory outside of the library search path used by clang...
% clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v
clang version 3.7.0 (trunk)
Thread model: posix
"/sw/opt/llvm-3.7.0/bin/clang-3.7" -cc1 -triple
x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name omp_getEnvInfo.c
-mrelocation-model pic -pic-level 2 -mthread-model posix
-mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 242 -v -dwarf-column-info
/Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140
-fopenmp -stack-protector 1 -mstackrealign -fblocks
-fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
-x c omp_getEnvInfo.c
clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
"/sw/opt/llvm-3.7.0/bin/ld" -demangle -dynamic -arch x86_64
-macosx_version_min 10.10.0 -o omp_getEnvInfo -liomp5
ld: library not found for -liomp5
clang-3.7: error: linker command failed with exit code 1 (use -v to
requiring an explicit path to passed to the compiler...
% clang-3.7 -fopenmp -L/sw/opt/llvm-3.7.0/lib -o omp_getEnvInfo omp_getEnvInfo.c
% otool -L ./omp_getEnvInfo
/sw/opt/llvm-3.7.0/lib/libiomp5.dylib (compatibility version 5.0.0,
current version 5.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
Currently, all the other shared libraries linked by the clang
compilers (aside from libc++) are expected to be located in the
clang/3.7.0/lib/darwin subdirectory (such as
libclang_rt.asan_osx_dynamic.dylib). Using CMAKE_INSTALL_PREFIX in the
cmake build to bury the llvm installation has no impact on the usage
of those two libraries with the -fsanitize flags but the current
search library search path doesn't do the same for the libiomp5
relocation in the same case.
Openmp-dev mailing list
Openmp-dev at dcs-maillist2.engr.illinois.edu<mailto:Openmp-dev at dcs-maillist2.engr.illinois.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev