Compiling Fortran code for Python module

[Michael Dickens]

In my recent (still not fully tested and hence not yet checked in) work
with numpy and scipy, to get +universal working robustly, I have to
manually set env LDFLAGS="-undefined dynamic_lookup -bundle", and also
be careful with the other *FLAGS (e.g., CFLAGS, CPPFLAGS, CXXFLAGS,
F2CFLAGS, ...). IIRC, the default Python distutils will -overwrite-
their internal LDFLAGS, but -augment- the other *FLAGS. There's also an
option when specifying a compile to do it using "noopt" or "noarch" --
disable optimization or arch-specific flags; the former implies the
latter.  There are also some compiles that I've run across in scipy and
numpy that overrule the LDFLAGS default, but will honor the env LDFLAGS
-- so, setting them this way seems to work very well all around.  I'm
betting this is what Frank came upon. - MLD

On Thu, May 2, 2013, at 09:32 PM, Joshua Root wrote:
> The default LDSHARED command when building C extensions for python
> definitely contains "-bundle -undefined dynamic_lookup". For example
> this is a link command run by py27-game (which succeeds, of course):
> 
> /usr/bin/clang -bundle -undefined dynamic_lookup -L/opt/local/lib -arch
> x86_64 -arch x86_64 build/temp.macosx-10.7-x86_64-2.7/src/imageext.o
> -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib
> -lSDL -lSDL_image -lpng -ljpeg -o
> build/lib.macosx-10.7-x86_64-2.7/pygame/imageext.so
> 
> So it's not clear why (a) you would have to add it manually at all, or
> (b) why it would fail like that. For (a), I can only guess that maybe
> the setup.py is overriding some of the standard distutils behaviour for
> handling environment variables, and overwriting something when it should
> append. The environment is one of the relevant differences between
> running it manually and from a portfile.