Fortran recipe

[Chris Jones]

Hi,

I've submitted an update to ROOT to try and address the C++ runtime issues (as well as bump the version to the latest upstream version, and improve the cocoa variant). 

https://trac.macports.org/ticket/40432

Could someone take a look ?

cheers Chris

On 26 Aug 2013, at 2:07am, Jeremy Huddleston Sequoia <jeremyhu at macports.org> wrote:

> 
> On Aug 25, 2013, at 13:53, Chris Jones <jonesc at hep.phy.cam.ac.uk> 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++). 
> 
> That's not exactly correct.  There are three runtimes we are concerned with: host libstdc++, host libc++, and MacPorts libstdc++ (libgcc port)
> 
> Here's the breakdown:
> 
> gcc-*            : host libstdc++
> *llvm-gcc-4.2    : host libstdc++
> apple-gcc-*      : host libstdc++
> macports-gcc-*   : MP libstdc++
> dragonegg-*      : MP libstdc++
> clang < 163      : host libstdc++
> clang >= 163     : host libstdc++ or host libc++
> macports-clang-* : host libstdc++ or host 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 …
>> 
>> Removing the gcc variants is thus a good idea to avoid this. I have a version under test which does this, uses the fortran recipe JH posted earlier in this thread, and fixes the cocoa variant by selecting the compiler in a better way. 
> 
> This solves the primary issue of mixing the MP runtime and the host runtime.  We will still need to deal with host libc++ vs host libstdc++, but those problems are much more obvious (build failure).
> 
>> Note that for those users that *really* want to use gcc, they will always be able to do something like
>> 
>>> sudo port install root configure.compiler=macports-gcc-4.8
>> 
>> So all is not lost, but by doing so you are accepting whatever the consequences might be.
> 
> And such expert users might want to set configure.compiler globally after they first bootstrap it.
> 
> --Jeremy
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2030 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130909/fd7f22f3/attachment.p7s>