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

[Michael Dickens]

On Wed, Aug 28, 2013, at 06:06 PM, Jeremy Huddleston Sequoia wrote:
> 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
> > ...
> > 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).

What you wrote is what I meant to write. Maybe I did not succeed? 
Moving from MacPorts' libstdc++ (which is newer) -back- to Apple's
libstdc++ (which is older) did not work; hence, no backwards
compatibility from newer to older.

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

Ah; OK; well then. So MacPorts -officially- supports just whatever
compiles Apple provides for the given OS.  MacPorts' GCC, Clang, LLVM,
and so forth are not officially supported, and may or not work.  I'm
glad that's clarified (at least with me); I thought that in ports that
provided variants for +gcc4X, the MacPorts' GCC was actually supported.

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

My thought is to do an internal post-destroot that looks over all of the
files, and for those that are binaries (libraries, executables) it
checks for Apple's libstdc++ and if found does an "install_name_tool
-change" to use MacPorts' version instead.  This solution should be
relatively simple to implement, and, as you wrote above (and, I think we
are in agreement on) MacPorts' libstdc++ can be used to replace Apple's
libstdc++ (just not the other way around).  We'd need to add a
post-install hook for "port" for existing installations, but that should
also be relatively simple to implement.  I'm not saying I'm 100%
thinking this is the right way to go, but it is an interesting idea that
might be worth testing to see if it really works -- and, potentially a
short-term solution to this whole "which c++ library do we use?" issue
while a better long-term solution is determined.  In this manner, any
compiler can be used.

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

Whatever assembly the GR programmers hand-coded, they made sure it works
with GCC; not clang or any other compiler.  I do not know if there is
such a thing as "GCC-style" but it sounded good; maybe all assembly
these days is cross compiler compatible?  In my programming experience
over the last 30+ years, assembly language programming is very compiler
specific; so, I highly doubt that assembly written with GCC in mind
compiles cleanly using clang  -- though I'd love to be proven wrong. 
This is not to say that it's not possible to write assembly for both GCC
and clang, but rather that, in general, if one tests with GCC only, then
the resulting code is likely to not compile cleanly for other compilers.

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

That doesn't help (me) very much.  I read and use GPL (v2, v3) code
daily, and I don't feel like I'm tainted.  While the GPL is meant to be
hyper-viral (anything that touches that code becomes GPL'd to the same
degree), the reality is that folks (like me) read through such code
regularly, get great ideas, and then write their own code to replicate
the idea with augmentation.  In this manner, the original GPL'd code was
never copied or used verbatim, and hence has no jurisdiction.  The (US)
courts are also undecided on how viral the GPL is; so, there's room for
interpretation and leniency/forgiveness.  Further, GCC's license
provides an exception to the GPL such that the programmer can assign
his/her own license to both the source and binary code for a project; it
allows alternative compilers used in conjunction with GCC, and
alternative linkers and assemblers; it is quite lenient, basically not
permitting non-GPL'd plugins (or, that's how I read it).  So, assigning
priority for issues relating to GCC should be the same as any other
prioritization (unless you're actually modifying GCC code). Or am I
mis-understanding what you wrote? - MLD