<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 20, 2014 at 2:23 AM, Dmitri Gribenko <span dir="ltr"><<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":ewk" style="overflow:hidden">  We just used to link in libgomp for compatibility with gcc, is this correct?  (For example, some object files could be compiled with GCC with OpenMP, while the rest of the program could be compiled with clang and linked with 'clang -fopenmp'.)<br>

<br>
  If it is so, I think the change is good, the users can get the previous behavior by specifying the required libraries manually.</div></blockquote></div><br>I really disagree, unless I misunderstand the change entirely.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Today, when users get Clang on Linux, they likely already have libgomp installed much as they have libstdc++ installed. We don't even vaguely document how to build or install libiomp5, much less is that common practice when installing a Clang and LLVM based toolchain. As such, this essentially regresses every user if -fopenmp on Linux.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If you think this is totally fine for Darwin, Dmitri, I can't *really* argue as I don't work on Darwin heavily, but it seems completely crazy to me to require a *completely* undocumented library installation process, with no tests, and no ability to self host with Clang and have full feature support.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Note that we don't have a single build bot set up externally that tests libiomp5 AFAIK. In fact, the situation is much more dire than that:</div><div class="gmail_extra">
<br></div><div class="gmail_extra">- This library is not being developed as an active part of the LLVM community, even if it is checked into SVN as part of the LLVM project and under its license. See r197914 where there is a code drop of many months worth of development with *no* change log, attribution, information, or other participation in any part of the community.</div>
<div class="gmail_extra">- There has been essentially *zero* discussion with the rest of the clang or llvm community about this library. There are separate mailing lists which have nearly no traffic since the code drop.</div>
<div class="gmail_extra">- There has been no effort to make this library even work properly with Clang as a host compiler. See the copious notes that only Clang 3.3 is supported, and that not full featured.</div><div class="gmail_extra">
- The build system is totally disjoint from LLVM's, in fact it is an entirely custom Perl build system that is unlike anything in use by the LLVM project.</div><div class="gmail_extra">- There are *zero tests* in the open source repository!!!! This is even called out in the original submission and on the primary website. We simply *cannot* ship and link against a runtime library which has no tests!</div>
<div class="gmail_extra">- No part of this library has gone through an LLVM release process either, not even as a "new" or "beta" project.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
While I'm very glad that the basic source code for this library was contributed to the LLVM project, it is *not* an active part of the project, it is *not* a reasonable requirement that users install and have as part of their Clang toolchain, and it is *not* a production quality open source piece of software. Thus I cannot support it as being the default library to link in under *any* circumstances, and I absolutely object to it being the default under Linux.</div>
</div>