gcc version mismatches

[Kyle Husmann]

On Wed, Nov 16, 2011 at 7:33 PM, Kyle Husmann <kyle.husmann at gmail.com> wrote:
> On Wed, Nov 16, 2011 at 7:06 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>
>> On Nov 16, 2011, at 20:40, Kyle Husmann wrote:
>>
>>> I'm wondering if it is possible to build the entire macports tree with
>>> a custom gcc version. (I would like to use gcc44). Here's why I think
>>> I need to do this:
>>>
>>> I've installed octave-devel from the macports tree, which uses gcc44.
>>> I have have some programs (outside of macports) that link against
>>> liboctave. Some of these work, others of these fail with malloc errors
>>> ("pointer being freed was not allocated"). When running these programs
>>> with DYLD_PRINT_LIBRARIES, I found that both
>>> /opt/local/lib/gcc44/libstdc++.6.dylib AND /usr/lib/libstdc++.6.dylib
>>> are being loaded. This doesn't seem like a good thing because the
>>> version of libstdc++ shipped by apple isn't necessarily compatible
>>> with gcc's, and I think it could very well be the source of these
>>> problems.
>>>
>>> So, the only solution I can think of is to recompile EVERYTHING with
>>> gcc44. Is this possible?
>>
>> You would have to add e.g. "configure.compiler=macports-gcc-4.4" to the end of every "port install" command, i.e.
>>
>> sudo port install foo configure.compiler=macports-gcc-4.4
>>
>> There isn't a switch in macports.conf for this because we don't really want users changing the compiler. It's yet another variable to how a port would be installed on a user's system, yet another thing that the user could choose wrong.
>>
>> In your particular situation, you may be right about a mismatch in the stdc++ libraries. This kind of problem is the reason why some time ago there was an initiative to standardize the gcc variants, at least amongst the science ports, and to have them use the same version of gcc by default (gcc44, the latest at the time). But of course many of the science ports are not islands -- they have dependencies on other "regular" software like graphics libraries, which we don't put compiler variants in.
>>
>> Also, understand that when you use a MacPorts gcc compiler, you lose the ability to build universal ports. If you are on a 64-bit Mac, and one of the ports you want to use is only available for 32-bit, then that will be a problem. (The solution should be to set build_arch to i386 in macports.conf and rebuild all ports.)
>>
>>
>>
>
> Oops, didn't reply all. Still getting used to the new gmail interface...
>
>> But of course many of the science ports are not islands
>> -- they have dependencies on other "regular" software
>> like graphics libraries, which we don't put compiler variants in.
>
> Right. Does this mean that any science library that depends on other
> libraries that don't have the compiler variants is in danger of
> undefined behavior? This seems like a rather critical problem,
> _especially_ for scientific programs that are trusted to provide
> reliable answers.
>
> To check, I just ran octave with the DYLD_PRINT_LIBRARIES flag and
> confirmed that it is loading both the macports and osx version of
> libstdc++. Even though I haven't had any crashes running it (yet),
> this seems dangerous!
>
>> You would have to add e.g.
>> "configure.compiler=macports-gcc-4.4" to the end of
>> every "port install" command, i.e.
>
> Great! I'll see if I can compile all the deps from scratch using this
> trick. Fingers crossed...
>

Also, I've found another hitch when adding the
"configure.compiler=macports-gcc-4.4" command: It doesn't
automatically rebuild ports that have binary distributions. How do I
force compilation of all the packages?

Kyle