python package using a Fortran library

Michael Wimmer wimmer.mike at gmail.com
Thu Jul 18 02:18:24 PDT 2013


Am 7/18/13 10:36 AM, schrieb Clemens Lang:
> Hi,
> 
> On Wed, Jul 17, 2013 at 08:14:15PM -0400, Lawrence Velázquez wrote:
>> No one said anything about Python +gccXY variants in that thread. If
>> the maintainers of the Python ports can be convinced to add such
>> variants (or to create subports so that other ports could depend on
>> them), that would be fine.
> 
> Please do not introduce new variants on language interpreter ports,
> especially if they might instroduce binary incompatibilities. All python
> modules compiling native code would need to have the same variants added
> to mark binary compatibility, because otherwise potentially incompatible
> packages would get downloaded from the buildbot.
> 

Somehow my original question resulted in quite a debate about
fundamental issues which I certainly did not intend ...

The practical situation in macports right now is that for the situation
described (a pyhon package that has extensions using a fortran library)
I need to mix binaries/libraries created from different compilers. I
have two possibilities for that:

1. Compile the python extensions using the macports gcc.

Pro: I can link easily against the fortran library and
     libgfortran.
Con: Possibly a compatibility problem as the extension is
     compiled with a different compiler than python itself. In
     practice, this however rarely seems to be a problem. For example,
     py-scipy is compiled with the gcc compilers.
How: This is somewhat involved, as the setuptools/distutils
     mechansim of python *would* like to use the same compiler/options
     as python. One can override that by setting environment variables

     CC=gcc-mp-..
     LDSHARED=gcc-mp-.. -shared -undefined dynamic_lookup
     CFLAGS=-dynamic

     What I particularly don't like is that I have to set my own CFLAGS
     instead of pythons's CFLAGS (if you don't do it, then setuptools
     adds -arch x86_64 -arch i386 to the flags as it wants to compile a
     universal binary with clang. That doesn't work with gcc). It seems
     to me that this could be a source of errors.

     Note that I mentioned above that py-scipy is compiled with gcc.
     The situation there is a bit special, as numpy/scipy heavily
     modifies distutils, and that's not applicable to other python
     packages

2. Compile the python extensions using Xcode (as is default)

Pro: I don't have to "hack" setuptools/distutils using environment
     variables; potentially more compatible.
Con: I have to link with a fortran library from a different compiler,
     and to libgfortran of the gcc version used to build that library.
     While there could be incompatibilities, this again usually works.
How: Essentially I have to add the path of the respective libgfortran
     to my compile options for Xcode.

     Now, and this was my original question, I don't know how to figure
     out this path automatically. Is it somehow possible to find within
     a portfile which variant (gcc version) of the fortran library was
     installed? As far as I understand, i cannot depend on a specific
     variant of  a port, or can I?

Hence, 1 and 2 seem to be the only practical options. Both are not
perfect, but that's how it is.

Any thoughts?

Best,

Michael


More information about the macports-users mailing list