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 <jerem...@macports.org> wrote: > > On Aug 25, 2013, at 13:53, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote: > >> Hi, >> >> On 25 Aug 2013, at 7:22pm, Christoph Deil <deil.christ...@gmail.com> wrote: >> >>> >>> On Aug 25, 2013, at 10:44 AM, Mojca Miklavec <mo...@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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
