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

[Jeremy Huddleston Sequoia]

On Aug 28, 2013, at 13:19, Michael Dickens <michaelld at macports.org> wrote:

> 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
> ...
> So, there are differences. Hmmm .... probably just not backward
> compatible, which is not a big surprise.


No, libstdc++ *is* backwards compatible (MP's libstdc++ can be used as a replacement for the host's).  libstdc++ is not *forward* compatible (the host's libstdc++ cannot be used as a replacement for MP's).

> 
>>> 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;

No, it *may work*, but it is not supported (a ticket filed will be closed as invalid) ... just like MacPorts *may work* on Leopard and Tiger, but it's not supported.

> So ... we need to get Apple's libstdc++ updated to a newer version? 

No, that's not going to happen.

> Seems unlikely. Seems like a better arrangement that all MacPorts ports
> using C++ use the MacPorts-provided libstdc++, no matter the
> configure.compiler setting.

Choosing libstdc++ would force us to abandon Apple's compiler, and I (and I'm sure many others) would have to choose to either fork or stop using MacPorts.

If we're going to choose to migrate to a different C++ runtime, it will be the host's libc++, not MP's libstdc++.  Snow Leopard users can get a "host" libc++ from the libcxx port.

>> 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.

It's OSS.  The reason that it doesn't support clang as well isn't because it's a GNU project, it's because nobody has provided them patches to do so.  There's no GNU conspiracy to prevent their projects from working with clang.  It's just that most GNU developers use gcc and thus don't notice bugs not found by gcc nor do they know about semantics for different platforms or toolchains.

I'm not sure what you mean by "all assembly is GCC-style" ... perhaps you mean it's not darwin compatible, but AFAIK, there is no "GCC-style" for assembly.  Please point me to what you are referring to.

>> 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

I cannot taint myself by reading GPLv3 code.  It makes triaging issues with gcc "interesting"...

--Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130828/2c00f56c/attachment.p7s>