Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sun, Sep 7, 2014 at 8:36 PM, Lawrence Velázquez wrote: All this talk about keeping track of C++ runtimes and switching to libc++ is dangerous because it proposes a huge amount of work that deftly dances around the actual problem. It's not a huge amount of work. It already works. The question is about providing a buildbot with binaries. (Personally I'm not willing to keep recompiling Qt, clang and all other software just to get libc++ working.) What do you mean with dancing around the actual problem? The problem is that the default libstdc++ on 10.9 doesn't have support for C++11. (But yes, the use of GPLv3 has something to do with the issue. The version of libstdc++ that supports C++11 no longer provides a suitable licence for Apple.) Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sun, Sep 7, 2014 at 12:52 AM, Ryan Schmidt wrote: On Sep 6, 2014, at 5:51 AM, Mojca Miklavec wrote: I already argued that we really need a libc++-based buildbot for 10.6-10.8. From what I understood all we need is a fix in binary package signature + time and resources to set up the buildbots. Once the buildbots run, people can start testing and switching to libc++. Once we get to a satisfactory support, we can recommend everyone to switch and retire the libstdc++-based buildbots if needed. Switching from libstdc++ to libc++ would be equal to switching from 10.x to 10.(x+1). (Nice to automate one day, but people should switch manually for now and reinstall everything from scratch.) Anything where we're asking people to manually reinstall things is, IMHO, a niche situation. My guess is that a few very interested and involved people subscribe to the macports-users list, but that the vast majority of MacPorts users just use it and never communicate with the community. Those users should be given a smooth upgrade experience as well; they shouldn't have to seek out help to get the best MacPorts experience; it should just work. I never suggested doing dramatic changes that would *require* users to do a manual upgrade. But at least to those users that start complaining about mkvtoolnix crashing, we would have a satisfactory answer: go to this wiki page and follow instructions to switch to libc++. Switching to libc++ only means changing a single setting in macports.conf. (For better support this also means changing the binary signature depending on which libc++/libstdc++ library is being used and setting up a buildbot.) Support for libstdc++ can stay (to the extent that port maintainers will support it – same as with support for Tiger). It would be weird if we forced users to switch to a different runtime. If nothing else I bet there are users who would really want to keep using libstdc++ for various reasons (easier to compile [own] software manually etc.) and don't bother about C++11. But it would be really really nice to create a mechanism that: - remembers which ports are installed and which ones are requested - deactivates (and possibly uninstalls) all ports - installs all the ports again which could be applied in both situations: - switching to a different library or changing some other options in macports.conf (maybe change applications_dir or frameworks_dir or so) - upgrading the OS But that's not *required* to improve support for libc++ on older OSes. Do we already record the C++ runtime in the registry with each installed port? If not, we should do that, in addition to getting it into the binary filenames. And just as we do for architectures, maybe we should have an indication for software that doesn't use any C++ runtime (nocxx?). This is something that I'm not familiar with at all. I would be very grateful if some other developer would add the necessary code. I'm willing to keep testing and fixing ports ... Presumably we would (or possibly already do) record in the registry the value of configure.cxx_stdlib. But it would be nice if we would also automatically check (somehow: either as part of the install, or maybe as part of rev-upgrade) that the specified C++ library is the one that actually got used. Similarly, it would be nice if we checked that the architectures we recorded are the architectures that actually got built. The libc++-based MacPorts works well on 10.9 already for most packages. Good to know many ports have worked, but I still suspect there are many ports you either haven't tried or haven't noticed the situations where libstdc++ is still being used even though libc++ was requested. An automated check would help with this. Most definitely there are other/more problems to be expected. If we add a buildbot, it will be a lot easier to get more people to test. Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
[C++11 conversation moved to macports-dev. You can all relax now.] vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sep 7, 2014, at 4:11 AM, René J.V. Bertin rjvber...@gmail.com wrote: Debian's package generation system is very intricate and can keep track of ABI changes in shared libraries (exported symbols, really) so I'd not be amazed if it could also keep track of dependencies on C++ runtimes and the like. (Just sayin' ... :) ) All this talk about keeping track of C++ runtimes and switching to libc++ is dangerous because it proposes a huge amount of work that deftly dances around the actual problem. As I understand it, the root problem is that the libstdc++ we provide does not use the system's C++ runtime, as Apple's custom libstdc++ does. It uses its own runtime. Until our libstdc++ is ported to use libc++abi instead of libsupc++, our g++ compilers will be broken in a *very* fundamental way. Jeremy didn't do this work because he can't touch GPLv3 code. Given the recent clamor, I'm starting to look into it. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Fri, Sep 5, 2014 at 9:05 PM, Ryan Schmidt wrote: On Sep 5, 2014, at 1:45 PM, René J.V. Bertin wrote: Starting with kdevelop 4.7, C++11 is going to be required Currently, that means the port will have require OS X 10.9 and later. Support for 10.7 and 10.8 would involve moving all of MacPorts from libstdc++ to libc++ on those systems, which we have pondered before but not yet agreed to do, nor worked out how such an upgrade could be facilitated. I already argued that we really need a libc++-based buildbot for 10.6-10.8. From what I understood all we need is a fix in binary package signature + time and resources to set up the buildbots. Once the buildbots run, people can start testing and switching to libc++. Once we get to a satisfactory support, we can recommend everyone to switch and retire the libstdc++-based buildbots if needed. Switching from libstdc++ to libc++ would be equal to switching from 10.x to 10.(x+1). (Nice to automate one day, but people should switch manually for now and reinstall everything from scratch.) The libc++-based MacPorts works well on 10.9 already for most packages. Supporting libstdc++ is getting increasingly painful with more and more software depending on C++11. Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
Before I start, I should make something clear: Given that this mixed runtime problem is definitively a problem on Lion and newer, I do not think MacPorts should jump through hoops to cater to Snow Leopard. We technically do not support Snow Leopard. In a month or two, Snow Leopard will be two versions removed from our support window. On Sep 6, 2014, at 5:18 AM, René J.V. Bertin rjvber...@gmail.com wrote: From what I understand, that's valid on later OS X versions, but not (necessarily) on OS X 10.6. I should have noticed issues with other C++ applications that I built using macports-gcc-4.x in that case, too. Nope. Valid on all systems. Runtime problems were rather less likely to crop up on earlier systems because they still used libstdc++ and libsupc++ (albeit old ones), but that was more dumb luck than anything. Everything was still using different libraries, depending on which compiler had been used. Apple's move to a new runtime (libc++abi) and standard library (libc++) made the mess rather clearer. Also, I thought the GCC 4.x runtimes were supposed to be ABI compatible? Supposedly. Note that OS X's libstdc++ was an Apple-modified 4.2. Hacking alert: Par of me now wonders if I couldn't simply replace the system runtime(s) with the current MacPorts one(s) (C++ and/or libgcc_s). I suppose that has been tried? I do not know if anyone has tried that. You're welcome to volunteer for guinea pig duty. The FSF GCC ports each used to include their own runtime and support libraries (libstdc++, libgcc_s, etc.). This caused problems when, for example, a port using gcc44's libraries linked against a port using gcc45's libraries. On 10.6 or earlier already? I just wonder, this kind of situation is not at all uncommon on Linux, how come it doesn't bite there? You'd have to ask someone who uses Linux and knows how Linux package managers link up their GCCs. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sep 6, 2014, at 6:51 AM, Mojca Miklavec mojca.miklavec.li...@gmail.com wrote: I already argued that we really need a libc++-based buildbot for 10.6-10.8. From what I understood all we need is a fix in binary package signature + time and resources to set up the buildbots. Once the buildbots run, people can start testing and switching to libc++. Once we get to a satisfactory support, we can recommend everyone to switch and retire the libstdc++-based buildbots if needed. Switching from libstdc++ to libc++ would be equal to switching from 10.x to 10.(x+1). (Nice to automate one day, but people should switch manually for now and reinstall everything from scratch.) The libc++-based MacPorts works well on 10.9 already for most packages. Supporting libstdc++ is getting increasingly painful with more and more software depending on C++11. What happens if MacPorts-built software wants to link to system software that doesn't use our libc++? Does the libc++ port link to the system libc++abi? vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sat, Sep 6, 2014 at 1:10 PM, Lawrence Velázquez lar...@macports.org wrote: The FSF GCC ports each used to include their own runtime and support libraries (libstdc++, libgcc_s, etc.). This caused problems when, for example, a port using gcc44's libraries linked against a port using gcc45's libraries. On 10.6 or earlier already? I just wonder, this kind of situation is not at all uncommon on Linux, how come it doesn't bite there? You'd have to ask someone who uses Linux and knows how Linux package managers link up their GCCs. They declare one runtime and use it. The difference in our case is that on Linux the decision is made by whoever packages the system (their equivalent of us) and everything goes through one gateway, but on OS X the decision is made by Apple and package maintainers are all third parties who have to cope with Apple's choice. Additionally note that, while there is a libstdc++ that supports the new ABI and which is used on Linux and is compatible with libc++, it's GPL3 so Apple refuses to have anything to do with it. So Linux has jettisoned the old C++ runtime ABI completely, but on older OS X we have to deal with it still. Also, the way most Linux distributions handle versioning, it is possible to run old binaries if you can install the old C++ runtime library; you can't use newer libraries with it, but their versioning prevents those libraries from being considered. If you try to compile something, you'll get the new libraries including the new C++ runtime; you can't have both *compile-time* (vs. runtime) C++ runtimes installed. So everything remains consistent, but only because they control the whole ecosystem. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sat, Sep 6, 2014 at 1:21 PM, Brandon Allbery allber...@gmail.com wrote: On 10.6 or earlier already? I just wonder, this kind of situation is not at all uncommon on Linux, how come it doesn't bite there? You'd have to ask someone who uses Linux and knows how Linux package managers link up their GCCs. I should also mention that I've had to help someone on Arch Linux with a very similar issue, since Arch does a rather weird take on rolling releases and doesn't put much effort into making sure the result is internally consistent. You can also get the package manager version of this if you use Debian testing or unstable (packages that want to remove glibc, anyone?). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Saturday September 06 2014 13:10:40 Lawrence Velázquez wrote: I do not know if anyone has tried that. You're welcome to volunteer for guinea pig duty. Initial impression is that it works fine (and I found a trace of having relinked a version on 10.3 or 10.4, from a self-build gcc, though presumably a backport of an Apple gcc version). I'll know more when I've finished building the universal libgcc port variant. On 10.6 or earlier already? I just wonder, this kind of situation is not at all uncommon on Linux, how come it doesn't bite there? You'd have to ask someone who uses Linux and knows how Linux package managers link up their GCCs. Heh, I use Linux about 50% of the time nowadays. On Debian/Ubuntu, there are x86_64, i386 and x32 versions of libstdc++, and they're clearly the version belonging to the default gcc version (4.8x atm on Ubuntu 14.04). All new packages are built with that compiler, but there isn't necessarily an upgrade of ALL packages in the repositories when the compiler version is bumped ... I do not currently have a system that has seen a compiler upgrade so I cannot tell if such upgrades leave the older libstdc++ libraries around. Seems unlikely though, given that the dependencies are on libstdc++.6.so ... I think it's safe to presume that newer runtimes only add features without breaking ABI compatibility, features that are of course unused by binaries compiled with older versions of the compiler. The libc++-based MacPorts works well on 10.9 already for most packages. Supporting libstdc++ is getting increasingly painful with more and more software depending on C++11. OTOH, I just noticed that the binaries Qt5 distributes are linked against libstdc++, which I do have in /usr/lib on my 10.9 VM. A remnant of the OS upgrade, or is it still distributed by Apple, for older software? Question is then, how do Qt build their binaries? On 10.7 or 10.8? R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sat, Sep 6, 2014 at 1:37 PM, René J.V. rjvber...@gmail.com wrote: OTOH, I just noticed that the binaries Qt5 distributes are linked against libstdc++, which I do have in /usr/lib on my 10.9 VM. A remnant of the OS upgrade, or is it still distributed by Apple, for older software? Question is then, how do Qt build their binaries? On 10.7 or 10.8? I expect so, yes. And the runtime part of libstdc++ is still there so that older programs will continue to work. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sep 6, 2014, at 1:37 PM, René J.V. Bertin rjvber...@gmail.com wrote: On Debian/Ubuntu, there are x86_64, i386 and x32 versions of libstdc++, and they're clearly the version belonging to the default gcc version (4.8x atm on Ubuntu 14.04). All new packages are built with that compiler, but there isn't necessarily an upgrade of ALL packages in the repositories when the compiler version is bumped Right. We don't revbump all C++ ports after a libgcc update either. I think it's safe to presume that newer runtimes only add features without breaking ABI compatibility, features that are of course unused by binaries compiled with older versions of the compiler. This doesn't mean that it's okay to have multiple runtimes in the same address space, even if they're all libstdc++. This is the core issue. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Saturday September 06 2014 13:10:40 Lawrence Velázquez wrote: Hacking alert: Par of me now wonders if I couldn't simply replace the system runtime(s) with the current MacPorts one(s) (C++ and/or libgcc_s). I suppose that has been tried? I do not know if anyone has tried that. You're welcome to volunteer for guinea pig duty. Well, it works. It took almost 3.5 hours to build libgcc+universal, and that of course only gave me an x86 universal binary. So I had to do lipo /usr/lib/libstdc++.6.0.9.dylib -thin ppc7400 -output libstdc++.6.0.9.dylib lipo /opt/local/lib/libstdc++.6.dylib -thin i386 -output libstdc++.6.0.20.i386.dylib lipo /opt/local/lib/libstdc++.6.dylib -thin x86_64 -output libstdc++.6.0.20.x64.dylib sudo lipo -create libstdc++.6.0.* -output /usr/lib/libstdc++-mp.6.dylib sudo ln -s libstdc++-mp.6.dylib /usr/lib/libstdc++.6.dylib It's a bit of a miracle, but apparently it's allowed to mix and match library versions in a single universal binary like that, and Rosetta clearly doesn't mind (my old Illustrator CS copy ran fine with the new libstdc++). I presume it might be possible to build a ppc variant of libgcc as well, but if so that would bump the build time to over 4.5 hours, which is really disproportionate. Who decides whether or not a universal variant binary port is made available via the buildbots? O:-) R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sep 6, 2014, at 7:15 AM, René J.V. Bertin wrote: If moving to libc++ also aids upgrading MacPorts after upgrading the OS, that just gives an additional reason ... I don't see why it would do anything like that. Upgrading the OS to a new major version always requires reinstalling MacPorts and all ports, as explained in the wiki Migration page. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sep 6, 2014, at 4:18 AM, René J.V. Bertin wrote: On Friday September 05 2014 22:41:42 Lawrence Velázquez wrote: Judging from your comments, your crashes are probably caused because you're mixing up C++ runtime libraries. Binaries compiled with MacPorts' gcc48 use libgcc's libraries. Binaries compiled with Xcode's compiler will use the system libraries. If these binaries try to exchange objects in any fashion, you'll have trouble. From what I understand, that's valid on later OS X versions, but not (necessarily) on OS X 10.6. [...] On all OS X versions. The only difference is that in OS X 10.9 the system library changed from libstdc++ to libc++. However, Apple's libstdc++ is not identical to libgcc's libstdc++, so yes, mixing libgcc's and the system's libraries can cause problems on any version of OS X. The FSF GCC ports each used to include their own runtime and support libraries (libstdc++, libgcc_s, etc.). This caused problems when, for example, a port using gcc44's libraries linked against a port using gcc45's libraries. On 10.6 or earlier already? [...] On all OS X versions. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sat, Sep 6, 2014 at 6:52 PM, Ryan Schmidt ryandes...@macports.org wrote: Do we already record the C++ runtime in the registry with each installed port? If not, we should do that, in addition to getting it into the binary filenames. And just as we do for architectures, maybe we should have an indication for software that doesn't use any C++ runtime (nocxx?). Right up until something can use a plugin built against C++, since that would only show up at runtime if it's dlopen()ed. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Friday September 05 2014 18:36:08 René J.V. Bertin wrote: On Friday September 05 2014 11:23:45 Lawrence Velázquez wrote: Re: libcxx port and using it ... I had to finagle out that the only way to get -stdlib=libc++ into the compile options was to use configure.cxx_stdlib on the commandline (instead of sticking -stdlib=libc++ into configure.optflags). Starting with kdevelop 4.7, C++11 is going to be required, meaning that on OS X 10.6 the port will either have to be compiled with MacPorts gcc, or with MacPorts clang with port:libcxx as a build dependency. What would be the best way to get the required compiler flags set from within the Portfile, probably including the -I flag with a clang-specific path so it'll find the C++11 headers? R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sep 5, 2014, at 1:45 PM, René J.V. Bertin rjvber...@gmail.com wrote: Starting with kdevelop 4.7, C++11 is going to be required Currently, that means the port will have require OS X 10.9 and later. Support for 10.7 and 10.8 would involve moving all of MacPorts from libstdc++ to libc++ on those systems, which we have pondered before but not yet agreed to do, nor worked out how such an upgrade could be facilitated. Support for 10.6 would involve that plus the use of the libcxx port. Support for 10.4 and 10.5 would not be available. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Friday September 05 2014 14:05:15 Ryan Schmidt wrote: Starting with kdevelop 4.7, C++11 is going to be required Currently, that means the port will have require OS X 10.9 and later. Support for 10.7 and 10.8 would involve moving all of MacPorts from libstdc++ to libc++ on those systems, which we have pondered before but not yet agreed to do, nor worked out how such an upgrade could be facilitated. Support for 10.6 would involve that plus the use of the libcxx port. Support for 10.4 and 10.5 would not be available. Bummer. So I noticed. Building with C++11 and libcxx using clang worked well enough, but of course it crashes soon enough because the rest of KDE and Qt are not built the same way. So that leaves macports-gcc-4.8 and higher ... I wonder if some of the crashes I've seen are due to using an outdated C++ runtime; sadly it's quite difficult to get proper backtraces, at least from optimised code, not even using port:gdb (Apple's own gdb tends to crash on kdevelop-git; Xcode 4's lldb just quits). Maybe I should just consider getting on with getting over the idea of just keeping a 10.6.8 VM for the few PPC apps I still use ... :-/ R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)
On Sep 5, 2014, at 4:54 PM, René J.V. Bertin rjvber...@gmail.com wrote: So that leaves macports-gcc-4.8 and higher ... I wonder if some of the crashes I've seen are due to using an outdated C++ runtime; Judging from your comments, your crashes are probably caused because you're mixing up C++ runtime libraries. Binaries compiled with MacPorts' gcc48 use libgcc's libraries. Binaries compiled with Xcode's compiler will use the system libraries. If these binaries try to exchange objects in any fashion, you'll have trouble. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
