Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clang and FSF's strategy

gcc.gnu.org

Post reply on HN
Print view View original

41–50 of 143 posts

Re: Clang and FSF's strategy

#41

Post by Shamanmuni »

bjourne wrote: post #30
Shamanmuni wrote: post #23

Earlier quoted context omitted.

There's a reply to esr by Alexandre Oliva which touches this point. I'll quote what he says: "That GCC plugin interface is not sufficiently stable for major uncoordinated developments by third-parties is just as true as that Linux's module interface is constantly changing, and complaints about its lack of stability in it are often responded with such phrases as contribute your driver and we'll even help you keep it u…

I believe he is talking about different kind of plugins. For example, suppose you are an editor and you want to syntax highlight c source code. You could then feed .c files to clang, get back a parsed ast and use that for awesome syntax highlighting. You can not do that with gcc and the fsf does explicitly not want you to be able to. Because you could then be writing a non-free editor to take advantage of and using g…

Oh, I think you are right, esr was talking about using GCC as a plugin and I understood plugins for GCC. Apparently Alexandre Oliva and many of us made the same mistake.

Considering that, I mostly agree with David Kastrup; it doesn't make sense for the FSF to bend its principles and help propietary software in order to get market-share. But, unfortunately, it's also affecting FOSS developers.

Re: Clang and FSF's strategy

#42

Post by coldcode »

vonbladet wrote: post #39
Devid2014 wrote: post #28

IMHO GCC has already lost this batle. Today one developer can create incredible tools using Clang/LLVM coda-base and release it as open-source or if he wants as closed source. This is just impossible with GCC. GCC is just a compiler but Clang is much more as this is a very powerful compiler building library... If we talk about C++ then Clang already support C++14 but GCC still not. And yes License matters, GPL just d…

> Today one developer can create incredible tools using Clang/LLVM coda-base and release it as open-source or if he wants as closed source. This is just impossible with GCC. By design. > And yes License matters, GPL just does not allow to use GCC in most cases. By design.

At that rate GCC will eventually die in obsolescence. By design, apparently.

Re: Clang and FSF's strategy

#43

Post by pdw »

dalke wrote: post #32
e12e wrote: post #26

As other's have noted, GCC has a plugin system (and not a [edit:stable] external interface) -- so that extensions/tools (plugins) will have to link to GCC, and be covered by the GPL. This is similar to how the Linux kernel tries to limit binary drivers, by explicitly not having a stable ABI (although, in the case of the Linux kernel I think it is also a case of "we don't want the burden of maintaining an outdated, in…

As one of the commenters points out, Intel continues to develop a proprietary compiler. I think that's a better example than Apple for this case. In general, the world is more than just C/C++. IBM dominates the enterprise COBOL market. (See http://www.itworldcanada.com/article/most-wanted-the-elusive... .) And there are several commercial Fortran compilers besides Intel, including that of NAG (Numerical Algorithms Gr…

Proprietary C compilers are also alive and well in the embedded world.

Re: Clang and FSF's strategy

#44

Post by oddevan »

vadiml wrote: post #34
e12e wrote: post #26

As other's have noted, GCC has a plugin system (and not a [edit:stable] external interface) -- so that extensions/tools (plugins) will have to link to GCC, and be covered by the GPL. This is similar to how the Linux kernel tries to limit binary drivers, by explicitly not having a stable ABI (although, in the case of the Linux kernel I think it is also a case of "we don't want the burden of maintaining an outdated, in…

Xcode is clang based

And used GCC before that.

Re: Clang and FSF's strategy

#45

Post by pmelendez »

e12e wrote: post #26

As other's have noted, GCC has a plugin system (and not a [edit:stable] external interface) -- so that extensions/tools (plugins) will have to link to GCC, and be covered by the GPL. This is similar to how the Linux kernel tries to limit binary drivers, by explicitly not having a stable ABI (although, in the case of the Linux kernel I think it is also a case of "we don't want the burden of maintaining an outdated, in…

>"proved wrong by Apple's Xcode? "

As far as I know, Xcode is not an compiler, it's an IDE that uses LLVM/Clang underneath as primary option but also gcc if it is your choice. In the same way, Visual Studio uses cl.exe underneath but it can be hooked up with Clang too.

Re: Clang and FSF's strategy

#46

Post by justincormack »

teddyh wrote: post #40

I wrote this six months ago: If people switch from GCC to Clang/LLVM in enough numbers that Apple think they can get away with it, Apple will, in a heartbeat, close the development of Clang/LLVM and make all new versions proprietary. ( https://news.ycombinator.com/item?id=6146066 ) This is still true, and this is the reason we cannot allow GCC to give up or declare “victory” and move on.

Why would anyone use a closed fork of llvm? The open one would continue as normal without Apple.

Re: Clang and FSF's strategy

#47

Post by teddyh »

justincormack wrote: post #46
teddyh wrote: post #40

I wrote this six months ago: If people switch from GCC to Clang/LLVM in enough numbers that Apple think they can get away with it, Apple will, in a heartbeat, close the development of Clang/LLVM and make all new versions proprietary. ( https://news.ycombinator.com/item?id=6146066 ) This is still true, and this is the reason we cannot allow GCC to give up or declare “victory” and move on.

Why would anyone use a closed fork of llvm? The open one would continue as normal without Apple.

The open one would stagnate without the developers who Apple pays to out-compete then both GCC and the free fork of LLVM.

Re: Clang and FSF's strategy

#48

Post by pjmlp »

teddyh wrote: post #40

I wrote this six months ago: If people switch from GCC to Clang/LLVM in enough numbers that Apple think they can get away with it, Apple will, in a heartbeat, close the development of Clang/LLVM and make all new versions proprietary. ( https://news.ycombinator.com/item?id=6146066 ) This is still true, and this is the reason we cannot allow GCC to give up or declare “victory” and move on.

Lets not forget the private war Steve Jobs had on FSF for being forced to release the NeXT Objective-C frontend to gcc, if I remember the events correctly.

Re: Clang and FSF's strategy

#49

Post by [deleted] »

ja30278 wrote: post #31

I found the counter-argument made in the first reply to be more compelling. http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html Whether you agree with the FSF or not, their whole existence stems from their beliefs about software freedom. If they compromise their principles in exchange for 'market share', then they quite literally have no purpose.

[deleted]

Re: Clang and FSF's strategy

#50

Post by jordigh »

dded wrote: post #38
dalke wrote: post #32

Earlier quoted context omitted.

As one of the commenters points out, Intel continues to develop a proprietary compiler. I think that's a better example than Apple for this case. In general, the world is more than just C/C++. IBM dominates the enterprise COBOL market. (See http://www.itworldcanada.com/article/most-wanted-the-elusive... .) And there are several commercial Fortran compilers besides Intel, including that of NAG (Numerical Algorithms Gr…

I'm not part of the Ada world, so I don't actually know, but I thought the important Ada compiler(s) were also proprietary.

Ada is one of the poster children for early GPL success:

https://en.wikipedia.org/wiki/GNAT#History

They also sell GPL exceptions, which I think is a good thing:

https://news.ycombinator.com/item?id=7027926

Post reply on HN