Re: math/fftw-long / math/fftw-quad broken on Linux as it pulls in math/libquadmath, which is superfluous and broken on Linux

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

Am Tue, 22 Jun 2021 14:01:01 +0000
schrieb nia <nia%NetBSD.org@localhost>: 

> I have hacked the generated ./configure.
> Can you check if it works?

CentOS build is happy now.

> > I guess all of these lirbraries that are part of a full toolchain, at
> > least those pulled from the GCC distribution, should get builtin.mk. 
> > 
> > Do you agree with that? Or can I convince you? ;-)
> >   
> 
> I'd rather fix the multilib situation.

Seems like I have some convincing to do. The situation that you
consider fixed is the situation where I have two versions of the same
library in my environment. I consider that undesirable. I accept that
when basesystem openssl is too outdated that I want to replace it, but
otherwise the philosophy of my HPC installs is to have the least
possible confusion in which library comes from where.

When I do not need nor want a libquadmath from pkgsrc, the fix is not
to install a libquadmath from pkgsrc.

Hence … any opposition to me figuring out (or copying) a builtin.mk
that drops it when the host compiler has a libquadmath available? I
imagine that such a builtin.mk is non-trivial when it should avoid any
false positives. But I guess the same logic applies to libgomp
(-fopenmp working to produce a program).

Maybe such properties should be rather settled in boostrap? I consider
this a property of the underlying toolchain that is not subject to change.

> Package options in libraries are bad. But there is also an argument
> to keep things simple. By following other popular packaging systems we
> can avoid headaches in the future from package authors introducing
> these dependencies.

Well, packaging fftw-mpi separately seems sensible, then. Others do
that. The OpenMP case could be included in the main package (of the
respective precision) the same way as the pthreads one: If the system
supports OpenMP, just build it. No option.

The MPI case will need an option/separate package as it is rather
normal not to have an MPI library on a regular system.

Nothing is broken right now by re-shuffling that. I'd rather get it
done. If you were able to pull out -long and -quad, we should just
extract -mpi, -long-mpi. So the full set of packages:

math/fftw (includes fftw3, fftw3f, threads, openmp without option)
math/fftw-mpi (includes MPI for single/double)
math/fftw-long (includes fftw3l, threads, openmp without option)
math/fftw-quad (includes fftw3q, threads, openmp without option)
math/fftw-long-mpi (includes MPI for fftw3l)

Doesn't seem to bad to me. The package that is used as a dependency
right now is math/fftw. The others are special. Each of the specific
package also depends on math/fftw itself.

How did you manage the transition conflict of splitting out fftw-long?
Simple revbump on all? It would be sensible to handle that _before_
having this in a stable release.


Alrighty then,

Thomas

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