[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] Weird bug with gcc-5.2's libstdc++ (sort of solved)
From: |
Duncan |
Subject: |
Re: [Pan-users] Weird bug with gcc-5.2's libstdc++ (sort of solved) |
Date: |
Wed, 9 Sep 2015 09:21:36 +0000 (UTC) |
User-agent: |
Pan/0.140 (Chocolate Salty Balls; GIT af87825) |
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.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman