Re: introduce mk/openmp.mk, common choice of pulling in paralle/openmp or not (lots of biology)

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Sun, 1 Jun 2025 21:40:52 +0200
schrieb Edgar Fuß <ef%math.uni-bonn.de@localhost>:

> > .if !empty(PKGSRC_COMPILER:M*clang*)  
> I don’t get why you check for clang where, according to your rationale, you want to check for !gcc.

That is possibly a good point. Two answers:

1. Well, I just copied what was there before.
2. So far I only heard of clang shipping the OpenMP runtime library
   separately.

I learnt years ago that OpenMP is a feature the compiler offers and
that you just need to add -fopenmp and all is well. GCC brings its own
runtime. Intel compilers have their runtime … Pgi compilers … also
clang-based commercial compilers (which most of them seem to become
nowadays) for sure ship with libomp included.

OpenMP runtime shipping with the toolchain is one reason why you might
not want to mix toolchains too much. Speaking of that, I faintly
remember that the Intel compilers supported linking to gcc's libgomp to
stay binary compatible with other software that was built with gcc. I
am not sure how far the option to exchange OpenMP runtimes between
compilers goes.

I really think needing to build the runtime separately is the odd-ball
case. So singling out the odd-ball seems appropriate to me. I might be
wrong, of course. But when I build pkgsrc with Intel One API or AMD's
aocl (which is also clang, IMHO), I for sure do _not_ want
parallel/openmp from pkgsrc, but the runtime shipped with the external
toolchain.


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg