-fPIC not included in f2py flags when FFLAGS set

[mandli]

I am not sure if this is something we can fix but when I run any of the examples I get errors related to not including -fPIC in the compiling flags. I ran

env --unset=FFLAGS make

in one of the applications and everything worked fine. I also tried adding

ifdef FFLAGS
    FFLAGS += -fPIC
else
    FFLAGS = -fPIC
endif

to Makefile.variables which also seems to have solved the problem. It does not look like we are doing anything special with f2py arguments so it may be prudent to either include the above Makefile fix or pass f2py the user defined FFLAGS variable through the appropriate command line flags.

[ahmadia]

f2py usually knows the right way to compile Fortran files for Python. The
problem is getting the information from f2py to our Makefiles. My
workaround has been to explicitly set FC="gfortran -fPIC" or similar. The
problem with explicitly setting FFLAGS in the Makefile is that -fPIC is
gfortran-specific, and we use different flags on XL and other compilers.

One intermediate solution is to set the default Makefile.variables to use
gfortran and its associated flags, and then have the user modify that if
they are doing something exotic.

A

On Thu, Dec 1, 2011 at 2:16 AM, Kyle Mandli <
reply@reply.github.com

wrote:

I am not sure if this is something we can fix but when I run any of the
examples I get errors related to not including -fPIC in the compiling
flags. I ran

env --unset=FFLAGS make

in one of the applications and everything worked fine. I also tried adding

ifdef FFLAGS
   FFLAGS += -fPIC
else
   FFLAGS = -fPIC
endif

to Makefile.variables which also seems to have solved the problem. It
does not look like we are doing anything special with f2py arguments so it
may be prudent to either include the above Makefile fix or pass f2py the
user defined FFLAGS variable through the appropriate command line flags.

---

Reply to this email directly or view it on GitHub:
#102

[mandli]

Would a better fix then be to include some Makefile logic with this dependent on the compiler? In the newer Clawpack Makefiles we have been including something like this for module flags since they are also compiler dependent. Perhaps something like

ifeq ($FC,gfortran)
    FFLAGS = -fPIC
else ifeq ($FC,ifort)
    FFLAGS = -shared
else ...

I left out the ifdef part since it would have to be nested in there somehow. We could also do this with the FC variable as well but I think it does the same thing.

The other option is to look into what the --f90flags= does and see if it fixes this problem appropriately.

[ahmadia]

This is a problem with the FFLAGS environment variables being set interfering with f2py, and doesn't have anything to do with our Makefiles. I'm going to close this issue. Kyle, please reopen this if I screwed up :)

[mandli]

This seems to have broken again with the pull request for issue #103.

[ahmadia]

@mandli I'm still convinced that this is an error in your system setup, not a bug in the PyClaw build system. Let me make sure I understand this:

• If the FFLAGS environment variable exists, f2py cannot build shared objects correctly, regardless of whether you are trying to build PyClaw code or a simple Fortran module.
• You can work around this by unsetting FFLAGS.

This is because when f2py detects an exported FFLAGS it will replace its compile flags with the contents of FFLAGS, it will not append any flags that your environment fails to specify (such as building relocatable code). The correct answer here is to either unset FFLAGS before you start trying to build PyClaw, or ensure the exported FFLAGS are correct.

[mandli]

I don't think this is a problem with PyClaw but a problem with the way f2py gets flags. What really should do is always append -fPIC to everything since having it twice does not damage but not having it breaks everything. My suggestion is to somehow use --f90flags and -f77flags to get around this but I am not sure how to block f2py from using FFLAGS. After playing with this a bit, I don't think it's going to work though.

I guess I ready to relent on this subject as it appears I really should not be setting my own generic flag variables in the environment. What is the current "best practice" in terms of overriding flagging variables then, just to do it on the make line or configure? This seems a bit tedious.

[ahmadia]

Discussion moved to https://groups.google.com/d/topic/claw-dev/Irt7qQv7C0E/discussion