Understood and agreed, Mojca. Again: It seems like keeping track of the std c++ lib could be done by port & would have utility (mostly for developers, but still). It would certainly beat adding compiler variants to all C++ ports to get the c++ lib correct for dependents (as I did for my test for GR). No, I don't expect this to happen overnight; it's a process, but it's one that will keep popping up here and there (as per this email). It's good to get confirmation that it's not just me, too :) Thx! - MLD
On Wed, Jun 21, 2017, at 09:52 AM, Mojca Miklavec wrote: > On 21 June 2017 at 03:48, Michael Dickens wrote: > > Hi MP devs - A hopefully brief discussion of / query about c++ library > > usage, with a little background. What I describe below works for me, > > which makes me wonder if what I'm doing is nonstandard use of 'port' or > > what's going on ... > > > > GNU Radio devs were asked whether GR compiles using GCC7 cleanly, so I > > decided to give it a try on my macOS setup (10.12 most recent of > > everything running on a MacBook Pro Retina Touchpad; standard MacPorts > > install from GIT). Installing GCC7 was pretty simple, but of course GR > > didn't link because some of its dependencies were not built using > > libstdc++ from libgcc-devel, so the C++ library wasn't correct & mixing > > C++ libraries doesn't generally work anyway. > > > > Adding some temporary code to the Portfiles of those dependencies > > allowed me to install them with compiler variants, which did the trick & > > GR built cleanly & even passes "make test". The dependencies also work, > > even though they are linked to libgcc-devel's libstdc++; they do not use > > libc++ -- directly or indirectly from the look of it. Thus, I was able > > to pretty quickly report back that GR is, or will be shortly when I get > > some pull requests in place, compatible with GCC7. There are plenty of > > deprecation warnings, but we can ignore those for now. > > > > The above got me thinking about c++ library linking and usage, because > > this isn't the first time I've run into this issue: I want to install a > > port using clang4.0 or GCC7 & then need to go through & rebuild specific > > dependencies using the same compiler / c++ library. Seems like in 'port' > > we could provide information as to whether the port uses c++, and if so > > keep information as to which c++ library was used for linking (e.g.): > > xcode libc++, xcode libstdc++, MacPorts libc++, MacPorts libstdc++. > > Then, when someone does something "stupid" like what I try to do way too > > often, port can tell them so & ask if they really want to go through > > with this & then offer to rebuild the c++ dependencies using the desired > > compiler. It seems like offering compiler variants, while useful for > > testing, isn't the most practical except on specific ports (e.g.: atlas, > > scipy, numpy, openblas, octave, arpack, itsol, qrupdate). GR requires > > just 5 dependent ports to be rebuilt (boost, cppunit, log4cpp, scipy, > > uhd). > > > > This also got me wondering why libc++ is required for macOS 10.12, or > > maybe that I'm missing something in the way libstdc++ (via libgcc-devel) > > is built or used? If I can successfully install and use libstdc++ as the > > primary linked-to c++ library, then is it a legit way to install > > c++-based projects? is this maybe just libgcc-devel, not libgcc? Am I > > just missing something? > > The problem is that all dependencies with C++ API need to be built > against the same stdlib (which is something you figured out already). > > And running the default compiler outside of MacPorts will link against > libc++. And a number of software would not even compile with gcc (when > using some Apple frameworks etc.). > > Supporting one default variant is challenging enough. Supporting > multiple configurations (Apple's stdlibc++ 2, libc++, gcc's libstdc++ > 3, gcc's libstdc++ 3 that's not using C++11 to make it possible to > link against stdlibc++, ...) and then all the zillion workarounds to > make dependencies somehow work is basically a mission impossible, so > MP is trying to at least somewhat take care of one reasonable default > (potentially two by partially supporting libc++ on older systems). > > Linking against gcc's libstdc++ is not an option for default > configuration. > > But I totally agree that it would be nice if: > - MacPorts would store the compiler and stdlib being used for each > individual binary archive > - it was possible to force recompilation of dependencies with another > compiler/stdlib (and then switch back to the default one) > - it was slightly easier to switch the system compiler/stdlib (in > particur switching to the latest gcc on 10.5 for example) > - we had official support for libc++ on older systems (including > binary archives) > > That requires some work though and I don't see it really likely that > someone would go and implement all of that. We were not even able to > carry out the last point yet.
