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

[Jeremy Huddleston Sequoia]

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

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

Yes.  We support what the Portfiles do.  We do not support users who go off and decide to set configure.compiler to whatever they want.  We support the configuration as it is provided.  If the port uses gcc46, then we support gcc46 being used for *THAT* port, not some other port.

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

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

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.

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

Valid inline asm will compile fine with both gcc and clang.  I've seen many ports report errors when building inline asm with clang, and in almost every case, it was a bug in the assembly.  There are a couple of issues with clang's MMX, but that's a compiler bug and not a language issue.

If the code *is* asm, then it's passed straight through to the assembler anyways.

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

That's true in general for compiler to compiler and is not specific to asm.  clang is much stricter than gcc, and switching to it has found tons of project bugs which gcc missed.

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

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.

--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/18401238/attachment-0001.p7s>