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

[nia <nia%NetBSD.org@localhost>]

On Tue, Jun 22, 2021 at 03:27:34PM +0200, Dr. Thomas Orgis wrote:
> Well, an alternative would be to just ship the GCC libraries within
> GCC. But I see that you want to work with the base compiler as much as
> possible and not always replace the whole thing.

Yes, upstream GCC is not always suitable or working.

> As I indicated in IRC, the only option I see is post-install or hacking
> the generated Makefile … or add support to the wrapper to change the output of
> 
> 	$CC -print-multi-os-directory
> 
> to ../lib/. It prints ../lib on Ubuntu, but ../lib64 on CentOS. This is
> appended to --with-toolexeclibdir in configure, which apparently is
> the directory used for libquadmath.la (for whatever reason).

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

> 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.

> You're confusing me. Either having parts of the ABI as options in a
> library package is bad or not. As long as nothing explicitly depends on
> fftw with MPI support or OpenMP (don't confuse these two), you won't
> run into trouble, sure.
> 
> So is the rule ‚options in libraries are bad unless no other package
> needs the option yet‘?

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.