c++ library usage

[Michael Dickens]

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.