On 03/11/14 21:57, Zach Davis wrote:
> It appears that didn’t work—PyFR complains about being unable to find
> the OpenMP header file. Looking at the compiler.py file in
> ${PYFR_ROOT}/pyfr/backends/openmp/ on line 55 you are using the value
> of cc to get the path of the compiler to be used. Unfortunately, on
> OS X this is a symbolic link to clang.
>
> Is there an environment variable that PyFR supports that will allow
> you to change which c compiler is used? Setting the shell
> environment variable CC is ignored, so I was hoping there might be an
> alternative way to explicitly specify the compiler PyFR uses. I have
> both gcc-4.9 (4.9.2) and have built an OpenMP compatible version of
> clang which I’ve named clang-omp to test; however, I can’t figure out
> how to direct PyFR to use those, rather than the cc symbolic link
> (which points to clang bundled with Apple’s XCode command line
> tools).
>
> Note, you also outlined an example of getting the copy of gcc-4.8
> installed on your mac to compile a simple Hello World example. I
> believe if you replaced the -march=native option with something like
> -msse4.2 or -mtune=native, then the code snippet compiles without the
> error. Although, I’m not certain that is relevant to what you were
> pointing out.
The compiler used by PyFR can be changed in the configuration file. For
example on my Linux system I have:
[backend-openmp]
cc = gcc-4.8.3
if you are going to be experimenting you might want to put
[backend-openmp]
cc = ${CC}
and then you can simply export CC in your shell to be your desired
compiler. We do not currently support expansions such as:
[backend-openmp]
cc = gcc -fsomething
the 'cc' field must be an executable. Similarly, we do not -- currently
-- permit one to append arguments to the compiler invocation. (Although
this is can be trivially accomplished with a one-line shell script
should any user require this feature.)
With regards to GCC on the Mac, yes it is -march=native that is causing
the trouble. I would, however, rather that compilers not try and emit
assembly instructions which they know can not be assembled on the
current system!
Regards, Freddie.
--
You received this message because you are subscribed to the Google Groups "PyFR
Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send an email to [email protected].
Visit this group at http://groups.google.com/group/pyfrmailinglist.
For more options, visit https://groups.google.com/d/optout.
