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

[Michael Dickens]

On Wed, Aug 28, 2013, at 01:48 PM, Jeremy Huddleston Sequoia wrote:
> On Aug 28, 2013, at 9:58, Michael Dickens <michaelld at macports.org> wrote:
> > 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.
> 
> That makes sense as well, for the same reason.  The issue is the runtime
> being used.  MP's libstdc++ is binary compatible with the host libstdc++
> runtime, so you just forced everything in your process to use MP's rather
> than the host's.  Going the other way (having your app use the host's)
> might work if it doesn't use any newer features from the newer libstdc++,
> but there's certainly no guarantee.

I tried setting all of the relevant binaries to use
/usr/lib/libstdc++.6.dylib, then "make test" failed with the same result
for C++ binaries, e.g. via a Python import:
{{{
ImportError:
dlopen(/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/gnuradio-runtime/python/gnuradio/gr/../../../swig/_runtime_swig.so,
2): Symbol not found: __ZNSt16invalid_argumentD1Ev
  Referenced from: /opt/local/lib/libgnuradio-runtime.3.8git.dylib
  Expected in: /usr/lib/libstdc++.6.dylib
  in /opt/local/lib/libgnuradio-runtime.3.8git.dylib
}}}
Looking at the "nm -a" output for this symbol:
MacPorts
{{{
T __ZNSt16invalid_argumentC1ERKSs
T __ZNSt16invalid_argumentC2ERKSs
T __ZNSt16invalid_argumentD0Ev
T __ZNSt16invalid_argumentD1Ev
T __ZNSt16invalid_argumentD2Ev
T __ZSt24__throw_invalid_argumentPKc
S __ZTISt16invalid_argument
S __ZTSSt16invalid_argument
S __ZTVSt16invalid_argument
}}}
Apple:
{{{
T __ZNSt16invalid_argumentC1ERKSs
T __ZNSt16invalid_argumentC2ERKSs
t __ZNSt16invalid_argumentD0Ev
t __ZNSt16invalid_argumentD1Ev
t __ZNSt16invalid_argumentD2Ev
T __ZSt24__throw_invalid_argumentPKc
D __ZTISt16invalid_argument
S __ZTSSt16invalid_argument
D __ZTVSt16invalid_argument
}}}
So, there are differences. Hmmm .... probably just not backward
compatible, which is not a big surprise.

> > 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
> > ..."),
> 
> I'd rather not do that.  I'd prefer to get the best experience for users
> without having a port suggest they go and do something that's not really
> supported.

Recompiling using "configure.compiler=macports-gcc-4.7" is supported;
this message would tell users to do that. I'd rather not do it either;
it was sort of like the WARNING I added a bit ago that folks hated. Not
a good user experience, I know, but it got folks' attention.

> My goal here is to try and get all ports off of libsdtc++ as provided by
> libgcc.  It should be there for users of the gcc compilers, but ports
> should cooperate with eachother well, and to do that, we need a single
> C++ runtime.

So ... we need to get Apple's libstdc++ updated to a newer version? 
Seems unlikely. Seems like a better arrangement that all MacPorts ports
using C++ use the MacPorts-provided libstdc++, no matter the
configure.compiler setting.

> Yes, I understand that some of these cases are for "newer faster better",
> and that made sense when Apple was stuck on GPL-2 gcc-4.2 and llvm was
> still maturing, but on Lion+, we have a very mature version of clang
> provided by Xcode 4.6, and Tiger through Snow Leopard intel users can use
> macports-clang-3.3 if they want a mature compiler that is compatible with
> the host.

The "behind the scenes" issue is that GNU Radio is a formal GNU project,
which means it is owned by the FSF and (hence) is optimized to use GCC. 
It can use Clang optimizations only via Orc, at least right now.  I
still hope that "the GNU Radio powers that be" decide to pursue Clang /
LLVM optimizations, but that is out of my control. AVX optimizations
require a compatible assembler, and all assembly is GCC-style.

> Yet another reason to not use the gcc ports is the assembler.  They are
> using the legacy asembler from cctools which does not support AVX. 
> llvm-based compilers (including dragonegg if using the
> integrated-as.specs) use the newer assembler.  One option is to have the
> gccXX ports use 'clang -c -x assembler' instead of as, but that requires
> someone who isn't afraid of GPL3 cooties to fix (or if nobody does, I'll
> have to write a bash script wrapper which is probably sub-ideal).
> 
> See https://trac.macports.org/ticket/37846#comment:6

I had wondered about the assembler, whether Clang/llVM used a more
modern one. I'll have to try your "AS='clang -c -x assembler'" and see
if it works.

Can you expound on "afraid of GPL3 cooties"?  I'm curious what you're
getting at. - MLD