Re: Building clang/cling 3.5 for ROOT on Lion
On 08/04/14 01:48, Ryan Schmidt wrote: On Apr 7, 2014, at 18:09, Christopher Jones wrote: p.s. whats the most recent MacPorts clang compiler you can install on OSX10.7 ? clang 3.4 and earlier should build fine on 10.7. 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 ? cheers Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On Apr 8, 2014, at 03:06, Chris Jones jon...@hep.phy.cam.ac.uk wrote: On 08/04/14 01:48, Ryan Schmidt wrote: On Apr 7, 2014, at 18:09, Christopher Jones wrote: p.s. whats the most recent MacPorts clang compiler you can install on OSX10.7 ? clang 3.4 and earlier should build fine on 10.7. 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+. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
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) ? Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
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? 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)? Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
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
Re: Building clang/cling 3.5 for ROOT on Lion
On 2014-4-8 18:06 , Chris Jones wrote: On 08/04/14 01:48, Ryan Schmidt wrote: On Apr 7, 2014, at 18:09, Christopher Jones wrote: p.s. whats the most recent MacPorts clang compiler you can install on OSX10.7 ? clang 3.4 and earlier should build fine on 10.7. 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 ? You can actually use libc++ all the way back to 10.6 (with the libcxx port). The trick is that if you build root against libc++, then every library it uses via a C++ API must also be built against libc++, and likewise for every library that uses it via a C++ API. It sounds like root wants to use bundled copies of all its dependencies, which while suboptimal for all the usual reasons, does at least solve that side of the problem. I don't know if root exposes a C++ API for its dependents, but if it does, they could also be made to use libc++. So it's not impossible, just highly inconvenient. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
You can actually use libc++ all the way back to 10.6 (with the libcxx port). The trick is that if you build root against libc++, then every library it uses via a C++ API must also be built against libc++, and likewise for every library that uses it via a C++ API. Yes, but that doesn't help here, as the libc++ on 10.6 does not support c++11 fully. See below. It sounds like root wants to use bundled copies of all its dependencies, which while suboptimal for all the usual reasons, does at least solve that side of the problem. I don't know if root exposes a C++ API for its dependents, but if it does, they could also be made to use libc++. Not really. ROOT will use external dependencies just fine. Its just ROOT6 has moved to a new interpreter based on clang, 'cling', and to build this ROOT6 does internally build parts of a clang release, which currently is I believe based on clang 3.5. They have also decided to fully embrace c++11 (I good thing) but this means root6 now only supports compilers that fully support c++11. That can be libc++ or libstdc++ (ROOT6 builds fine with gcc 4.8 on linux), it just has to be fully c++11 compliant... Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On 2014-4-8 20:02 , Chris Jones wrote: You can actually use libc++ all the way back to 10.6 (with the libcxx port). The trick is that if you build root against libc++, then every library it uses via a C++ API must also be built against libc++, and likewise for every library that uses it via a C++ API. Yes, but that doesn't help here, as the libc++ on 10.6 does not support c++11 fully. Which parts doesn't it support? The description of the port specifically says that it is targeting C++11. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On 08/04/14 11:26, Joshua Root wrote: On 2014-4-8 20:02 , Chris Jones wrote: You can actually use libc++ all the way back to 10.6 (with the libcxx port). The trick is that if you build root against libc++, then every library it uses via a C++ API must also be built against libc++, and likewise for every library that uses it via a C++ API. Yes, but that doesn't help here, as the libc++ on 10.6 does not support c++11 fully. Which parts doesn't it support? The description of the port specifically says that it is targeting C++11. I am only going on the reports I have seen from Mojca (I only have OSX10.9) but it appears std::move at least is not supported. Chris - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On Tue, Apr 8, 2014 at 12:53 PM, Chris Jones wrote: On 08/04/14 11:26, Joshua Root wrote: On 2014-4-8 20:02 , Chris Jones wrote: You can actually use libc++ all the way back to 10.6 (with the libcxx port). The trick is that if you build root against libc++, then every library it uses via a C++ API must also be built against libc++, and likewise for every library that uses it via a C++ API. Yes, but that doesn't help here, as the libc++ on 10.6 does not support c++11 fully. Which parts doesn't it support? The description of the port specifically says that it is targeting C++11. I am only going on the reports I have seen from Mojca (I only have OSX10.9) but it appears std::move at least is not supported. I didn't say that libc++ doesn't work – I didn't try that at all (I'm not even sure I know how to do it; maybe I could create a new macports installation with instructions posted by Jeremy a while ago). I just said that using clang-3.4 doesn't help as that doesn't support all c++11 features needed by cling. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On Apr 8, 2014, at 03:12, 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) ? The point is you wouldn’t be mixing C++ runtimes. On 10.8 and earlier, the C++ runtime is libstdc++, just as gcc48’s is. They’re different versions of libstdc++, but sometimes they’re similar enough to still work together. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On Tue, Apr 8, 2014 at 1:55 PM, Ryan Schmidt wrote: The point is you wouldn’t be mixing C++ runtimes. On 10.8 and earlier, the C++ runtime is libstdc++, just as gcc48’s is. They’re different versions of libstdc++, but sometimes they’re similar enough to still work together. Does that mean that it makes sense to report bugs/problems when binaries compiled with gcc48 crash (or when compilation crashes)? Would anyone care at all to look into these problems? Or just that it's worth trying ... and not be disappointed in case of problems? Mojca PS: It's not an issue of me personally upgrading the OS. I'll do that sooner or later. But it would be slightly suboptimal if the port only worked on 10.9. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On Apr 8, 2014, at 07:13, Mojca Miklavec wrote: On Tue, Apr 8, 2014 at 1:55 PM, Ryan Schmidt wrote: The point is you wouldn’t be mixing C++ runtimes. On 10.8 and earlier, the C++ runtime is libstdc++, just as gcc48’s is. They’re different versions of libstdc++, but sometimes they’re similar enough to still work together. Does that mean that it makes sense to report bugs/problems when binaries compiled with gcc48 crash (or when compilation crashes)? Would anyone care at all to look into these problems? Or just that it's worth trying ... and not be disappointed in case of problems? I’d say the latter. Whereas mixing libc++ and libstdc++ fails at compiling already, miking Apple’s old libstdc++ and gcc48’s new libstdc++ may work, or it may cause crashes; if the latter, that’s just the way it is. Mojca PS: It's not an issue of me personally upgrading the OS. I'll do that sooner or later. But it would be slightly suboptimal if the port only worked on 10.9. Personally, I feel that the cleanest solution is that C++11 code requires OS X 10.9 or later, unfortunately. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
I didn't say that libc++ doesn't work – I didn't try that at all (I'm not even sure I know how to do it; maybe I could create a new macports installation with instructions posted by Jeremy a while ago). I just said that using clang-3.4 doesn't help as that doesn't support all c++11 features needed by cling. by using clang34 I believe you are implicitly using libc++ anyway... Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
PS: It's not an issue of me personally upgrading the OS. I'll do that sooner or later. But it would be slightly suboptimal if the port only worked on 10.9. As a general point, I agree, only OSX10.9 has full c++11 support. However, upstream claim to be targeting 10.8 and 10.9, so I would hope it would work on OSX10.8 as well (to be tested sometime, by someone who has access to a 10.8 machine). Whilst not ideal, I think this is reasonable coverage (given root5 will remain available for all versions). Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On Apr 8, 2014, at 07:34, Chris Jones wrote: PS: It's not an issue of me personally upgrading the OS. I'll do that sooner or later. But it would be slightly suboptimal if the port only worked on 10.9. As a general point, I agree, only OSX10.9 has full c++11 support. However, upstream claim to be targeting 10.8 and 10.9, so I would hope it would work on OSX10.8 as well (to be tested sometime, by someone who has access to a 10.8 machine). Whilst not ideal, I think this is reasonable coverage (given root5 will remain available for all versions). Well, libc++ (with full C++11 support) is included in 10.8, it’s just not the default. As long as root doesn’t use any other libraries, it should build fine with that, if you instruct it to. But then any other software that wants to use root would have to do that as well. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: binary install details ...
Hi, Unfortunately there's no easy way to say fetch the archives for the ports that have them, and the distfiles for those that don't. You can use $ sudo port -bp archivefetch $portlist to get all the binary archives available and ignore those that aren't. This is one of the few places where `-p` is not harmful. Adding `-b` might help in this case because it doesn't give up after three servers that don't have the binary archive. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On 08/04/14 13:35, Ryan Schmidt wrote: On Apr 8, 2014, at 07:34, Chris Jones wrote: PS: It's not an issue of me personally upgrading the OS. I'll do that sooner or later. But it would be slightly suboptimal if the port only worked on 10.9. As a general point, I agree, only OSX10.9 has full c++11 support. However, upstream claim to be targeting 10.8 and 10.9, so I would hope it would work on OSX10.8 as well (to be tested sometime, by someone who has access to a 10.8 machine). Whilst not ideal, I think this is reasonable coverage (given root5 will remain available for all versions). Well, libc++ (with full C++11 support) is included in 10.8, it’s just not the default. As long as root doesn’t use any other libraries, it should build fine with that, if you instruct it to. But then any other software that wants to use root would have to do that as well. I see. Well, that might then cause problems as well :( ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On 2014-4-8 22:35 , Ryan Schmidt wrote: On Apr 8, 2014, at 07:34, Chris Jones wrote: PS: It's not an issue of me personally upgrading the OS. I'll do that sooner or later. But it would be slightly suboptimal if the port only worked on 10.9. As a general point, I agree, only OSX10.9 has full c++11 support. However, upstream claim to be targeting 10.8 and 10.9, so I would hope it would work on OSX10.8 as well (to be tested sometime, by someone who has access to a 10.8 machine). Whilst not ideal, I think this is reasonable coverage (given root5 will remain available for all versions). Well, libc++ (with full C++11 support) is included in 10.8, it’s just not the default. As long as root doesn’t use any other libraries, it should build fine with that, if you instruct it to. But then any other software that wants to use root would have to do that as well. Indeed, if you can get around the issues with using a non-default runtime on 10.8, then that should transfer pretty easily to 10.7 and 10.6 as well. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On 08/04/14 13:41, Joshua Root wrote: On 2014-4-8 22:35 , Ryan Schmidt wrote: On Apr 8, 2014, at 07:34, Chris Jones wrote: PS: It's not an issue of me personally upgrading the OS. I'll do that sooner or later. But it would be slightly suboptimal if the port only worked on 10.9. As a general point, I agree, only OSX10.9 has full c++11 support. However, upstream claim to be targeting 10.8 and 10.9, so I would hope it would work on OSX10.8 as well (to be tested sometime, by someone who has access to a 10.8 machine). Whilst not ideal, I think this is reasonable coverage (given root5 will remain available for all versions). Well, libc++ (with full C++11 support) is included in 10.8, it’s just not the default. As long as root doesn’t use any other libraries, it should build fine with that, if you instruct it to. But then any other software that wants to use root would have to do that as well. Indeed, if you can get around the issues with using a non-default runtime on 10.8, then that should transfer pretty easily to 10.7 and 10.6 as well. Thats OK for a standalone build, but the whole point of having root in macports is to pick up various dependencies from Macports. This trick would then only work if the user built all of these dependencies against libc++ as well. SO unless MacPorts is planning on switch its 10.8 builds to by default use libc++, this doesn't help much with getting the port working on 10.8 Chris - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: binary install details ...
On 2014-4-8 22:37 , Clemens Lang wrote: Hi, Unfortunately there's no easy way to say fetch the archives for the ports that have them, and the distfiles for those that don't. You can use $ sudo port -bp archivefetch $portlist to get all the binary archives available and ignore those that aren't. This is one of the few places where `-p` is not harmful. Adding `-b` might help in this case because it doesn't give up after three servers that don't have the binary archive. The giving up isn't usually a problem because it only does that if the archive is not available on packages.macports.org. And actually, I forgot before that archivefetch does adjust the statefile if it fetches an archive. So this should do the trick to fetch everything you need to do an upgrade offline: sudo port archivefetch outdated sudo port fetch outdated (the fetch will be a noop for ports that have an archive available). - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On Tue, Apr 8, 2014 at 2:41 PM, Joshua Root wrote: On 2014-4-8 22:35 , Ryan Schmidt wrote: On Apr 8, 2014, at 07:34, Chris Jones wrote: PS: It's not an issue of me personally upgrading the OS. I'll do that sooner or later. But it would be slightly suboptimal if the port only worked on 10.9. As a general point, I agree, only OSX10.9 has full c++11 support. However, upstream claim to be targeting 10.8 and 10.9, so I would hope it would work on OSX10.8 as well (to be tested sometime, by someone who has access to a 10.8 machine). Whilst not ideal, I think this is reasonable coverage (given root5 will remain available for all versions). Well, libc++ (with full C++11 support) is included in 10.8, it’s just not the default. As long as root doesn’t use any other libraries, it should build fine with that, if you instruct it to. But then any other software that wants to use root would have to do that as well. Indeed, if you can get around the issues with using a non-default runtime on 10.8, then that should transfer pretty easily to 10.7 and 10.6 as well. OK, the following works for a simple test file (on the source code that originally fails when compiling ROOT with clang++-mp-3.4): clang++-mp-3.4 -std=c++11 -stdlib=libc++ test.cpp -o test otool -L test test: /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 28.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) I'll see if I can manage to build the whole ROOT 6 with -stdlib=libc++ (without referencing any other piece from MacPorts). But that probably means that I shouldn't use OpenGL from the system, right? otool -L /System/Library/Frameworks/OpenGL.framework/Versions/Current/OpenGL ... /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) .. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On 2014-4-8 22:48 , Mojca Miklavec wrote: I'll see if I can manage to build the whole ROOT 6 with -stdlib=libc++ (without referencing any other piece from MacPorts). But that probably means that I shouldn't use OpenGL from the system, right? otool -L /System/Library/Frameworks/OpenGL.framework/Versions/Current/OpenGL ... /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) .. Does OpenGL.framework expose a C++ API? (And does root use it?) - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On Tue, Apr 8, 2014 at 2:46 PM, Chris Jones wrote: Thats OK for a standalone build, but the whole point of having root in macports is to pick up various dependencies from Macports. This trick would then only work if the user built all of these dependencies against libc++ as well. SO unless MacPorts is planning on switch its 10.8 builds to by default use libc++, this doesn't help much with getting the port working on 10.8 One option could be if 10.9 or later: use dependencies from MacPorts else: use just the built-in libraries without any advanced functionality or external libraries which is still better than having a nonfunctional port ... of course only if that works at all. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On Tue, Apr 8, 2014 at 2:53 PM, Joshua Root wrote: On 2014-4-8 22:48 , Mojca Miklavec wrote: I'll see if I can manage to build the whole ROOT 6 with -stdlib=libc++ (without referencing any other piece from MacPorts). But that probably means that I shouldn't use OpenGL from the system, right? otool -L /System/Library/Frameworks/OpenGL.framework/Versions/Current/OpenGL ... /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) .. Does OpenGL.framework expose a C++ API? (And does root use it?) How do I know that? Here's a page with examples using OpenGL: http://root.cern.ch/root/htmldoc/tutorials/gl/index.html But I checked and it seems that OpenGL is optional. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
On 08/04/14 13:52, Mojca Miklavec wrote: On Tue, Apr 8, 2014 at 2:46 PM, Chris Jones wrote: Thats OK for a standalone build, but the whole point of having root in macports is to pick up various dependencies from Macports. This trick would then only work if the user built all of these dependencies against libc++ as well. SO unless MacPorts is planning on switch its 10.8 builds to by default use libc++, this doesn't help much with getting the port working on 10.8 One option could be if 10.9 or later: use dependencies from MacPorts else: use just the built-in libraries without any advanced functionality or external libraries which is still better than having a nonfunctional port ... of course only if that works at all. Honestly, I think that is debatable. It would also make the port file a mess. You would have to find a way to prevent root from automatically finding the libraries under /opt/local. I suspect if you just remove all the dependencies, it will still find then. Honestly, I think you are flogging a dead horse a bit here. Unless you can find a clean way to get it working within MacPorts, my vote is just to flag root6 as only working on 10.9 (or 10.8, depending on if it works there or not) and beyond. Chris Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: binary install details ...
Hey, The giving up isn't usually a problem because it only does that if the archive is not available on packages.macports.org. That might be the case for you, since you're close to packages.macports.org, but it isn't necessarily true for people in Europe like me. sudo port archivefetch outdated sudo port fetch outdated That will fail on the first port without an archive, wouldn't it? You'd still need `-p` here. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
I'll see if I can manage to build the whole ROOT 6 with -stdlib=libc++ (without referencing any other piece from MacPorts). But that probably means that I shouldn't use OpenGL from the system, right? Don't forget, you will also need to rebuild each and every port that root uses, that uses a c++ runtime against libc++ as well... Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building clang/cling 3.5 for ROOT on Lion
SO unless MacPorts is planning on switch its 10.8 builds to by default use libc++, this doesn't help much with getting the port working on 10.8 At this time, we believe it is best to leave 10.8 and earlier on libstdc++, and use libc++ on 10.9 and later. There is a FAQ entry… Yes of course. I wasn't suggesting the policy should be changed, just I think it would be the only way to properly support c++11 on OSX10.8, if it where ever decided that was important enough to do. Sorry if that wasn't clear.. Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: binary install details ...
On 2014-4-8 22:58 , Clemens Lang wrote: Hey, The giving up isn't usually a problem because it only does that if the archive is not available on packages.macports.org. That might be the case for you, since you're close to packages.macports.org, but it isn't necessarily true for people in Europe like me. Being close has nothing to do with it. If the archive is on p.m.o then it will never give up until it downloads it (or exhausts the entire list if p.m.o becomes unreachable after it starts). sudo port archivefetch outdated sudo port fetch outdated That will fail on the first port without an archive, wouldn't it? You'd still need `-p` here. It doesn't fail if you're not in binary-only mode. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: curious dependency issues
Well I really think this needs to be documented more clearly. The examples in the guide do not mention it is a regex rather than the exact name of a port, and that is the only documentation I have seen on it. David On Mon, Apr 7, 2014 at 8:46 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Apr 7, 2014, at 17:14, David Strubbe wrote: Ok, I think I see what is going on here: apparently port installed depends:XXX returns all ports depending on port XXX -- OR a port that contains the string XXX. It's a regular expression search. So if you want the ports that depend on gcr, you could use: $ port echo depends:':gcr($|\s)' empathy epiphany evolution-data-server gnome-keyring gnome-online-accounts gnome3-core libgdata seahorse $ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
wildcarding port select files to install ?
Hi, Is it possible to wildcard the files in a XYZ_select port, so that all the files that match the wildcard are installed when a version is selected ? In particular with https://trac.macports.org/browser/users/mojca/ports/sysutils/root_select we would like some way to just have root_select install everything that gets installed in /opt/local/libexec/rootN/bin. The only examples I have seen explicitly list all the files. If we have to list them all then fine (and maybe this is required so the 'none' option knows what to remove ?), I am just curious as to if there is a way or not. cheers Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Giving up maintainership of some ports
Hi Michael, On Apr 7, 2014, at 2:13 PM, Michael Klein michael.kl...@puffin.lb.shuttle.de wrote: as I have currently no access to an Intel Mac and therefore stuck with 10.5, I'd like to give up maintainership of the ports below: py-lightblue (open tickets: 36371, 38666) linuxdoc-tools (42988) AppKiDo (36865) I have removed you as maintainer from py-lightblue [2] and linuxdoc-tools [1] and reset the appropriate tickets to be owned by macports-tickets. AppKiDo was already done [3]. Thanks for letting us know and for volunteering! Cheers! Frank [1] http://trac.macports.org/changeset/118706 [2] http://trac.macports.org/changeset/118707 [3] http://trac.macports.org/changeset/101878 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
A related item that bubbled on the mailing list for a while would be to get the http://trac.edgewall.org/wiki/CommitTicketUpdater configured for MP. This would let us refer to and take actions on (ref #1234 or closes #5432) tickets in commit messages, which ties a nice bow around commits tied to a ticket. It's not at github pull request / comments / sugar-ness level, but it's a nice feature if we could enable it. Any chance of getting that done? - Eric ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Apr 8, 2014, at 21:38, Eric A. Borisch wrote: A related item that bubbled on the mailing list for a while would be to get the http://trac.edgewall.org/wiki/CommitTicketUpdater configured for MP. This would let us refer to and take actions on (ref #1234 or closes #5432) tickets in commit messages, which ties a nice bow around commits tied to a ticket. It's not at github pull request / comments / sugar-ness level, but it's a nice feature if we could enable it. Any chance of getting that done? https://trac.macports.org/ticket/41919 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
