<div dir="ltr"><div class="gmail_quote">On Wed, May 13, 2015 at 11:16 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 12:56 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
> I already replied to the code review suggesting to enable it in the<br>
> projects/ tree. I don't understand why a bug report is necessary.<br>
<br>
   I was referencing your objections that build of openmp doesn't<br>
match the patterns and structures of the other runtime libraries (in<br>
case you had any particular changes in mind to address those issues).<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Have those particular issues been discussed in the openmp-dev mailing<br>
list yet?<br></blockquote><div><br></div><div>openmp-commits and llvm-commits.</div><div><br></div><div>Not sure how much more is needed. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> On Wed, May 13, 2015 at 10:55 AM Jack Howarth<br>
> <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, May 13, 2015 at 11:58 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>><br>
>> 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<br>
>> > 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<br>
>> build.<br>
>>              Jack<br>
>><br>
>> ><br>
>> > I think openmp needs to much more closely model its CMake build on<br>
>> > libc++'s<br>
>> > before we do anything more. Currently I can't even reasonably include it<br>
>> > in<br>
>> > my builds because it clobbers un-prefixed variable names and doesn't<br>
>> > re-use<br>
>> > any of the LLVM CMake logic.<br>
>> ><br>
>> > Also, I'll point out that the CMake build completely and universally<br>
>> > 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>
>> >><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>
>> >><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>
>> >><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></div>