We need a generic function to check if the currently used gcc has openmp capabilities (is built with USE="openmp") or not. The current breakage: Take a look at imagemagick's ebuild for example, we maintain a semi-ugly hack there. Then take a look at media-libs/opencv where the ebuild simply assumes this is true. The imagemagick hack pretty much breaks with prefix guys if gcc-apple is used... and the hack is about to get extended even futher. The opencv one simply breaks if you build your gcc without openmp. At first I was thinking of grepping something from `gcc -v` but it seems no-avail. Does anyone have any suggestions?
gcc-has-openmp() { return $([[ $($(tc-getCC) -v 2>&1 </dev/null | grep enable-libgomp) ]]) } d'oh? :)
(In reply to comment #1) > gcc-has-openmp() { > return $([[ $($(tc-getCC) -v 2>&1 </dev/null | grep enable-libgomp) ]]) > } > > d'oh? :) > Arfrever suggested following: gcc-has-openmp() { [[ $(gcc -v 2>&1 </dev/null) == *enable-libgomp* ]]; }
i'd go with tc-has-openmp() since this can be used with fortran code, and in case we want to extend it in the future to some other aspects of the toolchain see if this works: tc-has-openmp() { local base="${T}/test-tc-openmp" cat <<-EOF > "${base}.c" #include <omp.h> int main() { int nthreads, tid, ret = 0; #pragma omp parallel private(nthreads, tid) { tid = omp_get_thread_num(); nthreads = omp_get_num_threads(); ret += tid + nthreads; } return ret; } EOF $(tc-getCC "$@") -fopenmp "${base}.c" -o "${base}" >&/dev/null local ret=$? rm -f "${base}"* return ${ret} } personally, i think it is an error to build something with USE=openmp and the host gcc doesnt support it (too old / user disabled it). but i guess we should ewarn in that case rather than die. use openmp && ! tc-has-openmp && ewarn "Your toolchain (gcc) lacks openmp support, disabling openmp support"
Mike, nice! this worked for me. i'm using gcc-4.5.0 with USE="openmp". and that's what I had in mind, ewarn but avoid || die on build failure etc. in case users has switched gcc by accident or something like that... use it as a safe-kludge.
done then: http://sources.gentoo.org/eclass/toolchain-funcs.eclass?r1=1.99&r2=1.100
(In reply to comment #3) > i'd go with tc-has-openmp() since this can be used with fortran code, and in the implemented test is so far C code only. should we bloat it with fortran code as well? > $(tc-getCC "$@") -fopenmp "${base}.c" -o "${base}" >&/dev/null -fopenmp is a gcc specific. is the plan doing it multi-compilers, or should we add a test to check CC is gcc? see [1] for other flags. also not so sure it is the role of an eclass to do autoconf macros like. [1] http://git.savannah.gnu.org/cgit/autoconf-archive.git/tree/m4/ax_openmp.m4
i dont think it matters as i dont believe it is possible to emerge gcc with openmp support in the C frontend but not the fortran frontend. so use the tc-has-openmp function in fortran packages.
assuming toolchain-funcs is only for gcc suite, and no mixing of family compilers, i agree. now take the situation gcc-config set to a gcc < 4.2 and a user sets FC=ifort while installing a package. this test would fail while openmp was actually supported by ifort.
is that a realistic case ? i'm not inclined to extend toolchain-funcs.eclass to support every random toolchain out there considering the consumers of them are so minuscule. also, not everyone uses autotools. so if you have an autotooled package, then yes, you should be bugging the upstream package to fix things on their side.
yes it can be realistic, although i don't foresee another use than in science packages. many people in science do not use gfortran because it does not compile some legacy fortran 77 codes. my point with the link to the ax_openmp macro was to show something we could get inspiration from and translate the m4 to the eclass.
why not adding a simple test such as if [[ $(tc-getCC) != *gcc* ]] && [[ $(tc-getFC) != *gfortran* ]]; then # not a gcc based toolchain, let the user on his own return fi before anything else in the tc-has-openmp function?
