tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

Am Mon, 21 Jun 2021 20:26:27 +0000
schrieb nia <>: 

> On Mon, Jun 21, 2021 at 08:51:58PM +0200, Dr. Thomas Orgis wrote:
> > The problem I now have is that math/libquadmath is a hard dependency of
> > fftw-long and fftw-quad and it is broken for me on Linux for two reasons
> > 
> > 1. It has PLIST failures as it installs into
> >    ${PREFIX}/lib64 or ${PREFIX/libx32 (wtf?!) for my systems.  
> This should be fixed.

Sure. I am a bit confused to see this as separate package, though. Are
you combining the libquadmath from gcc 11 with any version of gcc in a
base system?

I think, though, that the proper fix could just be adding a
that avoids building it on messy Linux multilib installs which have the
library present anyway. I don't feel good about mixing in any other

> > math/fftw-mpi
> > math/fftw-omp
> > math/fftw-threads
> > math/fftwl-mpi
> > math/fftwl-omp
> > math/fftwl-threads
> > math/fftwq-mpi
> > math/fftwq-omp
> > math/fftwq-threads  

(Please scratch the -threads … that's being built with the respective
main package. So only precision and parallelization as dimensions.)

> Please understand I am trying to reduce friction by following other
> package managers.

The OpenMP and MPI options result in extra library files being built.
And extra dependencies — that's why you don't want them enabled by
default, and hence as separate packages. Speaking of which: The OpenMP
one might miss the libomp dependency for the Darwin toolchain.


Well, I'd like my names better, still, as they more closely match the
library names. But that's bikeshedding.

> > [libquadmath]
> > It was added for NetBSD. So shouldn't the dependency be guarded by a
> > platform check?  
> You're asking that we break the package for users of pkgsrc gcc...

I did not imagine that pkgsrc gcc doesn't ship libquadmath. So the
proper fix would be to depend on it if using pkgsrc gcc and not … if

> I realize you don't care about providing working binary packages
> to end-users, but it's very important for my primary mission of
> making pkgsrc useful for NetBSD users. That means not introducing
> arbitrary build failures.

Sure, it is clear that we have differing focus. I'm also used to
source-based Linux distros that are configured at install=build time.
Ideally, the combination of viewpoints leads to better solutions for
everyone …

Alrighty then,


Dr. Thomas Orgis
HPC @ Universität Hamburg

Home | Main Index | Thread Index | Old Index