Re: [ReZound-users] rezound not working at all. PERIOD.

[derek h. <de...@x-...>]

Yup, that was it. I manually compiled FFTW 2.1.5, recompiled the 
Rezound-CVS and everything looks good. I'll have to check the Gentoo 
ebuild and see what flags are being passed to FFTW.

thanks for all your help!
derek



Davy Durham wrote:
> Ok this may in fact be a clue..
> 
> As for whether fftw2 or 3... version 3 is a whole new API than version 
> 2.. so I really doubt that distroes will stop including version 2.  
> They're really two separate libraries with the same name.  However I 
> probably should look at reimplementing some things so that version 3 is 
> supported, but it is very low priority since version 2 is still being 
> maintained.  see http://fftw.org
> 
> Now another issue.. fftw can be compiled with it's native datatype being 
> either 32bit floats or 64bit doubles (but not both in the same 
> libfftw.so)  ReZound may be expecting fftw to be using floats and you're 
> lib may be compiled using doubles (or vice-versa).  If they don't match, 
> then a segv is probably likely.
> 
> 
> It probably ought to be an option in rezound to specify how fftw was 
> built.  However in the mean time you should be able to compile fftw 
> yourself and ensure that they're both using the same data type.. I think 
> if you compile fftw with no special configure flags then it builds as 
> double, and likewise rezound expects doubles.
> 
> Your distro's package might come with both float and double versions.. 
> sometimes the package might contain two .so files:  libfftwd.so and 
> libfftws.so (double and single versions)  But a symlink libfftw.so 
> points to one of them (maybe the wrong one) and rezound looks for 
> libfftw.so
> 
> 
> Hopefully this may be it..
> 
> -- Davy
> 
> 
> 
> derek holzer wrote:
> 
>> OK, think I found it:
>>
>>     (gdb) run
>>     Starting program: /usr/local/bin/rezound
>>     warning: Unable to find dynamic linker breakpoint function.
>>     GDB will be unable to debug shared library initializers
>>     and track explicitly loaded dynamic code.
>>     [Thread debugging using libthread_db enabled]
>>     [New Thread 16384 (LWP 1440)]
>>     using path '/usr/local/share/rezound' for share data directory
>>     [New Thread 32769 (LWP 1443)]
>>     [New Thread 16386 (LWP 1444)]
>>     If rezound dies unexpectedly while seeking with the 
>> keyboard,        auto-repeat may be disabled.. if this happens run 
>> 'rezound        --fix-auto-repeat'
>>
>>     Program received signal SIGSEGV, Segmentation fault.
>>     [Switching to Thread 16384 (LWP 1440)]
>>     0xb758a819 in fftw_real2hc_32 () from /usr/lib/libdrfftw.so.2
>>     (gdb) bt
>>     #0  0xb758a819 in fftw_real2hc_32 () from usr/lib/libdrfftw.so.2
>>     (gdb) cont
>>     Continuing.
>>     Cannot find thread 16384: generic error
>>
>>
>> I had FFTW 3.0.1-r1 installed, so I downgraded to FFTW 2.1.5, but I 
>> still get the same segfault. I did make sure to clean out any traces 
>> of the 3.0.1 version, and also recompiled Rezound-CVS against the 
>> 2.1.5 version. Is there a FFTW specific version I should be using?
>>
>> *  sci-libs/fftw
>>       Latest version available: 3.0.1-r1
>>       Latest version installed: 2.1.5-r1
>>       Size of downloaded files: 1,900 kB
>>       Homepage:    http://www.fftw.org/
>>       Description: C subroutine library for computing the Discrete 
>> Fourier Transform (DFT)
>>       License:     GPL-2
>>
>> So I've figured out what the problem is, but I'm still just as 
>> confused as before why it still segfaults. Further suggestions?
>>
>> Also, since FFTW 3 is now the stable version for Gentoo, I expect a 
>> lot more folks out there will have trouble with Rezound.
>>
>> derek
>>
>>
>> Davy Durham wrote:
>>
>>> No, I can't say that anything in that list should cause a problem..
>>>
>>> gdb is breaking on SIG32 events.. but those are not the crash.. do 
>>> 'cont' commands in gdb until you get actually a SEGV signal .. that 
>>> will be your segfault and perhaps reveal more on the backtrace.  Also 
>>> make sure that rezound is being built with -g on the c++ command 
>>> lines so that debug info is compiled in..   If it's not, "make clean" 
>>> and perhaps run  "CXXFLAGS=-g configure ..."
>>
>>
>>
>>
>>
> 
> 


-- 
derek holzer ::: http://www.umatic.nl
---Oblique Strategy # 1:
"(Organic) machinery"