On Wed, Nov 16, 2011 at 7:33 PM, Kyle Husmann <kyle.husm...@gmail.com> wrote:
> On Wed, Nov 16, 2011 at 7:06 PM, Ryan Schmidt <ryandes...@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
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
