On Wed, Aug 28, 2013, at 01:48 PM, Jeremy Huddleston Sequoia wrote:
> On Aug 28, 2013, at 9:58, Michael Dickens <michae...@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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
