Gooberpatrol66
commented
6 years ago The manual suggests that function doesn't work when openmp is enabled: http://fftw.org/doc/Thread-safety.html#Thread-safety But I can't get it to work regardless.
Closed dvzrv closed 4 years ago
Gooberpatrol66
commented
6 years ago The manual suggests that function doesn't work when openmp is enabled: http://fftw.org/doc/Thread-safety.html#Thread-safety But I can't get it to work regardless.
Gooberpatrol66
commented
6 years ago It appears to compile if you edit MtxConv.cpp and replace fftw_make_planner_thread_safe(); with void fftw_make_planner_thread_safe(void); I don't know if that breaks anything though.
thibaudk
commented
6 years ago I had the exact same problem on Ubuntu 18.04 and @Gooberpatrol66 's edit fixed it. Cheers! So far nothing else seems to be broken. Will keep on testing
dvzrv
commented
6 years ago @kronihias I'm a little puzzled as to why you just closed this. Is it a viable option to patch your source code before building a distribution package? A little feedback about the suggested solution would have been great instead of just silently closing, as this is obviously a bug. How am I supposed to know if the suggested fix doesn't break functionality? If it is a viable fix, please include it in a new release of the software!
kronihias
commented
6 years ago hi @dvzrv, I kind of missed there is a hack in the comments, sorry. however, the solution is get the latest fftw with fftw_make_planner_thread_safe, therefore it's not a bug in the code, it's simply an outdated library you are trying to use. (needs > fftw-3.3.6-pl2)
thibaudk
commented
6 years ago Hi @kronihias
I got this error using fftw-3.3.7-1 on Ubuntu 18.04.
@Gooberpatrol66 edit did fix it for me. I am now able to youse seemingly all ambix pluggins up to order 3 (higher order builds won't oppen in Ardour)
dvzrv
commented
6 years ago @kronihias I have now tried building against fftw 3.3.8 with the same result.
doing a grep -R "make_planner_thread_safe" /usr/include gives me:
/usr/include/fftw3.f03: subroutine fftw_make_planner_thread_safe() bind(C, name='fftw_make_planner_thread_safe')
/usr/include/fftw3.f03: end subroutine fftw_make_planner_thread_safe
/usr/include/fftw3.f03: subroutine fftwf_make_planner_thread_safe() bind(C, name='fftwf_make_planner_thread_safe')
/usr/include/fftw3.f03: end subroutine fftwf_make_planner_thread_safe
/usr/include/fftw3.h:FFTW_CDECL X(make_planner_thread_safe)(void); \
/usr/include/fftw3l.f03: subroutine fftwl_make_planner_thread_safe() bind(C, name='fftwl_make_planner_thread_safe')
/usr/include/fftw3l.f03: end subroutine fftwl_make_planner_thread_safe
/usr/include/fftw3q.f03: subroutine fftwq_make_planner_thread_safe() bind(C, name='fftwq_make_planner_thread_safe')
/usr/include/fftw3q.f03: end subroutine fftwq_make_planner_thread_safeI'm unsure where this goes wrong, but as mentioned before I have also tried different builds of fftw to track this down and the ambix build still fails.
kronihias
commented
6 years ago hi @dvzrv, @thibaudk, and @Gooberpatrol66 of course this breaks the code. the function make_planner_thread_safe is not being called after this codechange. i am using a thread to load new presets to speedup the startup on project load. (very helpful if several binaural plugins or mcfx_convolvers are used in one daw project) but fftw is not threadsafe if this function is not called, and crashes are almost certain. therefore the fix might work for you, but I can't include it upstream. you guys have to figure out whats wrong with fftw on linux. i don't use linux much nowadays, therefore I can't take care of that. i am waiting for a solution that does not break the code for other platforms/usecases. thanks for your help, matthias
dvzrv
commented
6 years ago @kronihias it seems fftwf_make_planner_thread_safe is a rather brute force method to deal with multi-threaded situations (http://www.fftw.org/fftw3_doc/Thread-safety.html) and will break OpenMP.
In any case: The example also explicitely calls it as void fftw_make_planner_thread_safe(void);.
Why do you do it differently in your code?
claudeha
commented
5 years ago The link failure
[ 13%] Linking CXX executable ../../_bin/standalone/ambix_binaural_standalone_o5
CMakeFiles/ambix_binaural_standalone_o5.dir/__/Source/MtxConv.cpp.o: In function `MtxConvMaster::MtxConvMaster()':
MtxConv.cpp:(.text+0x620): undefined reference to `fftwf_make_planner_thread_safe'
collect2: error: ld returned 1 exit statuscan be fixed properly by linking with -lfftw3f_threads as well as -lfftw3f (tested on Debian Buster with fftw3-3 version 3.3.8 from unstable (iirc)). I don't know how to do this properly in cmake, I just ran make VERBOSE=1 and edited the failing command line and re-executed it.
chris-kuhr
commented
4 years ago I have installed fttw3 3.3.8 and manually linked both variants against fttw3 and fttw3_threads.
But I still cannot compile ambix_binaural:
CMakeFiles/ambix_binaural_standalone_o5.dir/__/Source/MtxConv.cpp.o: In function `MtxConvMaster::MtxConvMaster()':
MtxConv.cpp:(.text+0x63f): undefined reference to `fftwf_make_planner_thread_safe'
CMakeFiles/ambix_binaural_standalone_o5.dir/__/Source/PluginProcessor.cpp.o: In function `Ambix_binauralAudioProcessor::LoadConfiguration(juce::File)':
PluginProcessor.cpp:(.text+0x6426): undefined reference to `Convproc::configure(unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, float)'
PluginProcessor.cpp:(.text+0x6483): undefined reference to `Convproc::impdata_create(unsigned int, unsigned int, int, float*, int, int)'
collect2: error: ld returned 1 exit status
ambix_binaural/ambix_binaural_standalone/CMakeFiles/ambix_binaural_standalone_o5.dir/build.make:319: recipe for target '_bin/standalone/ambix_binaural_standalone_o5' failed
make[2]: *** [_bin/standalone/ambix_binaural_standalone_o5] Error 1
CMakeFiles/Makefile2:216: recipe for target 'ambix_binaural/ambix_binaural_standalone/CMakeFiles/ambix_binaural_standalone_o5.dir/all' failed
make[1]: *** [ambix_binaural/ambix_binaural_standalone/CMakeFiles/ambix_binaural_standalone_o5.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....Any suggestions?
Thanks, Ck
umlaeute
commented
4 years ago you have to link against both libraries: -lfftw3f -lfftw3f_threads (instead of just -lfftw3f which is the autodetected value).
at least on Debian/buster...
kronihias
commented
4 years ago should be fixed with commit 9b9c8d3d4aba43985ec1936ffcce55eb8d058888 also need zita-convolver 4.0 if building with zita_convolver (which is optional)
chris-kuhr
commented
4 years ago It does not link with libfftw 3.3.8.
MtxConv.cpp.o: in func. MtxConvMaster::MtxConvMaster(): undefined reference to fftwf_make_planner_thread_safe
Do I need a newer version?
kronihias
commented
4 years ago the before mentioned commit makes sure the fftw threads library is getting linked as well. i have tested this in ubuntu and debian and it works, don't know about arch linux...
chris-kuhr
commented
4 years ago I am on Linux Mint 18 Sarah, which is Ubuntu 16.04.
dvzrv
commented
4 years ago I've just rebuilt this and it works for me now. Thanks for the fixes @kronihias!
I'm currently trying to create a package for Arch Linux, to eventually move ambix to the [community] repository. However, I have troubles building it with: alsa-lib: 1.1.5-1 eigen: 3.3.4-1 fftw: 3.3.7-1 freetype2: 2.9-2 glu: 9.0.0-4 jack: 0.125.0-3 libsoxr: 0.1.3-1 libxinerama: 1.1.3-2 libxcursor: 1.1.15-1 libxrandr: 1.5.1-2 zita-convolver: 3.1.0-6
It seems as if fftw is not detected properly, or the fftw package in Arch is missing something. For the latter reason I have build fftw from source to make sure (correlating with how Debian currently builds it), that everything is in its right place. Apart from not building static libs and not building for that many architectures, it should be the same though!
In any case, the build reproducibly fails, as can be seen in the below log:
Any help would be greatly appreciated.