petscvec.h:#define VecType char*

Becuase petsc does #define [and not typedef] - the namespace doesn't
protect the multiple usage of VecType.

One way to track whats hapenning with compile is to get the preprocessed
code [and see the order in which includes are used - and how these #defines
get expanded].

make CFLAGS=-E source.o

[and the output file source.o will actually be preprocessed c code -
that can be checked with emacs]

Satish


On Wed, 27 Oct 2010, Barry Smith wrote:

> 
>   Sending this to petsc-dev for better brains then mine to look at.
> 
>    Barry
> 
> 
> Begin forwarded message:
> 
> > From: Victor Minden <victorminden at gmail.com>
> > Date: October 27, 2010 3:30:29 PM CDT
> > To: Barry Smith <bsmith at mcs.anl.gov>
> > Subject: Re: SACUDA - Cannot compile
> > 
> > Quick append: I realized that it would make the most sense to see if it 
> > compiles at all with just smoothed_aggregation.h included, and it does.  
> > This caused me to look further and see that the first line that kills the 
> > compiler and the next few ones I looked at were trying to define and then 
> > use a struct (inside many nested namespaces) called VecType, which rang a 
> > bell--since vectype is a flag for petsc, I assume we have a 
> > variable/struct/something somewhere that is causing the compiler to not let 
> > us use it again--though it should be valid since it's in a namespace.  Is 
> > this mangling/namespace collision/something of the sort?  What's the best 
> > way around it?
> > 
> > 
> > ---
> > Victor L. Minden
> > 
> > Tufts University
> > School of Engineering
> > Class of 2012
> > 
> > 
> > On Wed, Oct 27, 2010 at 4:21 PM, Victor Minden <victorminden at gmail.com> 
> > wrote:
> > I'm having trouble compiling with the new experimental versions of thrust 
> > and cusp, but only the sacuda preconditioner is affected.  I pulled them 
> > out of their respective hg repositories and edited the version numbers so 
> > petsc would take them, and all the aijcuda and veccuda stuff seems to 
> > compile fine.  However, when the compile gets to sacuda.cu, I get a whole 
> > bunch of
> > 
> > /usr/local/cuda/bin/../include/thrust/detail/device/cuda/detail/b40c/vector_types.h(37):
> >  error: expected an identifier
> > 
> > and similar errors in two different files (make.log attached).
> > 
> > I pulled everything out of sacuda.cu except for the include statements (end 
> > of email[1]), but it still says the same thing.  Looking around online, I 
> > guess this could be a C/C++ problem, maybe needing some extern magic or 
> > something?  The internet is not being very helpful.  
> > 
> > The files that are affecting things were both added to Thrust *after* the 
> > last time we've looked at sacuda, vector_types.h [2] and 
> > radixsort_scanscatter_kernel.h [3].  These appear to be both part of a 
> > bundled radixsort code from an external source.  The files are protected at 
> > the top by a #pragma once, but I think we're ignoring pragmas (? or at 
> > least we have the flag -Wnounknownpragmas) so I tried popping in an if 
> > !defined and such to no avail.
> > 
> > Does anything come to mind as a likely source of this problem?
> > 
> > -Victor
> > 
> > 
> > 
> > 
> > [1]
> > #define PETSCKSP_DLL
> > 
> > /*  -------------------------------------------------------------------- */
> > 
> > /* 
> >    Include files needed for the CUDA Smoothed Aggregation preconditioner:
> >      pcimpl.h - private include file intended for use by all 
> > preconditioners 
> > */
> > 
> > #include "private/pcimpl.h"   /*I "petscpc.h" I*/
> > #include "../src/mat/impls/aij/seq/aij.h"
> > #include <cusp/precond/smoothed_aggregation.h>
> > #include "../src/vec/vec/impls/dvecimpl.h"
> > #include "../src/mat/impls/aij/seq/seqcuda/cudamatimpl.h"
> > 
> > 
> > [2]
> > http://code.google.com/p/thrust/source/browse/thrust/detail/device/cuda/detail/b40c/vector_types.h
> > 
> > [3]
> > http://code.google.com/p/thrust/source/browse/thrust/detail/device/cuda/detail/b40c/radixsort_scanscatter_kernel.h
> > ---
> > Victor L. Minden
> > 
> > Tufts University
> > School of Engineering
> > Class of 2012
> > 
> 
> 


Reply via email to