Clang-omp: Added C++ Support, minor code cleanup #38707
Conversation
| sha256 "ed23f2f98cd280c73f53c31a281a3baee6a7e89cdd2f6f1388502fae6ea043fe" => :yosemite | ||
| sha256 "de14d6887271d0926d0ef4b3eb5f74366955d92d7de231a9ba8c71ce6f8443d1" => :mavericks | ||
| sha256 "7d58ef5113604b044c916dcb1920157d77247eb60e0c508a67d285e139b576e0" => :mountain_lion | ||
| end |
There was a problem hiding this comment.
Please leave the bottle block as it is.
|
|
Whoops. Issues fixed in the latest commit. I'll be more careful in the future. I somehow managed to add a whitespace between my brew audit and the commit =/. And sorry, I misunderstood the bottle procedure. I thought the block was automatically reinserted by the build bot, I understand the correct procedure now. Sorry for the trouble! |
|
Thanks for the pull request! 🎉 Homebrew depends on contributions from community members like you and we're grateful for your support. |
|
@metacollin Many thanks for your contribution! One question though: would it be possible to change the build-time settings of clang-omp in order for the compilers to pick up automatically the Right now I have to include I don't even know if this is possible, but I would be grateful if you could look into it. Intel has by the way released a new version of libiomp: I will create a pull request for that later today. |
|
@tschoonj, is there a specific reason you're installing the header files into a libiomp subfolder? It's a non-issue if we simply link them into /usr/local/include. The presence of this file in normal search paths is benign, it will not cause anything to assume OpenMP support while using system clang or something like that, if that was what you were thinking about. OpenMP is a compiler capability, and even if the flag is found to work, every build system then performs an additional suite of tests to check WHICH OpenMP capabilities work and which don't, which can very depending on the compiler (clang-omp) is still missing a couple pieces of the OpenMP 4.0 spec I believe, or was). Basically, I don't see a reason to make them pick up on the header only when -fopenmp is used, it can just be in the header search path like any other user installed library and if you have #include <omp.h> in your code, it will find it and use it, no additional -I needed. This is how I did things in my tap, and I never ran into any issues. I think we should simply ditch the subfolder for the headers. The official homepage even tells the user to simply add the include file locations to their path (which we can approximate by symlinking them somewhere already in the users path instead). Thoughts? I have this thought at the back of my head that I'm overlooking something huge and thats why you used the subfolder, so if that's the case, let me know and I'll see if I can think of something else :). |
|
@metacollin Well installing those headers into include/libiomp was not my idea, someone else did that before me. By the way: I also wonder if it would be possible to have Maybe |
|
Interesting is that gcc does things differently: it keeps its |
version bump header installation path changed to prefix/include see also discussion in Homebrew#38707
version bump header installation path changed to prefix/include clang-omp's test case needs to be updated too see also discussion in Homebrew#38707
|
@tschoonj Remember, OpenMP is nothing more than a specification. gcc has it's own implementation called gomp, as well as it's own runtime library called libgomp. It's highly gcc verison dependent, and the libgomp run time is not meant to be used in a way independent from the specific verison of gcc it is part of. There were major differences between gcc 4.9's and gcc 4.9.1's gomp/libgomp. They even broke link-time compatibility going from 4.8 to 4.9 and gcc could not link intel's libiomp runtime for 4 months before it was fixed). Basically, we really shouldn't pay attention to what gcc is doing, because how they handle their own implementation is going to have almost nothing to do with how clang handles it. What do you mean 'getting picked up'? I think it just has everything in it's lib directory as part of it's search paths, just in case. And even then, you don't actually have to include omp.h in C or C++ code to use gomp features, only -fopenmp is needed. All omp.h defines is some c functions, but a lot can be done without it using nothing but #pragmas etc. Also, gcc has a long and...ahem...colorful track record of certain compiler feature or optimization flags saying they behave a certain way that may or may not necessarily reflect how they actually behave for that gcc release ;). I would not be surprised if there is a bug report on that somewhere, or if maybe it changed vs. an earlier version, and it's harmless so no one really cares. But I digress. I'm just not gonna worry about gcc, it can do it's own thang. ;) |
|
@tschoonj As for your idea about :clang_omp and needs :openmp, I think that's a great idea. Those are ruby constants and they are defined in the core homebrew ruby files, and I know may way around those pretty well. I'm happy to see about implementing something, though it will need to be well thought out and robust. That's the easy part. The hard part is convincing the powers that be to approve a pull request that adds something to what can be put in Formulae :). Oh, and I've unwillingly become something of an expert on the mess that is libc++, stdlibc++, and the migration that quietly happened from 10.8 to 10.9, due to work on another of my taps, homebrew kicad. Please don't mistake this for condescension or underestimating you, and sorry if this is all stuff you already know (it's very likely it is), but I like to mention it just in case as everyone (Apple, the llvm/clang people so on) has done a pretty crappy job at really mentioning or clearly stating this stuff in favor of a silent and 'seamless' migration (that is not always so seamless, as you found out), so it's not uncommon to find developers in the dark about this. I was, until recently =P. gcc is not binary compatible with OS X, meaning it cannot link or use any system libraries or frameworks, and only binaries also compiled with gcc can link to libraries also compiled by gcc. I believe you may be referring to llvm-gcc, which is a very different beast, it's an llvm front-end based on gcc 4.2.1, and yeah, it's too old to use anything besides stdc++ because it doesn't have cxx11 fully implemented, which is needed to use libc++. The only option if you need to use llvm-gcc (and, really, I don't think anyone needs to these days) is to recompile everything it will link using the -stdlib=libstdc++. If anything requires cxx11, then you cannot use llvm-gcc at all, clang and only clang is your only option. This gets confusing since gcc is an oldschool end to end toolchain, a compiler that makes actual binaries for a target machine. clang cannot produce binaries, only llvm universal machine code, similar to a binary, only it can then be turned into an executable binary for any CPU or architecture that llvm has targets for. It's amazing, it's the future, and it's a totally different and superior way of doing things than the normal compilation of the first decades of personal computers most of us are accustomed to. Doing that makes it impossible to maintain binary compatibility with other compilers, so everything made using llvm needs to only link to other llvm-generated stuff. So clang and llvm-gcc are just frontends that generate language-agnostic llvm machine code, after which llvm actually makes that .dylib or program that runs on your mac, or phone, or whatever. |
If we can use the system |
|
@metacollin Sorry for the delay in my reply. I was on holiday the last couple of days. Many thanks for your clear explanation. My problems with libc++ and libstdc++ occurred when I was writing the Formula for gnudatalanguage (Homebrew/homebrew-science#1905). This package supports OpenMP, which I tried to include as an option, but this required me to compile everything with gcc, installed with Homebrew (not the llvm-gcc that ships with XCode). I tried something similar as explained on stackoverflow and came close to a successful build, but it failed in the end with an Undefined symbol linking error which forced me to abandon my plans :( Now with clang-omp, I will give it another shot. By the way: is there any reason that libiomp is not part of the clang-omp Formulas? Are there any usage-scenarios involving libiomp with other compilers? |
If one attempts to compile any C++ code with clang built using the clang-omp formula, it will not find the header files or standard libraries.
I have made modifications to address this in the same way the llvm formula does if it is built with clang. I also cleaned up the resource installation lines and had the formula install a clang-omp++ symlink in addtion to clang-omp. I know this is redundant, as they both just point to clang, but many developers are used to seeing clang and clang++ for their CC and CXX compilers, so I thought this would give a more familiar work flow.
Thanks!