On Jul 15, 2013, at 02:33, Kasper Peeters wrote: >> I believe the developer is confusing "gcc-4.2" with "gcc42". > > I may very well have at some point (given they look, eh, kinda > similar ;-) ). I don't think that's the issue anymore. The issue is > definitely that if I do not restrict to Apple's gcc version 4.2 but > allow the Macports gcc version 4.2 as well, I end up with a binary > linked to two libstdc++ libraries (or at least that is what ldd shows > me), and associated malloc crashes. I seem to remember the same is true > for XCode gcc 4.2. > >> I propose the port should continue to allow Xcode GCC, as it did >> before this change. > > I have had users report that this leads to a crashing binary, but would > certainly like to have a second opinion on this. I think I tried this > as well, but am not absolutely sure. > >> I can do some testing on earlier OS X in the coming days to see if it >> builds correctly with this. > > I am not entirely sure this depends much on the version of OS X, but > yes please, if you can find the time to test this, that would be very > helpful. Thanks. > > Right now, my main priority is to get this to work again, as the > current version in Macports certainly does not work and is just a bunch > of wasted bits.
I was hoping to be able to avoid having to do this, but let me try to explain the compiler situation in MacPorts. configure.compiler gcc-4.2 means Apple GCC 4.2 build 5666.3 as installed by Xcode in /usr/bin/gcc-4.2. This is the default compiler in Xcode 3.2.x on Snow Leopard. It's also available in Xcode 3.0.x and 3.1.x on Leopard. As of MacPorts 2.2, it will be the default compiler on Leopard as well. It's also available in Xcode 4.0.x and 4.1.x on Snow Leopard and Lion. configure.compiler apple-gcc-4.2 means Apple GCC 4.2 build 5666.3 as installed by the MacPorts apple-gcc42 port in /opt/local/bin/gcc-apple-4.2. It should be identical to the version Xcode provides. The purpose of the apple-gcc42 port is to provide Apple GCC 4.2 to those users whose Xcode versions do not include it. There should be no reason to force users to use the apple-gcc42 port if they already have Apple GCC 4.2 in Xcode. cadabra just finished building successfully for me with gcc-4.2 on Snow Leopard. What steps should I now perform to verify whether it works correctly? configure.compiler gcc-4.0 means Apple GCC 4.0 as installed by Xcode in /usr/bin/gcc-4.0. This is the default compiler on Tiger. With MacPorts 2.1.x and earlier, it's also the default on Leopard. configure.compiler apple-gcc-4.0 means Apple GCC 4.0 as installed by the MacPorts apple-gcc40 port in /opt/local/bin/gcc-apple-4.0. It may be a slightly newer version than Xcode provides but probably nobody needs this since 4.2 should work just as well. configure.compiler llvm-gcc-4.2 means the LLVM GCC 4.2 compiler as installed by Xcode in /usr/bin/llvm-gcc-4.2. This is the default for users with Xcode 4.0.x and 4.1.x. configure.compiler apple-llvm-gcc-4.2 means the LLVM GCC 4.2 compiler as installed by the MacPorts llvm-gcc42 port in /opt/local/bin/llvm-gcc-4.2. It should be the same software as Xcode provides, or perhaps a slightly newer version. The purpose of the llvm-gcc42 port is to provide LLVM GCC 4.2 to those users whose Xcode versions do not include it. It has been announced that Xcode 4.6.x is the last version of Xcode that will include LLVM GCC 4.2. configure.compiler clang means the LLVM clang compiler as installed by Xcode in /usr/bin/clang. This is the default compiler for users with Xcode 4.2.x or later. The clang version varies widely depending on the installed version of Xcode. Ports not compatible with certain versions of Xcode clang can use the compiler_blacklist_versions portgroup to specify that. configure.compiler clang-X.Y means the LLVM clang compiler version X.Y as installed by the MacPorts clang-X.Y port in /opt/local/bin/clang-X.Y, where X.Y is between 2.9 and 3.4 inclusive currently. All of the above compilers should be using the same Apple standard C++ library provided by OS X in /usr/lib/libstdc++.dylib. There should be no problem linking a library built with one of the above compilers with a library or program built with another of these compilers. configure.compiler gcc-4.Z means the FSF GCC compiler version 4.Z as installed by the MacPorts gcc-4.Z port in /opt/local/bin/gcc-mp-4.Z, where Z is between 2 and 9 inclusive currently. These compilers use a different standard C++ library -- the one installed by the libstdcxx (or libstdcxx-devel) port in /opt/local/lib/libstdc++.6.dylib -- and this can cause problems linking libraries compiled with these compilers with libraries or programs compiled with the other compilers that use Apple's standard C++ library. I believe this is the problem you were referring to. And lately, there is a new wrinkle to all of this, wherein we now have /usr/lib/libc++.dylib which I believe is meant to eventually replace /usr/lib/libstdc++.dylib. But I'll leave this part to someone else to explain (because I don't know the explanation). _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
