[Dune-devel] dune-common update seems to cause error in my ParMetis routine

[Aleksejs Fomins]

Hey Jö,

Thanks for your suggestion. I have tried to do as you say, and I attach the preprocessor output.

If you search the text for "real_t", you find it is defined once in metis.h

/opt/extlib/parmetis/4.0.3/openmpi/1.10.0/gcc/5.2.0/include/metis.h:120:17
   typedef float real_t;

and once in Dune typetraits

/home/fomins/gitwork/hades-lspr-ag/dune-common/dune/common/typetraits.hh:565:55
 using real_t = typename FieldTraits<Type>::real_type;

I am not sure if I am reading the preprocessor output correctly, but, as far as I can tell, the typetraits definition is inside namespace Dune and metis definition is not inside any namespace. And yet the compiler complains about ambiguous definition of real_t when reading metis.h.


Steffen: I have used the extern "C" in front of parmetis.h as you suggested, but, sadly, the error persists.

Greetings,
Aleksejs


On 23.01.2016 19:44, Jö Fahlke wrote:
> Am Fri, 22. Jan 2016, 15:52:45 +0100 schrieb Aleksejs Fomins:
>> Date: Fri, 22 Jan 2016 15:52:45 +0100
>> From: Aleksejs Fomins <aleksejs.fomins at lspr.ch>
>> To: Christian Engwer <christian.engwer at uni-muenster.de>,
>>  "dune-devel at dune-project.org" <dune-devel at dune-project.org>
>> Subject: Re: [Dune-devel] dune-common update seems to cause error in my
>>  ParMetis routine
>>
>> Compiler is GCC 5.2. Have been using it for like half a year now
>>
>> I suppose that the easiest way to inject would be sth like
>>
>> namespace Dune {
>>   #include <parmetis.h>
>>
>>   ...
>> }
>>
>> However I have explicitly checked that this is not the case. If anybody has ideas of what else could have gone wrong for this injection to happen, ideas are much appreciated.
>>
>> I will search some more and get back to you.
> 
> One way to thoroughly check that this is really not happening is by checking
> the preprocessor output.  Take the g++ invocation that is failing, and in the
> arguments replace "-c" and "-o <something>" by "-E".  Make sure you are in the
> same directory as the original invocation.  Then g++ will print the
> preprocessor output annotated with the original line numbers and source files
> to standard output.  Search for the definitions of real_t in there, that
> should help you figure out what is going on.
> 
> The CMake-generated make files often hide how exactly they invoke the
> compiler, you probably need to do "make V=1" (or was ist "make VERBOSE=1"?) to
> do the build in verbose mode.
> 
> Regards,
> Jö.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.tar.bz2
Type: application/x-bzip
Size: 1408898 bytes
Desc: not available
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20160126/34166dd9/attachment.bin>