Hi,

On 08/04/14 10:14, Mojca Miklavec wrote:
On Tue, Apr 8, 2014 at 10:12 AM, Chris Jones wrote:

Indeed. They aren't quite the same thing though in the end, as on OSX
10.8 and newer it supports c++11, whereas on 10.7 it doesn't, because of the
underlying system support. So the same clang34 compiler now builds root6
fine on OSX10.9, but fails on 10.7.

My recollection of all the previous times c++11 has been discussed, can
be summarised as there is no obvious way to support it cleanly on older OSX
releases. So if an upstream package, as ROOT6 has, is actively only
targetting c++11 supporting compilers, then effectively these ports cannot
be used on older OSX releases now. Is that correct, or am I being overly
pessimistic here ?


Using latest gcc (currently gcc48) might be a way to support C++11 on OS X
< 10.9, but otherwise, with clang, C++11 requires 10.9+.

Yes, I thought of that. But as I understanding it mixing libc++ and
libstdc++ runtimes is an absolute no no when c++11 is involved, so the user
would have to update their MacPorts settings to build *everything* with
gcc(48) ?

So would it work in theory if ROOT could be compiled without any
external dependencies (other than Cocoa)? And is compiling it "without
external dependencies" (and with some limited functionality) feasible
at all?

Not really within MacPorts. root in macports is designed to use various macports provided dependencies. Thats the benefit of using MacPorts...

First try installing MacPorts gcc48, then use it to build root6 standalone, outside macports, without it finding any of Macports libraries (so move /local/local out the way for a while). If that works, you could try try building inside macports, but you will have to first mac sure to build *every* dependency root needs with gcc48 as well, instead of the normal default compiler.

Honestly, this to me sounds like a lot of effort. I personally would be more inclined to invest that amount of effort in updating my system to 10.9. Ultimately, this is the only way to get a system that properly supports c++11...


I checked and it seems that it's depending on CoreFoundation which
depends on /usr/lib/libobjc.A.dylib, no libstdc++ (but OpenGL depends
on /usr/lib/libstdc++.6.dylib and that's probably needed).

Btw: what's the trick to make fortran-based libraries depend on
/usr/lib/libstdc++.6.dylib in the current port (rather than on
/opt/local/lib/libgcc/libgcc_s.1.dylib)?

Fortran libraries do not need a C++ runtime at all ... If a library that contains fortran symbols is linking against a c++ runtime, it must be because it also contains C++ symbols.

Chris


Mojca


_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to