Re: C++11 on Mountain Lion and lower?
In article 69d2e4c6-38df-4a86-a650-856ac9dac...@macports.org, Ryan Schmidt ryandes...@macports.org wrote: On Dec 4, 2013, at 20:16, Joshua Root wrote: And there are machines with 64-bit processors but 32-bit EFI that can't go past 10.7. Which machines are you thinking of? The system requirements of Mavericks are pretty liberal: http://support.apple.com/kb/ht5842 For example, the mid-2007 MacBookPro3,1, which I have, which is supported, has a 64-bit processor but under Snow Leopard boots to the 32-bit kernel. Under later OS releases my understanding is that it boots to the 64-bit kernel. http://www.tuaw.com/2012/02/16/mountain-lion-drops-support-for-several-older-ma c-models/ -- Ned Deily, n...@acm.org ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Am 04.12.2013 01:24, schrieb Christopher Jones: Hi, This is more what I was thinking for this case. Have the port use a newer c++11 enabled version on OSX versions that support it, and a older version where they don’t. Hi, maybe I got lost in this thread but I think multiple issues get mixed up. I try to summarize some points here in the hope that it's useful. - C++11 code requires a recent version of libc++ or libstdc++ - same with other c++ code that for any reason needs a more recent version than Apples g++ implementation. - The only C++ runtime that Apple provides on all systems since 10.5(?) is the one delivered with gcc 4.2.1. I really doubt that Apple will change that to a recent libc++ - I don't see what the question of C++11 support and thus the c++ library version has to do with the OSX version besides, presumably, that 10.9 is the first OSX release with full (?) C++11 support in the preinstalled C++ standard library. macports provides two recent C++ implementations, clang/libc++ and FSF g++, that both work on systems earlier than 10.9 - I doubt but don't know whether there are any other C++ libraries in /usr/lib (besides a stone old implementation of wxWidgets on 10.6) Using them within macports would collide with the macports philosophy not to use more of the base system than necessary. - An executable loading more than one implementation of the C++ standard library is asking for undefined behaviour. - You should not mix up different C++ standard libs in one address space, regardless of whether both are libstdc++ or not. It's the job of macports to ensure that for the C++ executables it compiles. - more and more C++ ports will start to require C++11, or at least newer C++ implementations than the the one shipped with the ubiquitous gcc 4.2.1 - currently, there might still be some ports that require g++ Thus given the theoretical possibility to provide a (the same) recent C++ runtime for (all) OSX (versions), then I'd see these questions: How many C++ ports really require something newer than gcc 4.2.1? Are they used by many macports installations? How does the estimated growth rate of these ports relate to the estimated phase out rate of older OSX installations? In short, how bad is the pain to drop the idea of C++11 on OSX 10.9? And the other way round: Down to which OSX version shall macports be responsible for providing a recent C++ runtime and how much effort should that take? I don't know macports well enough to answer these questions, but here are some guesses trying to be educated: The only C++ runtime on osx that I'd expect to have long term support is clang/libc++. Then I'd first rule out using a newer self-built g++ since that collides with the reasons to use clang/libc++, anyway. My second guess is that I'd drop the whole idea of macports providing its own C++ implementation ;-) Additionally, c++ libraries compiled by macports might be used in own non-macports software projects. This own software might also require a newer C++ implementation than the one used by macports. I don't think that macports should be responsible for this although that's something that I could well use. When I started using C++11 in my software I just used macports compiler packages and manually installed all C++ libraries I needed. Just my €0,014725 Regards, Titus ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi, - The only C++ runtime that Apple provides on all systems since 10.5(?) is the one delivered with gcc 4.2.1. I really doubt that Apple will change that to a recent libc++ You are wrong on this point. Apple have been abandoning gcc in favour of clang/LLVM over the last few OSX releases, and finished this in 10.9 which does *not* have a 'gcc' compiler at all. OSX also does have libc++. In fact, its the only C++ runtime in 10.9. On OSX Macports explicitly links using the libc++ runtime, where as on older releases it This is exactly why c++11 code is fine on OSX10.9, as the default compiler libc++ used there supports it, but not on older OSC releases. This is why the c++ issue and OSX versions are mixed up here. Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Wed, Dec 04, 2013 at 10:00:48AM +, Chris Jones wrote: In fact, its the only C++ runtime in 10.9. That's incorrect. 10.9 still has the same libstdc++ runtime that previous versions of OS X had. In fact, you can still use the old runtime (and some of our ports do, because they fail with libc++) by passing -stdlib=libstdc++ to the compiler. On OSX [Mavericks] Macports explicitly links using the libc++ runtime, where as on older releases it That's correct, because the default of the clang compiler changed in 10.9. It is also correct on trunk, because trunk explicitly adds a -stdlib=$configure.cxx_runtime flag to CXXFLAGS. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi, On Wed, Dec 04, 2013 at 10:52:28AM +0100, Titus von Boxberg wrote: maybe I got lost in this thread but I think multiple issues get mixed up. Yes, I think some things are getting mixed up here, but only because we cannot handle them separately. The available C++ runtimes are in fact determined by the OS and we're not completely independent from the OS in choosing a C++ runtime implementation for MacPorts. - The only C++ runtime that Apple provides on all systems since 10.5(?) is the one delivered with gcc 4.2.1. I really doubt that Apple will change that to a recent libc++ libc++ has been available for a while now, but was not the default. I think it was first shipped in 10.6(?), although the older versions probably have their own set of problems related to compiling C++11 code. - I don't see what the question of C++11 support and thus the c++ library version has to do with the OSX version besides, presumably, that 10.9 is the first OSX release with full (?) C++11 support in the preinstalled C++ standard library. macports provides two recent C++ implementations, clang/libc++ and FSF g++, that both work on systems earlier than 10.9 It does matter in the sense that OS X ships a number of libraries that export a C++ API. The runtime these libraries use should also be the runtime MacPorts uses for all its own stuff, because while we can avoid using them in our ports, we might not be able to stop users from using them and libraries built from MacPorts in their own software. A question that still remains is how many of the libraries shipped with OS X actually offer C++ APIs. If there's only a few minor libraries we could disregard the compatibility problem here, document that those shouldn't be used when linking against libs from MacPorts and choose a C++ runtime independent of the system-provided one. That would solve our C++11 issues, because we could either use a recent (MacPorts-provided) libc++ or a recent (MacPorts-provided) libstdc++ for C++11 support (and thus also for _all_ other ports). - I doubt but don't know whether there are any other C++ libraries in /usr/lib (besides a stone old implementation of wxWidgets on 10.6) Using them within macports would collide with the macports philosophy not to use more of the base system than necessary. Yes, but as I said, MacPorts building its own ports is not the only issue here, users trying to build their stuff is just as relevant. - An executable loading more than one implementation of the C++ standard library is asking for undefined behaviour. - You should not mix up different C++ standard libs in one address space, regardless of whether both are libstdc++ or not. It's the job of macports to ensure that for the C++ executables it compiles. That essentially means we can not support C++11 on Mountain Lion and below at the moment. We need to switch to a different C++ runtime first. - more and more C++ ports will start to require C++11, or at least newer C++ implementations than the the one shipped with the ubiquitous gcc 4.2.1 Obviously C++11 support is a problem we're going to face sooner or later. It is a problem now and I don't think just avoiding C++11 on older systems is going to cut it. - currently, there might still be some ports that require g++ Which is fine as long as they don't any C++ API (we all know that, but just as a reminder). How many C++ ports really require something newer than gcc 4.2.1? Are they used by many macports installations? How does the estimated growth rate of these ports relate to the estimated phase out rate of older OSX installations? In short, how bad is the pain to drop the idea of C++11 on OSX 10.9? And the other way round: Down to which OSX version shall macports be responsible for providing a recent C++ runtime and how much effort should that take? That's the right set of questions. Unfortunately I don't have an answer. At the moment it seems to me C++11 on systems 10.9 is going to be a feature ports (and users!) will request. If I remember correctly there have been a number of questions on how to compile C++11 code on these systems, even before we discussed the runtime mixing problem on this list. I don't know macports well enough to answer these questions, but here are some guesses trying to be educated: The only C++ runtime on osx that I'd expect to have long term support is clang/libc++. Then I'd first rule out using a newer self-built g++ since that collides with the reasons to use clang/libc++, anyway. We don't need long-term support, because it's obvious that on systems that use libc++ as default runtime we're going to use that. The question we're facing is what to do on systems that still use libstdc++ as default runtime. clang can compile against libstdc++ just fine and if we can convince it to compile against MacPorts libstdc++ that would be a viable solution, IMO. My second guess is that I'd drop the whole idea of
Re: C++11 on Mountain Lion and lower?
Am 04.12.2013 11:00, schrieb Chris Jones: Hi, On OSX Macports explicitly links using the libc++ runtime, where as on older releases it This is exactly why c++11 code is fine on OSX10.9, as the default compiler libc++ used there supports it, but not on older OSC releases. This is why the c++ issue and OSX versions are mixed up here. As said, this is where the mix up of the issues gets a bit incorrect. libc++ is available since 10.7. clang is available from Apple way before Xcode 5. It's just that the libc++ of 10.9 and clang of Xcode 5 are the first versions by Apple that have had a chance to use the clang/libc++ that has (or claims to have) full C++11 support (actually, I don't know if that's really the case since I don't have 10.9/Xcode 5). When sticking to C++03 or at most the subset of C++11 that had already been implemented when 10.7.x shipped (which most ports currently do, I think), macports should work with libc++ on the three most recent OSX versions. (However, I didn't test that assumption, so I don't know if that's really correct from 10.7 onwards.) Regards, Titus ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Wed, Dec 04, 2013 at 12:48:13PM +0100, Titus von Boxberg wrote: libc++ is available since 10.7. clang is available from Apple way before Xcode 5. It's just that the libc++ of 10.9 and clang of Xcode 5 are the first versions by Apple that have had a chance to use the clang/libc++ that has (or claims to have) full C++11 support (actually, I don't know if that's really the case since I don't have 10.9/Xcode 5). When sticking to C++03 or at most the subset of C++11 that had already been implemented when 10.7.x shipped (which most ports currently do, I think), macports should work with libc++ on the three most recent OSX versions. But if we're not going to use the default C++ runtime on these older systems anyway, we could just port a recent version of libc++ with full C++11 support and use that on these systems? That would avoid the potential brokenness of some C++11 features in libc++ on = 10.8. Or am I mistaken here? -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On 04/12/13 11:48, Titus von Boxberg wrote: Am 04.12.2013 11:00, schrieb Chris Jones: Hi, On OSX Macports explicitly links using the libc++ runtime, where as on older releases it This is exactly why c++11 code is fine on OSX10.9, as the default compiler libc++ used there supports it, but not on older OSC releases. This is why the c++ issue and OSX versions are mixed up here. As said, this is where the mix up of the issues gets a bit incorrect. libc++ is available since 10.7. clang is available from Apple way before Xcode 5. It's just that the libc++ of 10.9 and clang of Xcode 5 are the first versions by Apple that have had a chance to use the clang/libc++ that has (or claims to have) full C++11 support (actually, I don't know if that's really the case since I don't have 10.9/Xcode 5). When sticking to C++03 or at most the subset of C++11 that had already been implemented when 10.7.x shipped (which most ports currently do, I think), macports should work with libc++ on the three most recent OSX versions. (However, I didn't test that assumption, so I don't know if that's really correct from 10.7 onwards.) That though is not really a robust definition that can be used in practise I think. A compiler that only implements some parts of the C++11 standard, doesn't implement the standard. Just saying yeah, it might work, as long as upstream only happen to use the parts of the standard our compilers implement is fragile and not going to work for long. If we are going to go the the effort of getting support for c++11 on systems 10.9, the aim should be *full* support, or sooner or later the same issue will come up again. Partial support just postpones the problem. Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Dec 4, 2013, at 05:29, Clemens Lang wrote: Obviously C++11 support is a problem we're going to face sooner or later. It is a problem now and I don't think just avoiding C++11 on older systems is going to cut it. I’m not entirely opposed to that actually. There are already many ports that don’t work on older systems, for various reasons. Requiring C++11 may well be another valid reason for a port requiring a newer OS. Mavericks is a free update, supports the same hardware as Mountain Lion, and is a better OS than Mountain Lion. We should continue fixing our ports to work on Mavericks and encourage users to upgrade. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi, On 04/12/13 12:01, Ryan Schmidt wrote: On Dec 4, 2013, at 05:29, Clemens Lang wrote: Obviously C++11 support is a problem we're going to face sooner or later. It is a problem now and I don't think just avoiding C++11 on older systems is going to cut it. I’m not entirely opposed to that actually. There are already many ports that don’t work on older systems, for various reasons. Requiring C++11 may well be another valid reason for a port requiring a newer OS. Mavericks is a free update, supports the same hardware as Mountain Lion, and is a better OS than Mountain Lion. We should continue fixing our ports to work on Mavericks and encourage users to upgrade. I concur with that. For me 10.9 is just better than both 10.8 and 10.7, and for those systems upgrading is I think a bit of a no brainer. Yes, there might be a few niggles that some users dislike, but if they are serious about wanting c++11 features, they should consider it a serious option. last time I checked 10.9 adoption had exceeded both 10.8 and 10.7. 10.6 is perhaps slightly different in that it is the last release to support PowerPC applications. Maybe some users have a need to stick with this because of that (but then, any application that *still* hasn't provided an intel version now, clearly is dead in the water. Personally, I would be looking heavily for alternatives at this stage). 10.5 is the last PowerPC OS. But then, I think this is old enough that support can be just 'take what you can get'. Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Dec 4, 2013, at 06:11, Chris Jones wrote: 10.6 is perhaps slightly different in that it is the last release to support PowerPC applications. Maybe some users have a need to stick with this because of that (but then, any application that *still* hasn't provided an intel version now, clearly is dead in the water. Personally, I would be looking heavily for alternatives at this stage). There are various solutions for having the best of both worlds, from dual-booting to virtualization to just using two machines, one with Snow Leopard, one with Mavericks. 10.5 is the last PowerPC OS. But then, I think this is old enough that support can be just 'take what you can get’. It’s been very much that for awhile already. I keep a PowerPC test machine around but the issues that show up have become stranger and beyond my abilities. For example many ports blacklist the old gcc compilers on Leopard, falling back to clang instead, but clang has some problems building on Leopard, and other problems with on PowerPC. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi Clemens, all, you dropped the last text block from my mail where I said that I think that macports shouldn't care much about users using macports libraries for their own software. This is why also in your mail quoted below in my opinion these things get mixed up: you mix up users of macports executables with developers using macports libraries. Again, only as a recommendation: macports shouldn't care about this c++11 library use case (if it's not cheap, and I guess that it wouldn't be). Developers wanting to use C++11 should be using 10.9. As said, (only) on this system, using clang from xcode 5, it comes with (almost) no extra cost for macports to have the whole port set moved to a c++11 compliant runtime (which reenables C++11 developers to use the libraries compiled by macports for their own software). C++11 developers really targeting earlier systems then are on their own. And spoken from my experience, they aren't lost since macports already provides compliant implementations also for systems 10.9. I simply wouldn't spend the time to make it use them for its own purposes (that is, the executables it compiles). Basically, all this boils down to following recommendations: - tell c++11 developers to use 10.9+Xcode 5 (presumably, they will know already). - mark all ports requiring the new runtime as unavailable on systems 10.9 Some smaller comments below. Regards, Titus Am 04.12.2013 12:29, schrieb Clemens Lang: Hi, libc++ has been available for a while now, but was not the default. I think it was first shipped in 10.6(?), although the older versions probably have their own set of problems related to compiling C++11 code. - I don't see what the question of C++11 support and thus the c++ library version has to do with the OSX version besides, presumably, that 10.9 is the first OSX release with full (?) C++11 support in the preinstalled C++ standard library. macports provides two recent C++ implementations, clang/libc++ and FSF g++, that both work on systems earlier than 10.9 It does matter in the sense that OS X ships a number of libraries that export a C++ API. The runtime these libraries use should also be the runtime MacPorts uses for all its own stuff, because while we can avoid using them in our ports, we might not be able to stop users from using them and libraries built from MacPorts in their own software. A question that still remains is how many of the libraries shipped with OS X actually offer C++ APIs. If there's only a few minor libraries we could disregard the compatibility problem here, document that those shouldn't be used when linking against libs from MacPorts and choose a C++ runtime independent of the system-provided one. That would solve our C++11 issues, because we could either use a recent (MacPorts-provided) libc++ or a recent (MacPorts-provided) libstdc++ for C++11 support (and thus also for _all_ other ports). I'm using only the Darwin / POSIX subset of MacOS together with Qt or wxWdigets, so I don't know. Does OSX really offer (so many) C++ APIs? - I doubt but don't know whether there are any other C++ libraries in /usr/lib (besides a stone old implementation of wxWidgets on 10.6) Using them within macports would collide with the macports philosophy not to use more of the base system than necessary. Yes, but as I said, MacPorts building its own ports is not the only issue here, users trying to build their stuff is just as relevant. Why yes? Did you mean no? Otherwise this contradicts what you said above. Or are you intermixing C and C++? - currently, there might still be some ports that require g++ Which is fine as long as they don't any C++ API (we all know that, but just as a reminder). I really meant g++ (to compile C++). That always uses C++ API/ABIs. I didn't mean the ports that require the C (or even the FORTRAN) part of gcc. How many C++ ports really require something newer than gcc 4.2.1? Are they used by many macports installations? How does the estimated growth rate of these ports relate to the estimated phase out rate of older OSX installations? In short, how bad is the pain to drop the idea of C++11 on OSX 10.9? And the other way round: Down to which OSX version shall macports be responsible for providing a recent C++ runtime and how much effort should that take? That's the right set of questions. Unfortunately I don't have an answer. At the moment it seems to me C++11 on systems 10.9 is going to be a feature ports (and users!) will request. If I remember correctly there have been a number of questions on how to compile C++11 code on these systems, even before we discussed the runtime mixing problem on this list. I don't know macports well enough to answer these questions, but here are some guesses trying to be educated: The only C++ runtime on osx that I'd expect to have long term support is clang/libc++. Then I'd first rule out using a newer self-built g++ since that collides with the
Re: C++11 on Mountain Lion and lower?
Hi, you dropped the last text block from my mail where I said that I think that macports shouldn't care much about users using macports libraries for their own software. I very much disagree here. MacPorts is *not* just about providing a bunch of applications for users to run, but also about providing a framework within which people can develop their own private applications. This has been something MacPorts has cared about and I very much hope it stays that way. Note, this does not mean I don't agree that perhaps the best appropriate here is to declare c++11 unavailable in macports in anything less than OSX10.9. Both internally to MacPorts, for building ports, and externally to users. That might well be the best way to proceed Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Wed, Dec 04, 2013 at 02:52:02PM +0100, Titus von Boxberg wrote: you dropped the last text block from my mail where I said that I think that macports shouldn't care much about users using macports libraries for their own software. This is why also in your mail quoted below in my opinion these things get mixed up: you mix up users of macports executables with developers using macports libraries. Well, I disagree with you on this. Building libraries you need for your own software _is_ a relevant use-case for MacPorts, and I don't think we should disregard it. I wouldn't even differentiate between users of MacPorts executables and developers using libraries from MacPorts. I'd even assume most users that use the command line and MacPorts extensively *are* in fact developers. Again, only as a recommendation: macports shouldn't care about this c++11 library use case (if it's not cheap, and I guess that it wouldn't be). It's not trivial, but we haven't decided yet whether it's impossible to get right -- that's what we're discussing here. Developers wanting to use C++11 should be using 10.9. As said, (only) on this system, using clang from xcode 5, it comes with (almost) no extra cost for macports to have the whole port set moved to a c++11 compliant runtime (which reenables C++11 developers to use the libraries compiled by macports for their own software). C++11 developers really targeting earlier systems then are on their own. And spoken from my experience, they aren't lost since macports already provides compliant implementations also for systems 10.9. I simply wouldn't spend the time to make it use them for its own purposes (that is, the executables it compiles). They are lost if they need to link against a C++ library, e.g. boost compiled against a runtime that supports C++11. And these libraries are probably the reason they were trying to use MacPorts in the first place. Consider a developer who wants C++11 support on 10.8. He might find out that he can use libc++ (from MacPorts or from the host) and clang. Then he tries to use boost, tries to use the MacPorts version and experiences weird crashes, because MacPorts boost is compiled against libstdc++. Sure, we could just tell users that's unsupported, but that will only cause frustration at best. Especially if there is a way to make this work correctly. Basically, all this boils down to following recommendations: - tell c++11 developers to use 10.9+Xcode 5 (presumably, they will know already). - mark all ports requiring the new runtime as unavailable on systems 10.9 Some smaller comments below. Regards, Titus I'm using only the Darwin / POSIX subset of MacOS together with Qt or wxWdigets, so I don't know. Does OSX really offer (so many) C++ APIs? Of the system libraries in /usr/lib/system, only a single one exports C++ symbols (and that seems to be related to kernel extension stuff). I haven't checked for the libraries in /usr/lib, but I'll try to come up with a shell script to look for C++ APIs in those libraries tonight. dyld is implemented in C++, but I think it only exposes C APIs. - I doubt but don't know whether there are any other C++ libraries in /usr/lib (besides a stone old implementation of wxWidgets on 10.6) Using them within macports would collide with the macports philosophy not to use more of the base system than necessary. Yes, but as I said, MacPorts building its own ports is not the only issue here, users trying to build their stuff is just as relevant. Why yes? Did you mean no? Otherwise this contradicts what you said above. Or are you intermixing C and C++? Yes was referring to using them within MacPorts would collide with the MacPorts philosophy. - currently, there might still be some ports that require g++ Which is fine as long as they don't any C++ API (we all know that, but just as a reminder). I really meant g++ (to compile C++). That always uses C++ API/ABIs. I didn't mean the ports that require the C (or even the FORTRAN) part of gcc. Yes. Compiling with g++ (and thus using MacPorts libstdc++) is fine, if the compiled library does not expose a C++ API, isn't it? (Sorry, it seems I forgot the word expose in this sentence.) We don't need long-term support, because it's obvious that on systems that use libc++ as default runtime we're going to use that. The question we're facing is what to do on systems that still use libstdc++ as default runtime. clang can compile against libstdc++ just fine and if we can convince it to compile against MacPorts libstdc++ that would be a viable solution, IMO. Again, I don't know. But I really doubt that you could convince clang++ to offer a fully compliant C++11 implementation when using any version of libstdc++. I would try to not even think about that since it's nonstandard (at least for Apple). As said above: since libc++ is - from 10.9 onwards - the only officially supported implementation
Re: C++11 on Mountain Lion and lower?
Hi, I think we're meaning the same thing. My first sentence was misleading. In my opinion, it's not much cost (at least extra) to drop boost or another C++ lib into macports and simply have it compile (please don't beat me, in my eyes bjam is an abomination, so I really feel with the port maintainer). On the other hand, things like providing an own C++ runtime for older OSX versions would be really (too) much. And of course, I also would like to keep macports providing libraries. I'm only trying to say that shouldn't have too much extra cost (how many libs live in macports that aren't used in any of mp's executable ports, anyway?) For C++11 I abandoned this idea some two years ago. If it comes back with 10.9, fine. Regards, Titus From: Chris Jones jon...@hep.phy.cam.ac.uk Sent: Mittwoch, 4. Dezember 2013 15:18 To: Titus von Boxberg ti...@v9g.de Cc: macports-dev@lists.macosforge.org Subject: Re: C++11 on Mountain Lion and lower? Hi, you dropped the last text block from my mail where I said that I think that macports shouldn't care much about users using macports libraries for their own software. I very much disagree here. MacPorts is *not* just about providing a bunch of applications for users to run, but also about providing a framework within which people can develop their own private applications. This has been something MacPorts has cared about and I very much hope it stays that way. Note, this does not mean I don't agree that perhaps the best appropriate here is to declare c++11 unavailable in macports in anything less than OSX10.9. Both internally to MacPorts, for building ports, and externally to users. That might well be the best way to proceed Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Dec 4, 2013, at 08:46, Clemens Lang wrote: Consider a developer who wants C++11 support on 10.8. He might find out that he can use libc++ (from MacPorts or from the host) and clang. Then he tries to use boost, tries to use the MacPorts version and experiences weird crashes, because MacPorts boost is compiled against libstdc++. Actually he experiences build failures, and files https://trac.macports.org/ticket/41588 and I have to tell him that what he wants to do is not possible right now. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Am 04.12.2013 15:46, schrieb Clemens Lang: They are lost if they need to link against a C++ library, e.g. boost compiled against a runtime that supports C++11. And these libraries are probably the reason they were trying to use MacPorts in the first place. Consider a developer who wants C++11 support on 10.8. He might find out that he can use libc++ (from MacPorts or from the host) and clang. Then he tries to use boost, tries to use the MacPorts version and experiences weird crashes, because MacPorts boost is compiled against libstdc++. Sure, we could just tell users that's unsupported, but that will only cause frustration at best. Especially if there is a way to make this work correctly. You describe my use case very well. At no time have I been frustrated, even though I had to climb into my own learning curve some time ago: http://permalink.gmane.org/gmane.os.apple.macports.devel/14693 And that was only about intermixing two different libstdc++. Immediately afterwards, I decided to compile my own versions of the libs I require. And in such a case one has nicely maintained portfiles to use cmd-c/cmd-v. Lost is a hard word for that situation: In my opinion that's not too much work for a C++11 developer sticking to os versions nowadays already dying out. Again: I don't want to object or anything else if someone does find the time to get C++11 right for older OSX versions. I'm only saying: I'd expect that to be rough, and less and less nessecary due to the phase out of older OSX. (Around June 2011, my thinking would have been the opposite ;-) For a cheaper idea to keep error reports low, what about wrapping MP's g++ and clang++ in a small warning banner program? It could print a message like: do not link to macports c++ libraries with this compiler if the macports C++ runtime isn't the same as the one of the compiler being invoked. Which is fine as long as they don't any C++ API (we all know that, but just as a reminder). I really meant g++ (to compile C++). That always uses C++ API/ABIs. I didn't mean the ports that require the C (or even the FORTRAN) part of gcc. Yes. Compiling with g++ (and thus using MacPorts libstdc++) is fine, if the compiled library does not expose a C++ API, isn't it? (Sorry, it seems I forgot the word expose in this sentence.) It's OK as long as every part of the final software uses the same C++ runtime and no other ABI break is introduced (I don't know of an example). And for the reasons outlined earlier, if the decision is made to provide an own runtime with macports, I would try to make that libc++ provided by (macports) clang. So I'd recommed to drop support for ports strictly requiring g++. As far as I understood from the 10.9 discussions on the list this is currently done by macports for 10.9, anyway (just because macports has to stick to clang++ on 10.9). Regards, Titus ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
In article 529f1c08.4000...@hep.phy.cam.ac.uk, Chris Jones jon...@hep.phy.cam.ac.uk wrote: 10.6 is perhaps slightly different in that it is the last release to support PowerPC applications. Maybe some users have a need to stick with this because of that (but then, any application that *still* hasn't provided an intel version now, clearly is dead in the water. Personally, I would be looking heavily for alternatives at this stage). FTR, 10.6 is also the last release to support 32-bit-only Intel Core Solo and Core Duo based Macs. So there are users with Intel Macs who cannot migrate from Snow Leopard. -- Ned Deily, n...@acm.org ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi, On 4 Dec 2013, at 09:14 pm, Ned Deily n...@acm.org wrote: In article 529f1c08.4000...@hep.phy.cam.ac.uk, Chris Jones jon...@hep.phy.cam.ac.uk wrote: 10.6 is perhaps slightly different in that it is the last release to support PowerPC applications. Maybe some users have a need to stick with this because of that (but then, any application that *still* hasn't provided an intel version now, clearly is dead in the water. Personally, I would be looking heavily for alternatives at this stage). FTR, 10.6 is also the last release to support 32-bit-only Intel Core Solo and Core Duo based Macs. So there are users with Intel Macs who cannot migrate from Snow Leopard. Fair point, but surely a small and ever reducing user base ... Low hanging fruit need to be pruned sometime ... -- Ned Deily, n...@acm.org ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Wed, Dec 04, 2013 at 03:46:49PM +0100, Clemens Lang wrote: Of the system libraries in /usr/lib/system, only a single one exports C++ symbols (and that seems to be related to kernel extension stuff). I haven't checked for the libraries in /usr/lib, but I'll try to come up with a shell script to look for C++ APIs in those libraries tonight. dyld is implemented in C++, but I think it only exposes C APIs. I've done that and found only 4 libraries in /usr/lib export C++ APIs (tested on 10.9): - libcupsppdc.1.dylib (what is this anyway?) - libhunspell-1.2.0.0.0.dylib (present in MacPorts) - libicucore.A.dylib (present in MacPorts) - libmecab.1.0.0.dylib (only a few symbols, what is this?) So in conclusion using a C++ runtime different from the one the host system uses might be a doable solution because these are the only libraries users would have to avoid. So remaining questions: - Which C++ runtime should be used? Host libc++? A newer libc++ from MacPorts? How can clang be convinced to use that? - Do we have the manpower to pull this off and support it? To be honest, I think the last question needs to be answered with no and might kill the whole idea. At least we have some data on how dangerous it is to use trunk and change cxx_stdlib to libc++. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi, On 5 Dec 2013, at 12:22 am, Clemens Lang c...@macports.org wrote: On Wed, Dec 04, 2013 at 03:46:49PM +0100, Clemens Lang wrote: Of the system libraries in /usr/lib/system, only a single one exports C++ symbols (and that seems to be related to kernel extension stuff). I haven't checked for the libraries in /usr/lib, but I'll try to come up with a shell script to look for C++ APIs in those libraries tonight. dyld is implemented in C++, but I think it only exposes C APIs. I've done that and found only 4 libraries in /usr/lib export C++ APIs (tested on 10.9): - libcupsppdc.1.dylib (what is this anyway?) - libhunspell-1.2.0.0.0.dylib (present in MacPorts) - libicucore.A.dylib (present in MacPorts) - libmecab.1.0.0.dylib (only a few symbols, what is this?) So in conclusion using a C++ runtime different from the one the host system uses might be a doable solution because these are the only libraries users would have to avoid. So remaining questions: - Which C++ runtime should be used? Host libc++? A newer libc++ from MacPorts? How can clang be convinced to use that? - Do we have the manpower to pull this off and support it? I guess a version of libc++ from MacPorts would have the advantage it would allow the use of a complete c++11 implementation on systems where the host version is lacking. Could this be done by just making one of macports own clang compilers the default compiler... ? To be honest, I think the last question needs to be answered with no and might kill the whole idea. At least we have some data on how dangerous it is to use trunk and change cxx_stdlib to libc++. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On 2013-12-5 08:14 , Ned Deily wrote: In article 529f1c08.4000...@hep.phy.cam.ac.uk, Chris Jones jon...@hep.phy.cam.ac.uk wrote: 10.6 is perhaps slightly different in that it is the last release to support PowerPC applications. Maybe some users have a need to stick with this because of that (but then, any application that *still* hasn't provided an intel version now, clearly is dead in the water. Personally, I would be looking heavily for alternatives at this stage). FTR, 10.6 is also the last release to support 32-bit-only Intel Core Solo and Core Duo based Macs. So there are users with Intel Macs who cannot migrate from Snow Leopard. And there are machines with 64-bit processors but 32-bit EFI that can't go past 10.7. Almost every recent release drops support for something. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On 2013-12-5 11:22 , Clemens Lang wrote: - libcupsppdc.1.dylib (what is this anyway?) Something to do with the CUPS ppd compiler I would say. - libmecab.1.0.0.dylib (only a few symbols, what is this?) Looks like some version of what's provided by the mecab-base port. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Dec 4, 2013, at 20:16, Joshua Root wrote: And there are machines with 64-bit processors but 32-bit EFI that can't go past 10.7. Which machines are you thinking of? The system requirements of Mavericks are pretty liberal: http://support.apple.com/kb/ht5842 For example, the mid-2007 MacBookPro3,1, which I have, which is supported, has a 64-bit processor but under Snow Leopard boots to the 32-bit kernel. Under later OS releases my understanding is that it boots to the 64-bit kernel. Almost every recent release drops support for something. Mavericks’ system requirements are pretty darn close to Mountain Lion’s: http://support.apple.com/kb/ht5444 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Dec 4, 2013, at 18:32, Chris Jones wrote: I guess a version of libc++ from MacPorts would have the advantage it would allow the use of a complete c++11 implementation on systems where the host version is lacking. Do we know which host versions are lacking? Could this be done by just making one of macports own clang compilers the default compiler... ? No; clang (from MacPorts or Xcode or compiled by hand) will use the system’s C++ runtime, unless you tell it otherwise; same goes for llvm-gcc and Apple’s modified versions of gcc, regardless where you got them. The only compilers we have that automatically use their own C++ runtime are the FSF versions of gcc, and somehow I don’t think telling them to use a different C++ runtime would be very successful. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
C++11 on Mountain Lion and lower?
Hi, does anybody know how I can compile C++11 code on Mountain Lion and lower without using libc++? The problem I face is that rethinkdb uses std::move (and probably other features) from C++11. To do this, it checks for the clang compiler and passes -stdlib=libc++ in CXXFLAGS if it detects clang on OS X. Rethinkdb also uses protobuf-cpp, which requires linking against libprotobuf.dylib. However, libprotobuf is built against libstdc++. This leads to the following problem when rethinkdb tries to use protobuf: Error: Unable to compile sample protobuf file. Try running ./configure with the --fetch protoc option Undefined symbols for architecture x86_64: google::protobuf::MessageFactory::InternalRegisterGeneratedFile(char const*, void (*)(std::__1::basic_stringchar, std::__1::char_traitschar, std::__1::allocatorchar const)), referenced from: protobuf_AddDesc_mk_2fgen_2fprotoc_2ftest_2eproto() in test-umpU92.o google::protobuf::DescriptorPool::FindFileByName(std::__1::basic_stringchar, std::__1::char_traitschar, std::__1::allocatorchar const) const, referenced from: protobuf_AssignDesc_mk_2fgen_2fprotoc_2ftest_2eproto() in test-umpU92.o So the problem is that the linker is looking for the symbol in libprotobuf that was compiled against libc++ (see the usage of std::__1::basic_string, which is specific to libc++), but cannot find the symbol, because libprotobuf has been compiled against libstdc++. Any ideas how to fix this? Should I just pass --fetch protoc --static protoc to have rethinkdb compile a local version of protobuf? -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi, I am not an expert, but based on the discussion in https://trac.macports.org/ticket/39975 my understanding is there is no easy way to enable c++11 on systems older than 10.9 using the current MacPorts release. You need to use the libc++ runtime by default everywhere, not, libstdc++, and this is only the case on Mavericks. MacPorts base in the trunk has the option to force the use of libc++ instead of libstdc++. See comment 19 in the above. This though requires the user to, use trunk, manually edit macports.conf then rebuild all their ports. I don't know if its the plan to ever do this by default on OSX10.8 or older... Chris In 03/12/13 14:09, Clemens Lang wrote: Hi, does anybody know how I can compile C++11 code on Mountain Lion and lower without using libc++? The problem I face is that rethinkdb uses std::move (and probably other features) from C++11. To do this, it checks for the clang compiler and passes -stdlib=libc++ in CXXFLAGS if it detects clang on OS X. Rethinkdb also uses protobuf-cpp, which requires linking against libprotobuf.dylib. However, libprotobuf is built against libstdc++. This leads to the following problem when rethinkdb tries to use protobuf: Error: Unable to compile sample protobuf file. Try running ./configure with the --fetch protoc option Undefined symbols for architecture x86_64: google::protobuf::MessageFactory::InternalRegisterGeneratedFile(char const*, void (*)(std::__1::basic_stringchar, std::__1::char_traitschar, std::__1::allocatorchar const)), referenced from: protobuf_AddDesc_mk_2fgen_2fprotoc_2ftest_2eproto() in test-umpU92.o google::protobuf::DescriptorPool::FindFileByName(std::__1::basic_stringchar, std::__1::char_traitschar, std::__1::allocatorchar const) const, referenced from: protobuf_AssignDesc_mk_2fgen_2fprotoc_2ftest_2eproto() in test-umpU92.o So the problem is that the linker is looking for the symbol in libprotobuf that was compiled against libc++ (see the usage of std::__1::basic_string, which is specific to libc++), but cannot find the symbol, because libprotobuf has been compiled against libstdc++. Any ideas how to fix this? Should I just pass --fetch protoc --static protoc to have rethinkdb compile a local version of protobuf? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Tue, Dec 03, 2013 at 03:09:10PM +0100, Clemens Lang wrote: does anybody know how I can compile C++11 code on Mountain Lion and lower without using libc++? The problem I face is that rethinkdb uses std::move (and probably other features) from C++11. To do this, it checks for the clang compiler and passes -stdlib=libc++ in CXXFLAGS if it detects clang on OS X. Rethinkdb also uses protobuf-cpp, which requires linking against libprotobuf.dylib. However, libprotobuf is built against libstdc++. This leads to the following problem when rethinkdb tries to use protobuf: [...] So the problem is that the linker is looking for the symbol in libprotobuf that was compiled against libc++ (see the usage of std::__1::basic_string, which is specific to libc++), but cannot find the symbol, because libprotobuf has been compiled against libstdc++. To follow up: the ML buildbot just succeeded building rethinkdb using FSF GCC 4.8 (obviously using MacPorts libstdc++). I guess the binaries will now use both - /opt/local/lib/libstdc++.dylib and - /usr/lib/libstdc++.dylib, but I suppose that will cause a lot less problems than mixing libc++ and libstdc++. Obviously this solution should only be used for ports that do *not* export a C++ API. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi, To follow up: the ML buildbot just succeeded building rethinkdb using FSF GCC 4.8 (obviously using MacPorts libstdc++). I guess the binaries will now use both - /opt/local/lib/libstdc++.dylib and - /usr/lib/libstdc++.dylib, but I suppose that will cause a lot less problems than mixing libc++ and libstdc++. Obviously this solution should only be used for ports that do *not* export a C++ API. Is this really a good idea though. My recollection is, whilst not as bad as mixing libc++ and libstdc++ runtimes, mixing the two different libstd++ runtimes can still lead to problems…. ? Chris smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Tue, Dec 03, 2013 at 05:00:25PM +, Christopher Jones wrote: Is this really a good idea though. My recollection is, whilst not as bad as mixing libc++ and libstdc++ runtimes, mixing the two different libstd++ runtimes can still lead to problems…. ? Under the constraints we have I think its the best solution possible. Alternatives would be - Mark the port as broken on systems darwin13 :( - Build a private copy of all dependencies of rethinkdb against macports libstdc++. Since that includes boost and a couple of other rather large ports, I don't think this is a feasible solution either. - Get Apple to ship a version of libstdc++ that supports C++11 on outdated OS releases - Get Apple to make libc++ the default stdlib on all releases that have libc++ None of those sound very appealing to me. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
What about using the libcxx and libcxxabi ports for libc++? Is there any way to make that work? On Tue, Dec 3, 2013 at 1:38 PM, Clemens Lang c...@macports.org wrote: On Tue, Dec 03, 2013 at 05:00:25PM +, Christopher Jones wrote: Is this really a good idea though. My recollection is, whilst not as bad as mixing libc++ and libstdc++ runtimes, mixing the two different libstd++ runtimes can still lead to problems…. ? Under the constraints we have I think its the best solution possible. Alternatives would be - Mark the port as broken on systems darwin13 :( - Build a private copy of all dependencies of rethinkdb against macports libstdc++. Since that includes boost and a couple of other rather large ports, I don't think this is a feasible solution either. - Get Apple to ship a version of libstdc++ that supports C++11 on outdated OS releases - Get Apple to make libc++ the default stdlib on all releases that have libc++ None of those sound very appealing to me. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi, Under the constraints we have I think its the best solution possible. Alternatives would be - Mark the port as broken on systems darwin13 :( - Build a private copy of all dependencies of rethinkdb against macports libstdc++. Since that includes boost and a couple of other rather large ports, I don't think this is a feasible solution either. - Get Apple to ship a version of libstdc++ that supports C++11 on outdated OS releases - Get Apple to make libc++ the default stdlib on all releases that have libc++ None of those sound very appealing to me. For that last one, it is not necessary to have Apple make that decision. macPorts could decide to release the current trunk, and force the use of libc++ on systems older than OSX10.9. This of course would force all users to recompile all their ports, and probably is not a solution for all OSX releases, as I guess the older ones probably don’t have any runtime supporting c++11…. To be honest, if it isn’t possible to do it properly, I would go with the top one above. At least it doesn’t pretend all is OK, when it isn’t. If upstream for a given port decides they are going to use c++11 features, unconditionally, they effectively they are making that decision for us. Chris -- Clemens Lang smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Tue, Dec 03, 2013 at 01:59:35PM -0500, Eric Gallager wrote: What about using the libcxx and libcxxabi ports for libc++? Is there any way to make that work? Only if we rebuilt all ports against libcxx/libcxxabi. We could do that, but we could also just rebuild everything against the host libc++ on those systems. Both would imply users could never link against a library exporting C++ APIs provided by the host. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Tue, Dec 03, 2013 at 07:48:48PM +, Christopher Jones wrote: For that last one, it is not necessary to have Apple make that decision. macPorts could decide to release the current trunk, and force the use of libc++ on systems older than OSX10.9. This of course would force all users to recompile all their ports, and probably is not a solution for all OSX releases, as I guess the older ones probably don’t have any runtime supporting c++11…. That would still require users that want to build their own C++ software to only use C++ APIs from libraries compiled by MacPorts. Strictly no linking against any C++ APIs provided by the OS in /usr/lib/*.dylib. I'm not sure that's what we currently want. To be honest, if it isn’t possible to do it properly, I would go with the top one above. At least it doesn’t pretend all is OK, when it isn’t. If upstream for a given port decides they are going to use c++11 features, unconditionally, they effectively they are making that decision for us. I'd do that if only systems below Lion were affected, but this would mean the port doesn't work on Mountain Lion and Mavericks has just been released, so I guess the majority of our user base still is on ML. I think the FSF GCC solution involving libstdc++ from MacPorts is good enough for now, even if it is a hack. Reading the documentation on ABI compatibility for libstdc++ mentions all releases since GCC 4.3 use libstdc++.6.so (on Linux) as SONAME and should be compatible. The docs also explicitly mention they libstdc++ libraries are forward-compatible, so in theory one should always be able to substitute a libstdc++ library with a newer version. Of course, I'm not sure whether this also holds for multiple libstdc++ versions in the same address space. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi, On 3 Dec 2013, at 8:13pm, Clemens Lang c...@macports.org wrote: On Tue, Dec 03, 2013 at 07:48:48PM +, Christopher Jones wrote: For that last one, it is not necessary to have Apple make that decision. macPorts could decide to release the current trunk, and force the use of libc++ on systems older than OSX10.9. This of course would force all users to recompile all their ports, and probably is not a solution for all OSX releases, as I guess the older ones probably don’t have any runtime supporting c++11…. That would still require users that want to build their own C++ software to only use C++ APIs from libraries compiled by MacPorts. Strictly no linking against any C++ APIs provided by the OS in /usr/lib/*.dylib. I'm not sure that's what we currently want. Nope, nor do I. Just mentioning it… To be honest, if it isn’t possible to do it properly, I would go with the top one above. At least it doesn’t pretend all is OK, when it isn’t. If upstream for a given port decides they are going to use c++11 features, unconditionally, they effectively they are making that decision for us. I'd do that if only systems below Lion were affected, but this would mean the port doesn't work on Mountain Lion and Mavericks has just been released, so I guess the majority of our user base still is on ML. Oh, I agree it sucks. But still I feel this is kinda upstreams decision to make. Is this issue due to a new change in an upstream version ? Have we got in contact with the upstream devs to find out what their intentions are, and if they know this effectively rules out all OSX versions before 10.9 ? If they still insist, I am not sure we should second guess them... I think the FSF GCC solution involving libstdc++ from MacPorts is good enough for now, even if it is a hack. Reading the documentation on ABI compatibility for libstdc++ mentions all releases since GCC 4.3 use libstdc++.6.so (on Linux) as SONAME and should be compatible. The docs also explicitly mention they libstdc++ libraries are forward-compatible, so in theory one should always be able to substitute a libstdc++ library with a newer version. Of course, I'm not sure whether this also holds for multiple libstdc++ versions in the same address space. Well yes, you can drop in a newer libstdc++ as a replacement for an older one, and applications linked against the old one should still work. The issue is that last point, about an application loading *both* runtimes at the same time. That I think can cause issues and should be avoided. I guess you can check with otool -L to see if this is happening with your hack ? Chris -- Clemens Lang smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Dec 3, 2013, at 13:48, Christopher Jones wrote: For that last one, it is not necessary to have Apple make that decision. macPorts could decide to release the current trunk, and force the use of libc++ on systems older than OSX10.9. This of course would force all users to recompile all their ports, and probably is not a solution for all OSX releases, as I guess the older ones probably don’t have any runtime supporting c++11…. First we would need to write more code in base that could identify when ports are installed with a different C++ runtime than that selected in macports.conf, and rebuild those ports. Users will not know they need to rebuild ports after such a change (since no previous MacPorts release has made them do this, when not upgrading the OS), and if they don’t rebuild ports things will break. I don’t think we record in the registry what C++ runtime was used to build a port. So we might have to scan all installed files to see what C++ runtime they link with. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi, On 3 Dec 2013, at 9:55pm, Ryan Schmidt ryandes...@macports.org wrote: On Dec 3, 2013, at 13:48, Christopher Jones wrote: For that last one, it is not necessary to have Apple make that decision. macPorts could decide to release the current trunk, and force the use of libc++ on systems older than OSX10.9. This of course would force all users to recompile all their ports, and probably is not a solution for all OSX releases, as I guess the older ones probably don’t have any runtime supporting c++11…. First we would need to write more code in base that could identify when ports are installed with a different C++ runtime than that selected in macports.conf, and rebuild those ports. Users will not know they need to rebuild ports after such a change (since no previous MacPorts release has made them do this, when not upgrading the OS), and if they don’t rebuild ports things will break. I don’t think we record in the registry what C++ runtime was used to build a port. So we might have to scan all installed files to see what C++ runtime they link with. I agree, its a royal pain all round. I think now is the right time for MacPorts to decide how its going to deal with this. I guess the number of packages that require c++11 is currently small, but I think this will slowly start to change. c++11 has a number of really neat features, so I am sure upstream devs. are going to want to start to use them, over time. I certainly do in the projects I work on... Part of the problem, for me, is MacPorts insists on all OSX versions using the same set of port versions. There is no way, I think, of having different versions on different OSX releases. Note this is quite different to say the Linux world, where for instance the various Ubuntu/Fedora/Whatever distributions allow packages to update at different rates in each of their releases. If we had this possibility in MacPorts (putting assign the headache it would give maintainers) it would allow us deal with situations like this. Assuming though the above is not to going to change anytime soon, the question is how to deal with this c++11 issue. The options are either a) Find a way to allow old OSX versions to use c++11, b) don’t update any port that starts to use c++11, as long as we ‘officially’ (whatever that means these days) support OSX releases without c++11 c) declare such ports as ‘broken’ on the older OSX releases. For me, compiling with MacPorts gcc versions is not a solution along the lines of a) as it potentially mixes different libstdc++ runtimes, which is dangerous. Maybe the solution above, to force the use of libc++ on older systems (with some automatic rebuild) is a solution, but most probably it will not work on all systems, as some OSX release will not have any C++ runtimes that support c++11. Solutions b) and c) are not ideal at all. Chris smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Tue, Dec 03, 2013 at 03:55:08PM -0600, Ryan Schmidt wrote: First we would need to write more code in base that could identify when ports are installed with a different C++ runtime than that selected in macports.conf, and rebuild those ports. Users will not know they need to rebuild ports after such a change (since no previous MacPorts release has made them do this, when not upgrading the OS), and if they don’t rebuild ports things will break. I think base has some patches to do that – I turned them from errors to warnings, because this currently often happens to ports that cannot yet use the stdlib specified in the configuration and the check doesn't handle that yet, returning lots of false positives just to rebuild them three times after which they are still broken in the same way. This check should really go into a post-destroot check phase (as the one implemented in GSoC 2009 still sitting on its branch), where we could use information from the Portfiles for that. I don’t think we record in the registry what C++ runtime was used to build a port. So we might have to scan all installed files to see what C++ runtime they link with. No, we don't record that. We could easily scan all files to find the C++ runtime, but how does that help us if we don't know whether a file doesn't link against the correct runtime because it doesn't support the chosen one or not? We could find situations where multiple C++ runtimes are involved, but I suggest that's something that should be done in post-destroot, too. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
On Dec 3, 2013, at 16:23, Christopher Jones wrote: Part of the problem, for me, is MacPorts insists on all OSX versions using the same set of port versions. There is no way, I think, of having different versions on different OSX releases. Note this is quite different to say the Linux world, where for instance the various Ubuntu/Fedora/Whatever distributions allow packages to update at different rates in each of their releases. If we had this possibility in MacPorts (putting assign the headache it would give maintainers) it would allow us deal with situations like this. Portfiles are Tcl scripts. The can do most anything. Whether they should is another matter. Usually when different versions are available and needed for whatever reason (including support for specific OS versions), we make separate ports. See vineserver which is for 10.6 and newer and vineserver3 which is for 10.6 and older, or graphviz-gui which is for 10.5 and newer and graphviz-oldgui which works on any OS X version. Some ports do vary their version based on the OS X version. See cctools and ld64. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
Hi, On 3 Dec 2013, at 11:43pm, Ryan Schmidt ryandes...@macports.org wrote: On Dec 3, 2013, at 16:23, Christopher Jones wrote: Part of the problem, for me, is MacPorts insists on all OSX versions using the same set of port versions. There is no way, I think, of having different versions on different OSX releases. Note this is quite different to say the Linux world, where for instance the various Ubuntu/Fedora/Whatever distributions allow packages to update at different rates in each of their releases. If we had this possibility in MacPorts (putting assign the headache it would give maintainers) it would allow us deal with situations like this. Portfiles are Tcl scripts. The can do most anything. Whether they should is another matter. Didn’t realise it was technically possible. useful to know, thanks. Usually when different versions are available and needed for whatever reason (including support for specific OS versions), we make separate ports. See vineserver which is for 10.6 and newer and vineserver3 which is for 10.6 and older, or graphviz-gui which is for 10.5 and newer and graphviz-oldgui which works on any OS X version. The problem then of course is you force ports that depend on these different versions, to know about these different versions, and to have some way of deciding which to pick. Some ports do vary their version based on the OS X version. See cctools and ld64. This is more what I was thinking for this case. Have the port use a newer c++11 enabled version on OSX versions that support it, and a older version where they don’t. Chris smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
