pan-users
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]