Fortran recipe

[Eric Cronin]

On Aug 25, 2013, at 4:53 PM, Chris Jones wrote:

> Hi,
> 
> On 25 Aug 2013, at 7:22pm, Christoph Deil <Deil.Christoph at gmail.com> wrote:
> 
>> 
>> On Aug 25, 2013, at 10:44 AM, Mojca Miklavec <mojca at macports.org> wrote:
>> 
>>> On Sun, Aug 25, 2013 at 5:16 PM, Jeremy Huddleston Sequoia wrote:
>>>> Seeing as how many developers don't understand the problems surrounding mixing multiple versions of the C++ runtime in a single process, I doubt that users understand those problems.  I think the root port needs to be simplified significantly.
>>>> 
>>>> Does root use any C++ APIs exposed by the host or other ports?  Does root expose any C++ APIs?
>>> 
>>> I don't understand much about those problems either.
>> 
>> I also don't understand the issues, or how to debug / check them.
>> 
>> I am using a non-public gamma-ray astronomy data analysis package built on top of ROOT.
>> After a lot of trial and error I did get it to compile with Macports gcc, I never managed to compile it with Apple gcc or (Apple or Macports) clang.
>> So at least I can write code and check that it compiles on my Mac  … actually running the software sometimes works and sometimes mysteriously crashes.
>> 
>> Probably this is a very specialised use case, if the Macports GCC variants are removed from the ROOT port I'll just build ROOT from source myself, no problem if that is the right thing to do to avoid "C++ runtime mix errors" (whatever that means).
> 
> The issue is in essence the gcc compilers use one c++ runtime library (libstdc++), the other compiles, clang etc. use another (libc++). Mixing these is a bad idea, so if you where to compile root using gcc, you should in theory compile *all* ports that that uses with it as well. This is not done. Maybe the crashes you refer to are to do with this …

It's actually slightly worse as yesterday's adventures with mkvtoolnix pointed out to me.  pre-Mavericks there are actually 3 C++ runtimes in play within macports: Apple libstdc++ (based on gcc4.2, does not support c++11 or newer FSF gcc's), Apple libc++ (the default system stdlib on mavericks, but only available explicitly using -stdlib before that), and macports-provided FSF libstdc++ (provided by the libgcc or libgcc-devel ports).  Each of the three is incompatible in some way with the other two.  Particularly annoying on pre-Mavericks is that the only one that's 100% compatible with system libraries (Apple libstdc++) is ancient and has no support for C++11.  This is the one used by clang/llvm-gcc/apple-gcc* on Lion and Mountain Lion, not libc++, and it's why -std=c++0x/-std=c++11 doesn't work a lot of the time there when using clang.

On Mavericks and later I think root +cxx11 would be possible since everything there will be compiled using the newer libc++.  On earlier OS releases, even though you could compile root with -stdlib=libc++, it would die at link time because the libraries it depends on were compiled using the incompatible Apple libstdc++ (in this regard it's better than mixing Apple libstdc++ and FSF libstdc++, where they successfully link but fail in strange ways at runtime).

There was some discussion on that ticket about altering macports so that the default c++ compiler was clang++ -stdlib=libc++ and then having a flag day at which time everything needs to be recompiled/upgraded.  That's a big change, and there's a question on if it would even work since apple-provided system libs are all compiled using Apple libstdc++ pre-Mavericks (Accelerate.framework was the one I knew ports used for sure and otool -L says links with libstdc++).  There's definitely some experimenting and testing needed here to see if it's possible.

Thanks,
Eric