Re: [vsipl++] fftm compile problem

[Jules Bergmann <jules@xxxxxxxxxxxxxxxx>]

Day, John wrote:
> Jules wrote:
> > > We tried building vsipl++1.3 on Windows using the Cygwin enviroment,
> > > but had many problems.
> > If you don't mind, can you describe the problems?  We've had some
> > success with cygwin, however we would like to make things more robust.
> Turns out that there was only a single problem: the configure failed on
> fftw3l (using the "builtin" parameters that you suggested). Configure
> reported an error on the console, but the logs did not contain any
> specific error that we could identify or troubleshoot. That's when we
> decided to give MingGW a try.
Ok, you can work around that by configuring with --disable-fft-long-double.

> I should also mention that our development platform is a Dell running an
> x64 Dual Core Xeon processor. But we are mostly running in 32-bit
> emulation (using the WOW64 emulation) which seems to be slightly
> unstable, for example we cannot get gdb (MinGW or Cygwin versions) to
> run reliably. So there might be other "x64" side-effects at play here.
Interesting.  As you might know, our company also produces Sourcery G++ 
a productized version of the GNU toolchain.  I'm checking with our G++ 
team to see if we have any solutions for 64-bit windows.

> These CLAPACK files included sys/times.h
> vendor/clapack/SRC/dsecnd.c 
> vendor/clapack/SRC/second.c
Thanks!  Unfotunately we pull in all of lapack, even though we don't use 
all of it, including the timer routines.  I've captured this issue 
internally, we'll correct that in our next release.
>  >> 2. Modified vendor\fftw\kernel\alloc.c to allow compilation of
>  >> our_alloc16()
>
> > Was this to fix a compilation error in that routine, or to force the
> > #ifdef to true?
> We forced with these #defines
> #define WITH_OUR_MALLOC16
> #define MIN_ALIGNMENT  16
> #if defined(WITH_OUR_MALLOC16) && (MIN_ALIGNMENT == 16)
Thanks, we need to look into why FFTW's configure did not detect 
WITH_OUR_MALLOC16.
> > 'lower' is no longer part of the chold object, rather it is in the
> > vsip namespace.  You might try changing parameter to vsip::lower.
> That worked.
Great!


> > Can you try adding the following include
> > 	#include <vsip/map.hpp>
> > and recompiling?
> That worked. 
> Also tried replacing both includes with a single #include
> <vsip/signal.h> and that worked too.
Great, thanks for trying that out.  That is an issue in our library that 
we need to fix.  Including map should not be required if maps are not 
being explicitly used.
> > There is a K-Omega beamformer (also originating from Randy Judd) that
> > was included with the old VSIPL++ reference implementation.  However,
> > I am not sure if it is adaptive.
>  
> We found this presentation with code snippets, 
> http://hpec-si.com/S14-HPEC-SI-VSIPL++.ppt#298,12,VSIPL++ Version
> ...but can't find the entire source code. How might we obtain this code
> or similar VSIPL++ implementations? (We are under Navy contract, so
> might reuse some old government code, if any exists).
Ok, I'll look into where this code might be.

				-- Jules

--
Jules Bergmann
CodeSourcery
jules@xxxxxxxxxxxxxxxx
(650) 331-3385 x705