Re: [Pan-users] Weird bug with gcc-5.2's libstdc++ (sort of solved)

[walt]

On Wed, 9 Sep 2015 09:21:36 +0000 (UTC)
Duncan <address@hidden> wrote:

> walt posted on Tue, 08 Sep 2015 13:22:29 -0700 as excerpted:
> 
> > I'm curious about clang versus gcc.  I notice that projects like
> > mesa use clang/llvm (I think) because it compiles faster than gcc
> > (?) or maybe because they can't use gcc to generate code in real
> > time(?).  
> 
> In mesa's case, use of llvm instead of gcc is down to licensing and 
> modular flexibility.
> 
> Technically, mesa uses llvm to compile shader source-code down to 
> binaries that will be loaded onto the graphics processor and directly 
> executed by its shader pipelines, which are simple programmable 
> processors all their own, and these are the programs they run.  
> (Alternatively and as you've no doubt read, due to their massive 
> parallelization, they're being exploited to run simple but massively 
> parallel non-graphics programs as well.)  And technically, gcc could
> be used instead.
> 
> But mesa, as the rest of X, has an extremely strong tradition of
> using the MIT license, an open-source license without the copy-left
> provisions of the GPL.  From memory it's legally much like 3-clause
> BSD but even simpler and shorter.  Companies like Apple (and the
> proprietary Unixes in their time) liked it since it allowed them to
> freely mix and match proprietary closed source in with the MIT
> licensed base, unlike the GPL and other licenses of various copyleft
> strength.
> 
> And llvm/clang has similar MIT/BSD style licensing (tho the specific
> llvm license appears to be VoI-NCSA), so it can be directly
> integrated into mesa without severely restricting people's
> distribution of binary-only modules. (Indeed, that lack of
> restriction is why Apple has been a major llvm sponsor, as they tried
> some time ago to go proprietary with gcc's objective-c modules and
> Stallman pulled license on them, requiring them to free their gcc
> plugin code, but they've been wanting off of gcc ever since and ship
> a very old and stale gcc without any of the new gplv3 code in it,
> since gplv3 is even worse for them than gplv2.)  But while gcc could
> be used, the combined license would be gpl, which is anathema to many
> of the X/mesa users.
> 
> Additionally, by deliberate design, gcc doesn't tend to be as
> flexibly modular, as Stallman had never allowed it (tho I believe the
> restrictions have loosened a bit recently), viewing that flexibility
> as a danger since it would allow proprietary software providers to
> more easily subvert it to their will, introducing modules less
> clearly and directly linked with the gcc core, which they could then
> argue are not derived code, thus weakening the legal argument for
> forcing them to open their modules.  As a result, while gcc is
> arguably more mature and at least in theory slightly more efficient,
> it'd likely be much harder to adapt to the shader-vm-code-compiler
> end that mesa needed.  So even in the absence of the license issue,
> it's quite possible that the better modular flexibility of llvm would
> favor it over the less flexible gcc.
> 
> For the same modular-flexibility reasons, you're likely to see llvm
> used in various other cases where a VM code compiler is useful,
> because it's simply easier to integrate parts of, without taking the
> whole thing.  Of course for software freedom lovers that's a
> two-edged-sword, since some of those projects are likely to be
> proprietary, given that the llvm license doesn't restrict that like
> the gcc license does.  As a result, from what I've read, gcc has
> loosened up its technical plugins restrictions and become somewhat
> more modular as well, but of course it's not going to compromise on
> the license side at least until Stallman exits the picture entirely
> if ever, and being an older and more mature compiler, there's a lot
> more code there and it was originally written to discourage modular
> flexibility, so it's likely to remain for some time more complex to
> integrate even when the license allows, despite it being easier now
> than it was in the 3.x and early 4.x period.
> 
> Meanwhile, FWIW, my own opinion strongly favors copyleft in general
> (as should be obvious from my sig), but even the FSF admits there's
> times when non-copy-left but still free licenses like
> MIT/3-clause-BSD/Apache are preferred, namely, for reference code
> implementations of standards- target specifications where proprietary
> use of the same standard simply strengthens it for all users.  Think
> the various Internet RFCs and Standards.  And such a standard is
> exactly what the MIT-licensed narrower X ecosystem (including mesa
> but not for instance all X-based apps) is, the X standard and
> extensions, with xorg and mesa being the community- based/reference
> implementation, at this point with enough history behind it that I
> don't expect even Stallman objects /too/ much to mesa's choice of
> llvm over gcc, in ordered to not restrict the customary MIT license
> as using gcc would do due to its GPLv3 license.

Very interesting.  I never considered licensing as a driver for llvm.
Now I'm wondering about mir (from ubuntu) and wayland as replacements
for X.  I'd heard that those projects are driven by the need for
something simpler and faster than X, but now you've got me wondering
about licensing, too.