[Paraview] Problems compiling 3.2 on IA64 with ICC/ICPC (Resolution)
Mike Jackson
imikejackson at gmail.com
Tue Jun 17 08:23:00 EDT 2008
I dug some more into this and I have a compile working on IA64 using
ICC 9.1.049. The difference seems to be in the XdmfConfig.h.in file.
I switched around some preprocessor so that they were more inline
with vtk:
#if defined( SIZEOF_LONG_LONG )
# define XDMF_64_INT long long
# define HAVE_64_INT
# define XDMF_have_64_bit_int
#elif defined( SIZEOF___INT64 )
# define XDMF_64_INT __int64
# define HAVE_64_INT
#else
# error "64 bit long not defined"
#endif
and now Xdmf seems to compile correctly without have to disable the
64 bit ids. Is this correct? Comments?
I also tested the compile on OS X 10.4.11 (X86) Intel Core Duo with
GCC and that also passed. I have a Linux AMD 64 box that I am going
to also try in the morning with Intel 10.1.x compilers.
--
Mike Jackson Senior Research Engineer
Innovative Management & Technology Services
On Jun 16, 2008, at 6:20 PM, Mike Jackson wrote:
> I did some digging on this and what I have found so far is that the
> file ParaView3/VTK/Common/VTKType.h
> has something that looks like a "hack" to turn off something. Down
> towards the bottom of the file is the following block:
>
> /
> *---------------------------------------------------------------------
> -----*/
> /* Choose an implementation for vtkIdType. */
> #define VTK_HAS_ID_TYPE
> #ifdef VTK_USE_64BIT_IDS
> # if defined(VTK_SIZEOF_LONG) && VTK_SIZEOF_LONG == 8 && 0
> typedef long vtkIdType;
> # define VTK_SIZEOF_ID_TYPE VTK_SIZEOF_LONG
> # define VTK_LARGE_ID VTK_LONG_MAX
> # elif defined(VTK_TYPE_USE_LONG_LONG) && VTK_SIZEOF_LONG_LONG == 8
> typedef long long vtkIdType;
> # define VTK_SIZEOF_ID_TYPE VTK_SIZEOF_LONG_LONG
> # define VTK_LARGE_ID VTK_LONG_LONG_MAX
> # elif defined(VTK_TYPE_USE___INT64) && VTK_SIZEOF___INT64 == 8
> typedef __int64 vtkIdType;
> # define VTK_SIZEOF_ID_TYPE VTK_SIZEOF___INT64
> # define VTK_LARGE_ID VTK___INT64_MAX
> # else
> # error "VTK_USE_64BIT_IDS is ON but no 64-bit integer type is
> available."
> # endif
> #else
> typedef int vtkIdType;
> # define VTK_SIZEOF_ID_TYPE VTK_SIZEOF_INT
> # define VTK_LARGE_ID VTK_INT_MAX
> #endif
>
> The real line of interest is:
> # if defined(VTK_SIZEOF_LONG) && VTK_SIZEOF_LONG == 8 && 0
>
> I guess some one put in the "&& 0" to disable that block
> permanently, this makes the compiler go to the next #elif which
> passes all of its tests and we get vtkIdType == "long long".
>
> This becomes a problem because XdmfInt64 defines to "long". Thus
> the conflicting types and we get the error. I am not sure what the
> correct fix is though. Is this just an Intel Compiler thing? It
> seems that the Xdmf project is figuring out the type for XdmfInt64
> in a slightly different manner than VTK. or the Xdmf project is
> interchanging vtkIdType, int, long and long long without proper
> regard. Don't know.
>
> I am cross posting to the Xdmf list in the hopes someone there
> might be able to help.
>
> --
> Mike Jackson Senior Research Engineer
> Innovative Management & Technology Services
>
>
> On Jun 16, 2008, at 4:21 PM, Randall Hand wrote:
>
>> yes I did, just this morning in fact. By turning off
>> "VTK_USE_64BIT_IDS", it compiled just fine.
>>
>> On Mon, Jun 16, 2008 at 3:19 PM, Mike Jackson
>> <imikejackson at gmail.com> wrote:
>> Did you ever get past this? I hit the same error...
>>
>> --
>> Mike Jackson Senior Research Engineer
>> Innovative Management & Technology Services
>>
>>
>> On Jun 13, 2008, at 1:38 PM, Randall Hand wrote:
>>
>>> aaaarrrgh.. I spoke too soon.. Later in the compile:
>>>
>>> /work1/rhand/Eagle/ParaView3/Utilities/Xdmf2/vtk/vtkXdmfWriter.cxx
>>> (831): error: more than one instance of overloaded function
>>> "XdmfArray::SetValue" matches the argument list:
>>> function "XdmfArray::SetValue(XdmfInt64={long},
>>> XdmfUInt8={unsigned char})"
>>> function "XdmfArray::SetValue(XdmfInt64={long},
>>> XdmfUInt16={unsigned short})"
>>> function "XdmfArray::SetValue(XdmfInt64={long},
>>> XdmfUInt32={unsigned int})"
>>> function "XdmfArray::SetValue(XdmfInt64={long},
>>> XdmfInt8={char})"
>>> function "XdmfArray::SetValue(XdmfInt64={long},
>>> XdmfInt16={short})"
>>> function "XdmfArray::SetValue(XdmfInt64={long},
>>> XdmfInt32={int})"
>>> function "XdmfArray::SetValue(XdmfInt64={long},
>>> XdmfInt64={long})"
>>> function "XdmfArray::SetValue(XdmfInt64={long},
>>> XdmfFloat32={float})"
>>> function "XdmfArray::SetValue(XdmfInt64={long},
>>> XdmfFloat64={double})"
>>> argument types are: (vtkIdType, long long)
>>> object type is: XdmfArray
>>> Data.SetValue(jj, val);
>>> ^
>>> detected during instantiation of "vtkIdType={long long}
>>> vtkXdmfWriterWriteXMLScalar(vtkXdmfWriter *, std::ostream &,
>>> AType *, vtkDataSet *, int *, const char *, const char *, const
>>> char *, const char *, NType, int, int, int *, int) [with
>>> AType=vtkIdTypeArray, NType=long long]"
>>>
>>> /work1/rhand/Eagle/ParaView3/Utilities/Xdmf2/vtk/vtkXdmfWriter.cxx
>>> (842): error: no instance of overloaded function
>>> "XdmfArray::SetValues" matches the argument list
>>> argument types are: (int, vtkIdType *, long long)
>>> object type is: XdmfArray
>>> Data.SetValues(0, array->GetPointer(0), array-
>>> >GetNumberOfTuples() * array->GetNumberOfComponents());
>>> ^
>>> detected during instantiation of "vtkIdType={long long}
>>> vtkXdmfWriterWriteXMLScalar(vtkXdmfWriter *, std::ostream &,
>>> AType *, vtkDataSet *, int *, const char *, const char *, const
>>> char *, const char *, NType, int, int, int *, int) [with
>>> AType=vtkIdTypeArray, NType=long long]"
>>>
>>> compilation aborted for /work1/rhand/Eagle/ParaView3/Utilities/
>>> Xdmf2/vtk/vtkXdmfWriter.cxx (code 2)
>>> gmake[2]: *** [Utilities/Xdmf2/vtk/CMakeFiles/vtkXdmf.dir/
>>> vtkXdmfWriter.o] Error 2
>>> gmake[1]: *** [Utilities/Xdmf2/vtk/CMakeFiles/vtkXdmf.dir/all]
>>> Error 2
>>> gmake: *** [all] Error 2
>>>
>>>
>>> Anything special about 'long long' ?
>>>
>>> On Fri, Jun 13, 2008 at 10:15 AM, Randall Hand
>>> <randall.hand at gmail.com> wrote:
>>> Ok, for anyone watching this thread, I wanted to post an update.
>>>
>>> The first problem (about _SC_GR0_OFFSET) was solved by switching
>>> from the icc 9.1.042 compilers to anything newer, in my case
>>> 9.1.049. This, however, created another problem later in the
>>> compile where the libxml2 headers were all missing.
>>>
>>> After alot of digging & help from the Kitware B-Trio (Bill, Berk,
>>> and Brad), I got past that by recompiling CMake for the ia64
>>> architecture (with icc). It seems the x86 compile doesn't
>>> entirely work on ia64 systems. It works enough to confuse you,
>>> but not enough to actually complete the compile. As of this
>>> writing, I'm 15% through compiling paraview and it's working fine
>>> so far.
>>>
>>>
>>> On Tue, Jun 10, 2008 at 8:53 AM, Berk Geveci
>>> <berk.geveci at kitware.com> wrote:
>>> I wonder if somehow a #define is screwing up symbols... Maybe you
>>> could run the prepocessor and see if its output has anything
>>> unusual?
>>>
>>> -berk
>>>
>>>
>>> On Tue, Jun 10, 2008 at 9:46 AM, Randall Hand
>>> <randall.hand at gmail.com> wrote:
>>> > It's the 3.2.1 ParaView from CVS a while back, with CMake 2.4.8.
>>> >
>>> > On Mon, Jun 9, 2008 at 8:09 PM, Berk Geveci
>>> <berk.geveci at kitware.com> wrote:
>>> >>
>>> >> This happens only with ParaView? Only with cvs ParaView?
>>> >>
>>> >> -ber
>>> >>
>>> >> On Mon, Jun 9, 2008 at 4:04 PM, Randall Hand
>>> <randall.hand at gmail.com>
>>> >> wrote:
>>> >> > Right now, my compiles are failing like so:
>>> >> >
>>> >> > eagle-0:/work1/rhand/Eagle/PV-build/ gmake
>>> >> > [ -3%] Building CXX object
>>> >> > VTK/Utilities/kwsys/CMakeFiles/vtksys.dir/SystemTools.o
>>> >> > /usr/include/sys/ucontext.h(52): error: expected a ")"
>>> >> > unsigned long _pad[_SC_GR0_OFFSET/8];
>>> >> > ^
>>> >> >
>>> >> > compilation aborted for
>>> >> > /work1/rhand/Eagle/ParaView3/VTK/Utilities/kwsys/
>>> SystemTools.cxx (code
>>> >> > 2)
>>> >> > gmake[2]: *** [VTK/Utilities/kwsys/CMakeFiles/vtksys.dir/
>>> SystemTools.o]
>>> >> > Error 2
>>> >> > gmake[1]: *** [VTK/Utilities/kwsys/CMakeFiles/vtksys.dir/
>>> all] Error 2
>>> >> > gmake: *** [all] Error 2
>>> >> >
>>> >> > (yes, i know it shows a Negative progress, no I have no idea
>>> why). I'm
>>> >> > compiling with icc/icpc and linking against Mesa (with the
>>> >> > linux-ia64-icc
>>> >> > config). Any ideas what's going on here?
>>> >> > --
>>> >> > ----------------------------------------
>>> >> > Randall Hand
>>> >> > Visualization Scientist
>>> >> > ERDC MSRC-ITL
>>> >> > _______________________________________________
>>> >> > ParaView mailing list
>>> >> > ParaView at paraview.org
>>> >> > http://www.paraview.org/mailman/listinfo/paraview
>>> >> >
>>> >> >
>>> >
>>> >
>>> >
>>> > --
>>> > ----------------------------------------
>>> > Randall Hand
>>> > Visualization Scientist
>>> > ERDC MSRC-ITL
>>>
>>>
>>>
>>> --
>>> ----------------------------------------
>>> Randall Hand
>>> Visualization Scientist
>>> ERDC MSRC-ITL
>>>
>>>
>>>
>>> --
>>> ----------------------------------------
>>> Randall Hand
>>> Visualization Scientist
>>> ERDC MSRC-ITL
>>
>>
>>
>>
>> --
>> Mike Jackson
>> imikejackson & gmail * com
>>
>>
>>
>>
>> --
>> ----------------------------------------
>> Randall Hand
>> Visualization Scientist
>> ERDC MSRC-ITL
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20080617/5a219a20/attachment-0001.htm>
More information about the ParaView
mailing list