Hi,

I have a package (cubature) that generates an include file (clencurt.h)
with a small helper program during build. This helper program uses the
"long double" version of libfftw (libfftw3-long3).

Unfortunately, libfftw3-long3 is only available on some architectures
and is missing on armel, armhf, mipsel and some ports. It seems that
these are the architectures where sizeof(long double) == sizeof(long),
which make the a separate "long double" version redundant.

However, the missing "long double" version breaks programs that use the
"long" version of the API. I could in principle rewrite the helper
program to support both; however this requires a lot of renaming and is
not really suitable for a Debian patch.

Therefore, I would ask to provide a "long double" version on all
machines which support the "long double" C data type.

Best regards

Ole

This would require disabling the testsuite on these architectures as
with no real long doubles they will likely fail (which I think is the
original reason the package is not built, but I'd have to look it up).

Imo it is also dangerous to provide a long double numerical library on
platforms that do not really support it. You likely will just get wrong
results.

I think it would be better to just not build cubature on these platforms
depending on how significant the long double support is.
Have you engaged with upstream to check if they want to make long double
support optional?

Hi Julian,

I think this would be a minor problem.

From my C understanding, "long double" is always implementation
dependent and is not guaranteed to be longer than "double". So, with a
"long double" library one gets only the accuracy that is expected for
the number of bits on that platform; this seems obvious to me.

The nominal precision (printed with 18 digits) will be a bit better.
However, when limiting to 15-16 digits (as they are finally converted to
double), almost all numbers are equal (a few deviate in the last digit
by 1). This looks acceptable for me.

Best

Ole