[Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

[Jack Howarth]

On Wed, May 13, 2015 at 12:56 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 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?

>
> On Wed, May 13, 2015 at 10:55 AM Jack Howarth
> <howarth.mailing.lists at gmail.com> wrote:
>>
>> On Wed, May 13, 2015 at 11:58 AM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>> > 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 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> 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...
>> >>
>> >>
>> >>
>> >> 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
>> >> _______________________________________________
>> >> Openmp-dev mailing list
>> >> Openmp-dev at dcs-maillist2.engr.illinois.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev