Linker error when using ITK in QT - itk

I am trying to use ITK within QT (New to QT and rusty in ITK) I was finally able to define the include paths and .lib but I am still not able to run my code. It is a simple dicom reader:
typedef signed short InputPixelType;
const unsigned int InputDimension = 2;
typedef itk::Image< InputPixelType, InputDimension > InputImageType;
typedef itk::ImageFileReader< InputImageType > ReaderType;
ReaderType::Pointer reader = ReaderType::New();
reader->SetFileName( "C:\Users\dmilford\Desktop\PvMRIm1" );
typedef itk::GDCMImageIO ImageIOType;
ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
The error comes at the last line and I get the following error
ITKIOGDCM-4.2.lib(itkGDCMImageIO.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall gdcm::Rescaler::SetPixelFormat(class gdcm::PixelFormat const &)" (__imp_?SetPixelFormat#Rescaler#gdcm##QAEXABVPixelFormat#2##Z) referenced in function "public: virtual void __thiscall itk::GDCMImageIO::Read(void *)" (?Read#GDCMImageIO#itk##UAEXPAX#Z)
100 odd times over.
Does anyone know how to solve this linker error or know were I might get a hint to the answer?

This link error probably is from the inconsistent compiled version between ITK and your Qt compiler. Make sure your ITK is built with the MSVC2010, for example, while your Qt SDK default compiler is the same.

Please try using CMake to generate the build files. It takes much less time, and all your issues will go away.

Related

Format specifier for cuDoubleComplex variables for accessing files

In C , we can easily access file using fprintf() and fscanf() as shown below:
fp = fopen(“forces1.txt”, “w”);
for(h=0;h<147;h++)
{
fprintf(fp, “%f %f %f\n”, ForceX[h], ForceY[h], ForceZ[h]);
}
But I am using CUDA and my variables ForceX[h] etc are of type cuDoubleComplex. I want to ask two things:
Whether I am allowed to use frintf and fscanf in CUDA, if not then how to access files.
What will be the format specifier used in place of %f as my variable is not float.
From here:
in cuComplex.h (which is in the CUDA include directory in your CUDA install) we can see the following typedef:
typedef double2 cuDoubleComplex;
and double2 is a struct definition (in vector_types.h, same directory) that looks like this:
struct double2 {
double x,y;
};
So now your question is a C or C++ question. You can print the elements (.x, .y) of that struct easily enough using the %f format specifier.
Yes, you can use fprintf and fscanf in CUDA host code, just like you would in ordinary host code.

Thrust zip_iterator - is typedef essential?

I tried to do this:
thrust::zip_iterator<IteratorTuple> zip;
zip = make_zip_iterator(...)
That failed to compile, but when I did this:
typedef thrust::zip_iterator<IteratorTupe> ZipIterator;
ZipIterator zip = make_zip_iterator(...)
, my code compiled and did exactly what I wanted. My question is, why was the typedef required in this case? And is this usage of typedef specific to this context? I can post the rest of my code if somebody thinks the problem might have been elsewhere.
The reason this:
thrust::zip_iterator<IteratorTuple> zip;
zip = make_zip_iterator(...)
fails is because the thrust::zip_iterator has no default constructor. This is a sensible design choice because an uninitialised fancy iterator has no practical use. The version including the typedef works because the copy constructor is used during instantiation of the fancy iterator. It is not a property of the typedef itself.
[This answer has been assembled from comments and added as a community wiki entry to get this question off the unanswered queue].

#cython.wraparound(False) cast integer CORE GENERATED Error

In cython when my code is compiled with
#cython.wraparound(True)
and I use the following cast function to convert (cast) a float to an integer
cdef DTYPE_t_I float_int(np.float_t val):
return <DTYPE_t_I>val
it runs ok
BUT
when I turn off
#cython.wraparound(False)
the code compiles normally and when it runs it gives the following error
CORE GENERATED
It happens compiling in linux with gcc and windows with MGS
What is wrong? Should it be like this?
Because I am trying to gain speed, I would like to know to switch off these flag.

Flex&Bison: define main function in a separate file

I am trying to make a small interpreter using Flex and Bison.
Now I have two files: parser.l and parser.y. Usually, main function is put in parser.y file. What I want to do is to put the main function in a different file main.cpp which makes my package look neat.
#include "y.tab.h"
int main()
{
yyparse();
return 0;
}
But when I compile, I got an error:
undefined reference to `main'
So I know there is something wrong to include y.tab.h.
Could you someone to tell me how to do it?
Solution
I just figured it out:
add the following to your main.c file:
extern FILE *yyin;
extern FILE *yyout;
extern int yyparse(void);
SO noted:
I just figured it out: add the following to your main.c file:
extern FILE *yyin;
extern FILE *yyout;
extern int yyparse(void);
#Jonathan Leffler Noted
You don't really need yyin or yyout since you don't (yet) reference
them from the file containing main(). However, if you end up doing
work such as reading from files specified on the command line instead
of standard input, you may need them. It would be nice if Bison
generated a header with the appropriate declarations in it. The
y.tab.h file is not, however, the place for that information; it is
used to convey information between the parser and the lexical
analyzer, not between the application and the parser.

cuda surface memory error

My cuda code works fine. but when I include the following on top of my code it gives some errors.
surface<void,2> sImg;
fatal : Parsing error near '.surf': syntax error
How can I solve this?
When I declare "sImg" inside the main method it compiles..
The following doesnt work..
surface<void,2> sImg;
int main()
{
return 0;
}
I changed
Properties-->CUDA Runtime API-->GPU-->GPR Architecture1 to sm_20
Now it compiles..
Are you declaring it inside a .cu file where the kernel using the surface is declared ?
That statements needs to be parsed by the nvcc compiler to become effective.
If that does not work then post the error log of the compiler.