Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

I have trouble building the current Ardour5 as it misses
libfftw3f_threads.so. I am used to the multithreaded fftw being a
separate library (that depends on the normal one). In fact this is
still how things are normally under UNIX. They added the
--with-combined-threads option to help builds on Windows where DLLs
cannot store dependency information (?!):

        http://www.fftw.org/install/windows.html

So … why do we enforce this Windows hack here and deviate from upstream?

config_query_option FFTW_THREADS "Compile FFTW SMP threads library?" n \
                    "--enable-threads --with-combined-threads"         \
                    "--disable-threads --without-combined-threads"    &&

This should be just --enable-threads/--disable-threads. Can someone
remember a good reason? This was introduced right at the beginning by
Jeremy in commit 9054df6f80e … oh, wait, that was a merge … eh git is
of no help there. Anyhow, it originates with the initial addition of
the threads option:

2006-01-29 Robin Cook
        * DETAILS: updated VERSION to 3.1
          converted SOURCEHASH to SOURCE_GPG
          removed BUILD_API
        * CONFIGURE: added to query about thead option
        * BUILD: add query to OPTS


So we got a history of 12 years sporting that non-default installation
now. Users of threaded fftw are not that many. I would like to change
things to the default way how it is on UNIX, so that a program using
the serial fftw API is not linked against libpthread just like that.
That can be programs that do multithreading themselves and the
possibility to screw up with multithreading inside multithreading is
something you want to rule out with a quick glance.

I guess we are rather special in deviating from upstream in that respect:

        https://packages.debian.org/stretch/amd64/libfftw3-single3/filelist

/usr/lib/x86_64-linux-gnu/libfftw3f.so.3
/usr/lib/x86_64-linux-gnu/libfftw3f.so.3.5.5
/usr/lib/x86_64-linux-gnu/libfftw3f_omp.so.3
/usr/lib/x86_64-linux-gnu/libfftw3f_omp.so.3.5.5
/usr/lib/x86_64-linux-gnu/libfftw3f_threads.so.3
/usr/lib/x86_64-linux-gnu/libfftw3f_threads.so.3.5.5

shell$ gaze install fftw | grep libfftw3f

/usr/lib/libfftw3f.a
/usr/lib/libfftw3f.la
/usr/lib/libfftw3f.so
/usr/lib/libfftw3f.so.3
/usr/lib/libfftw3f.so.3.5.7

The change is a good opportunity to identify the spells that actually
need a multithreaded fftw. We'll need to add a sub dependency for that
feature. Or we decide to just always build the multithreading part.
Thoughts on that? We already enforce building of long double, for
example … that will more rarely be needed than multithreading. Oh, and
of course OpenMP should also be added. I think including both
libfftw3?_threads and libfftw3?_openmp should be less controversial
than building the long double version that no piece of standard
software needs (most will use single precision float for audio work).

Each precision variant of the library adds considerable binary weight,
while the _openmp and _threads libs only put a little bit on top:

shell$ du -sk /dev/shm/test/lib/libfftw3*.so.3.5.7
136     /dev/shm/test/lib/libfftw3_omp.so.3.5.7
11100   /dev/shm/test/lib/libfftw3.so.3.5.7
144     /dev/shm/test/lib/libfftw3_threads.so.3.5.7
shell$ du -sk /dev/shm/test/lib/libfftw3*.a
8808    /dev/shm/test/lib/libfftw3.a
180     /dev/shm/test/lib/libfftw3_omp.a
196     /dev/shm/test/lib/libfftw3_threads.a

So, I'd opt for making long double an option instead of the threading,
as long we only are on platforms where both threading (glibc) and
OpenMP (gcc) are a given.


Alrighty then,

Thomas