On Thu, Feb 20, 2014 at 2:23 AM, Dmitri Gribenko <[email protected]>wrote:
> 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'.) > > If it is so, I think the change is good, the users can get the previous > behavior by specifying the required libraries manually. > I really disagree, unless I misunderstand the change entirely. 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. 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. 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: - 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. - 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. - 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. - 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. - 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! - No part of this library has gone through an LLVM release process either, not even as a "new" or "beta" project. 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
