CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

I believe we have a gap in clang's library search path with the
enabling of the openmp support via the proposed patch at...

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html

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)
Target: x86_64-apple-darwin14.4.0
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
-fno-unique-section-names -resource-dir
/sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0 -fdebug-compilation-dir
/Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140
-fopenmp -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
-fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
-x c omp_getEnvInfo.c
clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target
x86_64-apple-darwin14.4.0
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
/sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0/include
/usr/include
/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
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
-lSystem
ld: library not found for -liomp5
clang-3.7: error: linker command failed with exit code 1 (use -v to
see invocation)

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
./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
version 1213.0.0)

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_iossim_dynamic.dylib and
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.
            Jack

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…

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…

-lllvmomp

-llvmomp

-lclomp

-lcomp

-lnotintelomp ( just kidding J )

… Some other name? I get the feeling someone outside of Intel should make this choice.

– Johnny

[Joining in the bikeshed]
-llomp seems most consistent (first letter of LLVM + omp, consistent with first letter of GNU + omp, first letter of Intel + omp).

David

My suggestion had been ‘libllomp’ which would be ‘-lllomp’. But I don’t really care.

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++.

Chandler,
       Is linux able to find the installed libc++ shared library when
-DCMAKE_INSTALL_PREFIX=
is used in the cmake build? On x86_64 darwin, the built libc++ shared
library is installed
in the lib subdirectory of the path from CMAKE_INSTALL_PREFIX.
However, this isn't really
exercised on darwin as the system libc++ is always used by default.

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.

Please do open bugzilla reports on those issues against the openmp cmake build.
             Jack

I already replied to the code review suggesting to enable it in the projects/ tree. I don’t understand why a bug report is necessary.

I already replied to the code review suggesting to enable it in the
projects/ tree. I don't understand why a bug report is necessary.

   I was referencing your objections that build of openmp doesn't
match the patterns and structures of the other runtime libraries (in
case you had any particular changes in mind to address those issues).
Have those particular issues been discussed in the openmp-dev mailing
list yet?

I already replied to the code review suggesting to enable it in the
projects/ tree. I don’t understand why a bug report is necessary.

I was referencing your objections that build of openmp doesn’t
match the patterns and structures of the other runtime libraries (in
case you had any particular changes in mind to address those issues).

Yes.

Have those particular issues been discussed in the openmp-dev mailing
list yet?

openmp-commits and llvm-commits.

Not sure how much more is needed.

> I already replied to the code review suggesting to enable it in the
> projects/ tree. I don't understand why a bug report is necessary.

   I was referencing your objections that build of openmp doesn't
match the patterns and structures of the other runtime libraries (in
case you had any particular changes in mind to address those issues).

Yes.

Have those particular issues been discussed in the openmp-dev mailing
list yet?

openmp-commits and llvm-commits.

When I pinged the same proposed change from
http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-May/000255.html
in the openmp-dev mailing list...

http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-May/000522.html

Jonathan seemed to think that the change was non-essential...

http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-May/000525.html

Hi

I vote for -lllomp, i.e. lib name libllomp.a.

There is already a (perhaps unofficially named) LOMP library around (which can be used as openmp runtime for clang) and this would make some discussion hard to understand. See references to it here:

http://cscads.rice.edu/workshops/summer-2012/slides/performance-tools/OpenMP-for-exascale-CScADS.pdf
https://www.alcf.anl.gov/files/BlueGeneQ_Optimization.pdf

Cheers

– Carlo

How about naming the library “lvmomp”. Then you can use –llvmomp to link (cf. libiberty J)

Cheers,

-michael

Dr.-Ing. Michael Klemm

Senior Application Engineer

Software and Services Group

Developer Relations Division

Phone +49 89 9914 2340

Cell +49 174 2417583

Why not -lomp?

-Chris

Adding a prefix may be desireable to avoid conflicts or confusion.

Hi Chris

I sent an e-mail a while ago but I made a mistake when transforming it from daily digest into a single e-mail and you may not have seen it.

lomp is already used for the “lightweight OpenMP” (LOMP) implementation, which is for PPC64, BlueGene, and Z-series systems.
Here are some references to it:

http://cscads.rice.edu/workshops/summer-2012/slides/performance-tools/OpenMP-for-exascale-CScADS.pdf
https://www.alcf.anl.gov/files/BlueGeneQ_Optimization.pdf

One important note is that LOMP supports the KMP* interface and can be (and currently is) used as a OpenMP library for LLVM.
Unless you feel strongly for re-using the name, I would rather prefer LLOMP to avoid confusion.

Thanks

– Carlo

Inactive hide details for Chris Lattner ---05/15/2015 06:37:07 PM---> On May 13, 2015, at 9:29 AM, Peyton, Jonathan L <jonathanChris Lattner —05/15/2015 06:37:07 PM—> On May 13, 2015, at 9:29 AM, Peyton, Jonathan L jonathan.l.peyton@intel.com wrote: >

Adding a prefix may be desireable to avoid conflicts or confusion.

Sure, OTOH, we have precedent with this. There were many c++ standard libraries before libc++. I'm ok with LLVM's implementation being the defacto implementation, aren't you?

-Chris

Sure, but “lomp” is presumably actually linked with the command line flag -llomp today. The “-l” part is an aspect of the compiler interface to specify a library to link, not part of the name of the library.

-Chris

maybe we're talking about the same thing

Let me be very clear here. I am suggesting that this library be named "libomp.so" and thus be linked with "-lomp" (if named explicitly).

I'm not suggesting that we add magic behavior to the -l flag.

-Chris

yeah and I'm saying that name has a high chance to collide with
something else. In fact others have already posted to this fact. The
smart thing to do would be
a) leave it alone
b) name it libllvmopenmp or whatever else