Host Versus MacPorts lib[std]c++ [was: Re: Fortran recipe]

[Michael Dickens]

I think the "Fortran Recipe" is pretty well programmed now, and it is
easily tweakable for specific port's needs.  So, I'm changing the
subject to lib[std]c++ since that is still a real issue.  From the
thread below, I have an issue and wonder how folks think it could be
resolved.

The latest version of gnuradio (devel or next; the 3.7.1 release is
imminent) contains a fix which allows those ports to compile using
MacPorts GCC (C / C++, not Fortran). When I use
configure.compiler=macports-gcc-4.X, the resulting gnuradio binaries
(libraries and executables) link with MacPorts' libstdc++ while, by
default (without setting the compiler suite globally), all of gnuradio's
dependencies use Apple's clang or llvm and hence link with the host
libstdc++. In this setup, most of gnuradio's "make test" fails (for more
info see, e.g., <
http://stackoverflow.com/questions/4697859/mac-os-x-and-static-boost-libs-stdstring-fail
>).  If I rebuild, as it turns out, just boost and cppunit using the
same MacPorts GCC (or, it probably could be different since they now use
the common libgcc/libstdc++), "make test" now works.  Interestingly: If
I revert back to the original boost and cppunit (using Apple's
libstdc++), and use "install_name_tool" to change the version of
libstdc++ in the already-installed libboost* and libcppunit* to
MacPorts' libstdc++, then everything works again -- this is probably not
a generic solution to the issue, but it is curious that it works.

Compiling gnuradio with GCC48 results in better executing code than with
GCC4X (X <= 4; using GCC48 is best right now), including Apple's GCC
compilers.  gnuradio does not currently make use of clang for optimizing
assembly code, so all clang compilers are blacklisted.  Hence, I would
love to be able to use GCC48 as the default compiler for gnuradio.  But, 

I can create tests (e.g., in gnuradio's CMake script, or even in the
gnuradio Portfile) to check for the "multi-libstdc++" condition and
provide feedback to the user ("You need to rebuild boost and cppunit
..."), but is there a way for port to do the work automatically -- sort
of like "enforce variants" except more along the lines of "enforce
compiler suite"?  Somehow, I don't think so just yet.  I think this is
one reason why all of the various +gcc4X options were added to various
ports (e.g., fftw-3, atlas, lapack, octave), along with using the for
Fortran.

I value your thoughts. - MLD

On Sun, Aug 25, 2013, at 09:07 PM, Jeremy Huddleston Sequoia wrote:
> On Aug 25, 2013, at 13:53, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
> > On 25 Aug 2013, at 7:22pm, Christoph Deil <Deil.Christoph at gmail.com> wrote:
> >> On Aug 25, 2013, at 10:44 AM, Mojca Miklavec <mojca at macports.org> wrote:
> >>> On Sun, Aug 25, 2013 at 5:16 PM, Jeremy Huddleston Sequoia wrote:
> >>>> Seeing as how many developers don't understand the problems surrounding mixing multiple versions of the C++ runtime in a single process, I doubt that users understand those problems.  I think the root port needs to be simplified significantly.
> >>>> 
> >>>> Does root use any C++ APIs exposed by the host or other ports?  Does root expose any C++ APIs?
> >>> 
> >>> I don't understand much about those problems either.
> >> 
> >> I also don't understand the issues, or how to debug / check them.
> >> 
> >> I am using a non-public gamma-ray astronomy data analysis package built on top of ROOT.
> >> After a lot of trial and error I did get it to compile with Macports gcc, I never managed to compile it with Apple gcc or (Apple or Macports) clang.
> >> So at least I can write code and check that it compiles on my Mac  … actually running the software sometimes works and sometimes mysteriously crashes.
> >> 
> >> Probably this is a very specialised use case, if the Macports GCC variants are removed from the ROOT port I'll just build ROOT from source myself, no problem if that is the right thing to do to avoid "C++ runtime mix errors" (whatever that means).
> > 
> > The issue is in essence the gcc compilers use one c++ runtime library (libstdc++), the other compiles, clang etc. use another (libc++). 
> 
> That's not exactly correct.  There are three runtimes we are concerned
> with: host libstdc++, host libc++, and MacPorts libstdc++ (libgcc port)
> 
> Here's the breakdown:
> 
> gcc-*            : host libstdc++
> *llvm-gcc-4.2    : host libstdc++
> apple-gcc-*      : host libstdc++
> macports-gcc-*   : MP libstdc++
> dragonegg-*      : MP libstdc++
> clang < 163      : host libstdc++
> clang >= 163     : host libstdc++ or host libc++
> macports-clang-* : host libstdc++ or host libc++
> 
> > Mixing these is a bad idea, so if you where to compile root using gcc, you should in theory compile *all* ports that that uses with it as well. This is not done. Maybe the crashes you refer to are to do with this …
> > 
> > Removing the gcc variants is thus a good idea to avoid this. I have a version under test which does this, uses the fortran recipe JH posted earlier in this thread, and fixes the cocoa variant by selecting the compiler in a better way. 
> 
> This solves the primary issue of mixing the MP runtime and the host
> runtime.  We will still need to deal with host libc++ vs host libstdc++,
> but those problems are much more obvious (build failure).
> 
> > Note that for those users that *really* want to use gcc, they will always be able to do something like
> > 
> >> sudo port install root configure.compiler=macports-gcc-4.8
> > 
> > So all is not lost, but by doing so you are accepting whatever the consequences might be.
> 
> And such expert users might want to set configure.compiler globally after
> they first bootstrap it.