<div dir="ltr">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.<br></div><br><div class="gmail_quote">On Wed, May 13, 2015 at 10:55 AM Jack Howarth <<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, May 13, 2015 at 11:58 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
> I think that openmp should work much more like libc++ than like the<br>
> sanitizers. It has a reasonably stable API and even supports the libgomp<br>
> APIs and so it should be in the normal library tree just like libc++.<br>
><br>
<br>
Chandler,<br>
       Is linux able to find the installed libc++ shared library when<br>
-DCMAKE_INSTALL_PREFIX=<br>
is used in the cmake build? On x86_64 darwin, the built libc++ shared<br>
library is installed<br>
in the lib subdirectory of the path from CMAKE_INSTALL_PREFIX.<br>
However, this isn't really<br>
exercised on darwin as the system libc++ is always used by default.<br>
<br>
> However, the CMake build of the openmp needs a lot of work. =/ It doesn't<br>
> match the patterns and structures of any of our other runtime libraries.<br>
<br>
Please do open bugzilla reports on those issues against the openmp cmake build.<br>
             Jack<br>
<br>
><br>
> I think openmp needs to much more closely model its CMake build on libc++'s<br>
> before we do anything more. Currently I can't even reasonably include it in<br>
> my builds because it clobbers un-prefixed variable names and doesn't re-use<br>
> any of the LLVM CMake logic.<br>
><br>
> Also, I'll point out that the CMake build completely and universally uses<br>
> the term 'iomp'. This trend really needs to reverse....<br>
><br>
> On Wed, May 13, 2015 at 8:32 AM Jack Howarth<br>
> <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>><br>
>>     I believe we have a gap in clang's library search path with the<br>
>> enabling of the openmp support via the proposed patch at...<br>
>><br>
>><br>
>> <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html</a><br>
>><br>
>> Currently, in tree cmake builds of the openmp library using<br>
>> -DCMAKE_INSTALL_PREFIX to install the llvm build in a buried<br>
>> subdirectory will place the libiomp5.dylib shared library in a<br>
>> directory outside of the library search path used by clang...<br>
>><br>
>> % clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v<br>
>> clang version 3.7.0 (trunk)<br>
>> Target: x86_64-apple-darwin14.4.0<br>
>> Thread model: posix<br>
>>  "/sw/opt/llvm-3.7.0/bin/clang-3.7" -cc1 -triple<br>
>> x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free<br>
>> -disable-llvm-verifier -main-file-name omp_getEnvInfo.c<br>
>> -mrelocation-model pic -pic-level 2 -mthread-model posix<br>
>> -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2<br>
>> -target-linker-version 242 -v -dwarf-column-info<br>
>> -fno-unique-section-names -resource-dir<br>
>> /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0 -fdebug-compilation-dir<br>
>> /Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140<br>
>> -fopenmp -stack-protector 1 -mstackrealign -fblocks<br>
>> -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature<br>
>> -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o<br>
>> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o<br>
>> -x c omp_getEnvInfo.c<br>
>> clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target<br>
>> x86_64-apple-darwin14.4.0<br>
>> ignoring nonexistent directory "/usr/local/include"<br>
>> #include "..." search starts here:<br>
>> #include <...> search starts here:<br>
>>  /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0/include<br>
>>  /usr/include<br>
>>  /System/Library/Frameworks (framework directory)<br>
>>  /Library/Frameworks (framework directory)<br>
>> End of search list.<br>
>>  "/sw/opt/llvm-3.7.0/bin/ld" -demangle -dynamic -arch x86_64<br>
>> -macosx_version_min 10.10.0 -o omp_getEnvInfo -liomp5<br>
>> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o<br>
>> -lSystem<br>
>> ld: library not found for -liomp5<br>
>> clang-3.7: error: linker command failed with exit code 1 (use -v to<br>
>> see invocation)<br>
>><br>
>> requiring an explicit path to passed to the compiler...<br>
>><br>
>> % clang-3.7 -fopenmp -L/sw/opt/llvm-3.7.0/lib -o omp_getEnvInfo<br>
>> omp_getEnvInfo.c<br>
>> % otool -L ./omp_getEnvInfo<br>
>> ./omp_getEnvInfo:<br>
>> /sw/opt/llvm-3.7.0/lib/libiomp5.dylib (compatibility version 5.0.0,<br>
>> current version 5.0.0)<br>
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current<br>
>> version 1213.0.0)<br>
>><br>
>> Currently, all the other shared libraries linked by the clang<br>
>> compilers (aside from libc++) are expected to be located in the<br>
>> clang/3.7.0/lib/darwin subdirectory (such as<br>
>> libclang_rt.asan_iossim_dynamic.dylib and<br>
>> libclang_rt.asan_osx_dynamic.dylib). Using CMAKE_INSTALL_PREFIX in the<br>
>> cmake build to bury the llvm installation has no impact on the usage<br>
>> of those two libraries with the -fsanitize flags but the current<br>
>> search library search path doesn't do the same for the libiomp5<br>
>> relocation in the same case.<br>
>>             Jack<br>
>> _______________________________________________<br>
>> Openmp-dev mailing list<br>
>> <a href="mailto:Openmp-dev@dcs-maillist2.engr.illinois.edu" target="_blank">Openmp-dev@dcs-maillist2.engr.illinois.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev</a><br>
</blockquote></div>