python package using a Fortran library

Michael Wimmer wimmer.mike at gmail.com
Wed Jul 17 15:47:23 PDT 2013


> > You are correct in the general case but not in this particular special
> case, and the Python and Perl extension mechanisms force the compiler for
> very good reasons.
>
> And MacPorts forces the compiler for very good reasons. The very specific
> problem that this Python decision causes for MacPorts has been demonstrated
> by users using Xcode 4.2 on Snow Leopard. Our Snow Leopard packages are
> built on a buildbot with Xcode 3.2.6 with gcc-4.2; Xcode 4.2 does not
> contain gcc-4.2. Therefore any users on Snow Leopard with Xcode 4.2 who
> receive our pre-compiled binary for Python will be unable to compile any
> modules because they will try to use gcc-4.2.
>

Ok, but what does all that mean in practice now?

There is no gcc variant of python, and as argued in  a recent thread on the
macports mailing list (
https://lists.macosforge.org/pipermail/macports-users/2013-June/032891.html),
this is not going to changed. Note that that previous
post describes exactly the same problem I run into:

1.) python is built with Xcode, so all python extensions/modules should be
compiled with the same compiler. Using another
compiler is not guaranteed to work, but usually does work (in fact,
py-scipy is compiled using the macports gcc, unlike all other
python packages I looked at.)

2.) When linking to some external library, one should best also use the
same compiler as that library (especially when mixing C with
Fortran ...). But again, usually mixing different compilers does work, too.

Now, in many instances 1) and 2) can't be fulfilled at the same time. So
what's the lesser evil?

Best,

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20130718/7cbd0f0a/attachment.html>


More information about the macports-users mailing list