> > 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
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users