[petsc-dev] Parmetis / Metis changes

[Sean Farley]

>
> It appears that George is still living in the Linux desert and Sean has so
> pimped out his Mac it is barely running OS X.
>

Oh really? My system is so messed up that I have to have special code in
BuildSystem? Exhibit A:

http://petsc.cs.iit.edu/petsc/BuildSystem/rev/39d608c7ffd5

Let the record show that this only happens on Barry's (barely OS X) machine.


>    One problem I don't know how to fix.
>
>     metis has the file gk_externs.h with the lines
>
> #ifndef _GK_ERROR_C_
> /* declared in error.c */
> extern __thread int gk_cur_jbufs;
> extern __thread jmp_buf gk_jbufs[];
> extern __thread jmp_buf gk_jbuf;
>
> #endif
>
>   The default Mac compilers won't compile it; I don't see how this worked
> for Sean.


I think this is similar to the MPICH bug I reported with clang. __thread is
reported funky with the newest XCode, it seems (which is why I couldn't
compile MPICH with it).


> Anyways no big deal except because of metis's cmake system I don't know
> how I can pass the flag _GK_ERROR_C_ done into the metis cmake system so
> the compiler doesn't see this thing.


Actually, you'd want to pass -D__thread= which is how metis handles it with
other compilers. I don't know why llvm is reporting __thread incorrectly.

Any ideas on how to pass it from metis.py??????


This is an annoying fact of the way that metis's makefile passes variables
to cmake. We could circumvent the top-level makefile entirely, but that
would lock us into a permanent battle with doing the same with every metis
release. Or I could just patch the top-level makefile to take a
"cflags='-blah'" argument and hope that George accepts the patch. I'm
leaning towards the patch. I've implemented both but will see how I feel
about it tomorrow before I push any changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111120/8a0c362b/attachment.html>