Stallman on GCC, LLVM, and copyleft [LWN.net]

Stallman on GCC, LLVM, and copyleft

Posted Jan 29, 2014 19:23 UTC (Wed) by PaXTeam (guest, #24616)
In reply to: Stallman on GCC, LLVM, and copyleft by Del-
Parent article: Stallman on GCC, LLVM, and copyleft

> Sorry, I am still in the dark [...]

that's about the only statement you got right ;).

> Please avoid the ad hominems.

not before you learn to follow your own advice.

> Yes I said stable APIs are the back-bone of successful open projects, and I mean it.

so according to you linux and gcc are not successful.

> Linux has a rock stable API

wrong. the kernel's API has nothing to do with the syscall interface it provides to userland. the former is for kernel code, modules included, not userland and is intentionally not stable.

> Breaking backwards compatibility is typically seen as a bug.

linux does it all the time. please submit your bugreport to lkml. we all need a good laugh every now and then after all ;).

> When it comes to linux drivers, we are not talking about an API, but about an ABI.

wrong. you don't have a clue what these words mean, do you ;).

> It is somewhat different,

they're not somewhat different, but very different things. they refer to different levels of abstraction.

> but as I said, there is not supposed to be an API for external use there.

this sentence makes no sense whatsoever.

> People are expected to include the drivers as part of the distribution.

what does being in-tree vs. out-of-tree even have to do with the kernel API?

> This is different.

what is different?

> Talking about GCC, it does make sense to share what you mean with API.

are you saying that you didn't understand nix's response about said API? why did you even respond then? besides trolling, that is. and i did point you at said API, you can read the code or references to the code in that header.

> For most people I believe they are occupied by linking issues,

wrong, the API is not about 'linking issues'.

> which in the case of C++ refers to the ABI implemented by GCC

wrong, the gcc API that nix talked about has nothing to do with any C++ or other ABI. but then you already knew that difference, didn't you? ;)

> In the case of nix, I can of course guess that it is a reference to the newer plugin API

there's no gcc plugin API. there're a few plugin specific functions to register callbacks but other than that all public gcc symbols are available for plugin (ab)use. and this interface (functions and data structures, macros, etc) is not stable at all as you can see from my feeble attempt.

> By now I should have checked of course, but maybe you can share with me, is this the API you are struggling with?

i'm not the one struggling here with anything ;).

> I haven't worked with that API myself,

then on what grounds did you react to nix's statement?

> but I have seen GCC developers being sorry for not having it more stable.
> Whether they are just being modest, or whether they really have broken the API
> numerous times I don't know, and to be frank, I do not find you line of posting
> very helpful in conveying it either.

that's because you don't understand anything about this whole programming business yet it seemingly doesn't prevent you from posting nonsense after nonsense. you're still back at square one: figure out what API means, figure out what it is in the gcc world (never mind linux and others) and then figure out how stable they are and why. so do your homework before you spread your stupid claims about API stability.

> You see, the example from Octave using LLVM as a JIT library, is AFAIK, and intended usage of LLVM by an external project,
> and then whether the API is stable or not is a rather important issue, at least for me.

i can't imagine how anything programming related could be important for you ;). as for the API exposed by LLVM, it's the same deal as with gcc, all public symbols are there to take (over 40k of them at last count) and there're changes in there every day.

> I may of course be wrong, that Octave's usage was never intended for external usage of LLVM, so that we are more talking about an internal API, which in my mind is a different ball game.

what is LLVM's internal API? and what is 'external usage of LLVM'? and how's this 'external usage' different from LLVM's internal API?

to post comments

Stallman on GCC, LLVM, and copyleft

Posted Jan 29, 2014 21:20 UTC (Wed) by Del- (guest, #72641) [Link] (1 responses)

> wrong. the kernel's API has nothing to do with the syscall interface it provides to userland. the former is for kernel code, modules included, not userland and is intentionally not stable.

"The kernel user-space API is the API that allows programs in user space to access system resources and services of the Linux kernel. This API, by choice, never breaks."
ref. http://en.wikipedia.org/wiki/Linux_kernel_API#Kernel_user...

> wrong, the gcc API that nix talked about has nothing to do with any C++ or other ABI.

For GCC the APIs most people are interested in are in the libs. I showed the ABI part, but there is also an API for C++ too of course, here you are: http://gcc.gnu.org/onlinedocs/libstdc++/api.html
I find the ABI story of C++ in GCC more fascinating, that's all.
A part from that I can only think of the plugin API I already gave you. Does even GCC define an internal API? AFAIK, internal APIs are typically not stable, so not sure how relevant they are for this discussion at all. The starting point for this discussion was usage of LLVM by external projects. So no, I have no clue as to what GCC API you go on about.

You'd better run along and edit wikipedia though, my patience with you is up.

Stallman on GCC, LLVM, and copyleft

Posted Jan 29, 2014 22:36 UTC (Wed) by PaXTeam (guest, #24616) [Link]

> The kernel user-space API

that's the *userland* API (syscalls), and not the kernel's API (which is used by kernel code, including modules, both in-tree or out-of-tree). which part of it is not clear to you? ;)

> For GCC the APIs most people are interested in are in the libs.

irrelevant, you were not biching about this kind of API regarding LLVM either, so don't try to change the subject. and the C++ ABI (i bet you don't know what that is either) was irrelevant here as well, noone was discussing it.

> Does even GCC define an internal API?

what is an 'internal API'? what makes it 'internal'?

> AFAIK, internal APIs are typically not stable, so not sure how relevant they are for this discussion at all.

because you were bitching about the unstable nature of the same kind of 'internal API' of LLVM as something bad. you can't have it both ways, that's what everyone's been trying to explain to you.

> The starting point for this discussion was usage of LLVM by external projects.

no it wasn't. rather it started with you making this claim:

> This sounds incredibly stupid. Stable API's is the back-bone of any successful open project.

and you were shown counter-examples (all GPL projects btw) and you still didn't recognize how idiotic your claim is. in other words, you were trolling and i'm having great fun at exposing it ;).

> So no, I have no clue as to what GCC API you go on about.

that's because you don't know what an API is. go educate yourself, it'd be a much better use of your time than trolling.

Stallman on GCC, LLVM, and copyleft

Posted Jan 30, 2014 0:17 UTC (Thu) by nix (subscriber, #2304) [Link]

and i did point you at said API, you can read the code or references to the code in that header

Oh, if only that was all plugins had to conform to. Keeping them working would be simple! :)