[vsipl++] fftm compile problem

[Jules Bergmann]

Day, John wrote:
 > Jules,

 > 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.

 > However (surprisingly) we were successful in
 > building using standalone MinGW with Msys and gcc/g++/g77 3.4.5,

Great!

 > with only two minor glitches:

 > 1. MinGW didn't have sys/times.h, so we created one with just a tms
 > structure which satisfied the make.

OK.  Do you know where this was being included from?  We try to pull
in <time.h>, but only if you've enabled one of the posix timers
(--enable-timer=posix or --enable-timer=realtime).

 > 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?

 >
 > The two build examples, fft.exe and example1.exe were linked and ran 
OK, which suggests that our compiler switches and linkage issues were 
resolved OK.
 >
 > But we are still having a problem compiling the Judd/Cottel 
BeamformEx code 
(http://hpec-si.com/MinimumVarianceBeamformerExample.pdf) in files 
BeamformEx.cpp and beam_steer_coeff.cpp
 > [See listing compile/link commands and errors at end of this message]
 >
 > BeamformEx.cpp: pg 7
 > // Create a cholesky object
 >  vsip::chold<vsip::cscalar_f, vsip::by_reference>
 >           chold_object(vsip::chold<vsip::cscalar_f, 
vsip::by_reference>::lower,nh);
 > I was able to get this to compile by changing the first parameter of 
the constructor to (vsip::mat_uplo)0, since it seems to be looking for 
an enumeration of zero.

'lower' is no longer part of the chold object, rather it is in the
vsip namespace.  You might try changing parameter to vsip::lower.

 >
 > beam_steer_coeff.cpp: pg37
 > k *= (2.0 * M_PI/sv);
 > This statement causes the error, possibly due to incorrect
 > overloading of *= operator.
 >
 > I can get all of the beamformer files to compile and link if I
 > comment out this last statement.  Is this still a config problem, or
 > is this code possibly out of date? A comment on page 43 suggests
 > that this is using a very early implementation of VSIPL++.

That statement should work.  From the error message below, the library
may be failing to include a header file.

Can you try adding the following include

	#include <vsip/map.hpp>

and recompiling?

 >  We are trying to get this beamformer working to do signal
 >  processing on some towed-array sonar data. Are there any other
 >  adaptive beamformers available similar to this in the VSIPL++
 >  community, either commercially or as free software?

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.
 >
 > Thanks for your help and suggestions,
 > John Day

No problem!  Thanks for your feedback on VSIPL++.

				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705