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