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

[Michael Dickens]

On Wed, Aug 28, 2013, at 10:06 PM, Jeremy Huddleston Sequoia wrote:
> I think trying to move things over to MacPorts' libstdc++ would be a
> waste of time.  We should try to reduce the configuration space as much
> as possible (to just libc++).

OK; fine. I'm clearly out of the loop when it comes to MacPorts versus
host lib[std]c++. I do not generally write or debug code at that level;
I just use it and see how well it works or does not work.  It seems that
moving away from libstdc++ is your (the project's?) desired goal, moving
towards just libc++.  Fine; I'm OK with that. But, again with my limited
understanding, given the number of ports which require libstdc++
(Apple's or MacPorts' GCC) I don't see a good way to do the move to just
libc++ tomorrow, or even this month, or probably even this year.  I
believe that libstdc++ will have to be dealt with by MacPorts for quite
a while to come.

The MacPorts end-user, generally speaking, cares that the ports they
need/want can be installed and used as expected/desired, to not be
broken; they do not generally care which lib[std]c++ library is used.  I
see the scheme I wrote as realizable, in short order, and providing high
end-user functionality.  Maybe I'm wrong about all of these?  If not,
then I'd love to see this scheme, or something equivalent to it,
implemented sooner rather than later (by me if necessary, though I
haven't a clue how to do the changes so it will take me much longer than
others who do have a clue) and then take the time necessary to figure
out how to robustly transition to using just libc++.

> It's likely there are bugs in their asm that clang complains about
> because it is stricter.  gcc does a lot of guessing of intent on
> ambiguous asm.

Truth be told: I did not write the GNU Radio assembly code nor provide
advice regarding writing it; I've never looked at it beyond knowing that
it is compiled only iff the compiler is GCC.  I could provide a link to
the code, but GNU Radio is, unsurprisingly, GPLv3'd -- so, I'll let
anyone interested do a quick internet search for "gnu radio volk" and
look for themselves.

My original point was that, no matter how good Clang / LLVM / whatever
are compared with GCC / any other compiler out there, GNU Radio provides
optimizations for GCC only right now and using any other compiler
including Clang disables those optimizations.  You are correct that GNU
Radio is OSS and that the primary reason for not supporting Clang is
because nobody has provided patches to do so.  That's all well and good,
but it does not change the reality of the current state of GNU Radio. 
And, if I am to provide support for GNU Radio within MacPorts, then I
have to abide by reality.

That said: I would love to see the GNU Radio optimized code compiling
using Clang; maybe I'll figure out a way to convince them to pay me to
do that :)

> I'm not going to continue with a license debate.  Yes, the binaries
> produced by gcc are not infected by the viral license.  That's not what
> I'm talking about.  I am unable to look at gcc's source code in order to
> figure out what it's doing when there is a bug in gcc itself.
> It's not my decision.  I just can't look at GPLv3 code.  Many tech
> companies have the same policies for their employees.

Fair enough.  If your employer -- and at least one of them is publicly
available information BTW -- restricts you from looking at GPLv3'd code
then I can understand your frustration with pretty much anything GNU
oriented (and plenty of other projects too).  If the job with your
employer is to write compiler code, then that's doubly frustrating.

My goal in all of this is really just to better understand the
lib[std]c++ stuff, which clearly is a multi-faceted issue.  I think I'm
understanding more of that now, though I also think I have a ways to go.
- MLD