Comment by e12e | Hacker News Reader

Comment by e12e | Hacker News Reader

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, inferior ABI for the sake your proprietary crap -- share or GTFO (And it's easier for everyone if we can just see your code, bugs and all)").

However, isn't this paragraph:

"I also think it bears noticing that nobody outside of Microsoft seems to particularly want to write proprietary compilers any more. GCC won its war; the cost and time-to-market advantages of hooking into open-source toolchains are now so widely understood that new processor designs support them as a matter of course."

proved wrong by Apple's Xcode? Isn't that exactly what Aplle is (partially) doing? I know Apple makes great contributions to (among other projects, clang) -- but is upstream clang the same as what comes with Xcode?

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 Group) and PGI (The Portland Group).

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

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

But a lot of them use GCC, too. Atmel, for example.

As far as I know the LLVM tools (and it's not just clang there are others as well like clang-analyzer and lldb) that come with XCode are just binaries of the open source project. If there are any differences I haven't noticed them and I've built and used LLVM tools from source builds as well as Apple's binaries.

Since Apple has so much influence over the project they can simply get the changes they want into the project so that diminishes their need for their own changes.

The things they want to hold back almost entirely go into XCode's IDE. For instance XCode's IDE has a very nice visualization for the clang-analyzer. The visualization is just using the output from the open source analyzer. You can even replace the clang-analyzer with a newer version and use it from XCode. By keeping the visualization implementation in XCode itself they can maintain an advantage for their platform.

I'd say that this just proves his point since Apple has chosen not to produce a proprietary compiler and instead to contribute to LLVM.

>"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.

I don't think it's your choice what you hook underneath Xcode. I think it's Apple's choice. Since Xcode is non-free, you can't modify it to use something else will-nilly.

All of the fancy static analysis that Xcode does is completely tied to clang, for example. Its debugger front-end is tied to lldb's idiosyncratic interface. It's not something that you can just easily replace with non-Apple compilers.

Those are merely features of the IDE. The compiler used for actual building is configurable per project.

>"Its debugger front-end is tied to lldb's idiosyncratic interface. It's not something that you can just easily replace with non-Apple compilers."

What I going to say might not be true any more, since the last time I worked on Xcode was roughly two years ago. But by then I worked as a mobile game developer and at the studio we happily compiled in both GCC and LLVM. Actually we preferred to use gcc and gdb since LLVM debugger was very buggy at that time.

This is how you could install gcc to work with XCode 4.3

http://stackoverflow.com/questions/9353444/how-to-use-instal...

And I wouldn't call LLVM/Clang an Apple's compiler, since it is contributed by people from Google too.

> And I wouldn't call LLVM/Clang an Apple's compiler, since it is contributed by people from Google too.

It's about as much of an Apple compiler as gcc is an FSF compiler.

  All of the fancy static analysis that Xcode does is completely tied to clang, for example.

Xcode doesn't do static analysis; Clang/LLVM does, and it's perfectly possible to do it from the command line, or embed it in other tools. (This is an example of the difference between LLVM's modular library architecture and GCC plugins — LLVM doesn't insist on being ‘on top’.)

So it is easily replaceable? You could easily tell xcode to use gcc if gcc supported the same kind of static analysis? How would you do this?

I don't work for Apple and have never seen Xcode source, but my guess (based on what I would do) would be that Xcode invokes Clang/LLVM as libraries rather than a standalone binary, in order to keep persistent state. In principle GCC could present such an interface, but in practice FSF policies prevent it. The point is that the static analysis can be used directly or by other tools (there is a web interface, for instance); it is not restricted to Xcode.

So... it's not apparently possible without modifying the source code. So like I said originally, what Xcode is using for static analysis is apparently Apple's choice, not yours nor mine.

Yes; what's the point? Nobody's making you use Xcode (I don't), and nobody's stopping you using the Clang/LLVM features like static analysis outside of Xcode. If you want, you're free to call clang's static analysis from GNUstep's Xcode clone¹ (assuming GNUstep's license allows that; LLVM's certainly does), or any other IDE or editor.

¹https://github.com/gnustep/gnustep-xcode

Yes it's replaceable. I've used it with newer builds from the open source project. They even provide binaries and instructions: http://clang-analyzer.llvm.org/xcode.html

If by replaceable you mean using some other analyzer, I'd say it's not easily replaceable but if you can produce an analyzer that produces similar output and that's has the same options, then sure. clang in fact did that sort of thing with their gcc driver.

If GCC supported that (and if Xcode supported GCC's support of it), you'd probably tell Xcode to use it the same way you tell Xcode to build with GCC instead of clang: You'd select the option in your project settings.

Nobody's made the claim that Xcode is some kind of magical dynamic IDE that supports arbitrary hypothetical features of arbitrary hypothetical versions of arbitrary compilers that you can mix and match on the fly.

Nevertheless it is the case that Xcode allows you to select between clang and GCC 4.2 backends.

GCC support in XCode has been less and less GCC and more and more just the LLVM cleverly disguised as GCC. With XCode5 there is nothing left from the actual GCC project, even gdb has been entirely replaced with lldb. So now if you chose GCC in XCode you're not really using GCC at all.

All true, but that makes Xcode a proprietary IDE, not a proprietary compiler. Apple doesn't make a proprietary compiler.

Why not just write the license in such a way that linking against the stable ABI requires your code to also be GPL licensed?

Is there a legal reason why the requirement can only apply to the original source code and not the compiled source code? Don't the "proprietary binary" people exert some kind of license over their proprietary binaries?

And why can't the Linux Kernel have a versioned ABI? I don't know enough about it, but does it really get revised that often and by that much? I mean, Apple and Microsoft seem to be able to make this work, and everyone seems to think they aren't very capable compared to the Linux Kernel crew. The argument about "having to support old things" also doesn't seem to hold water, because one of the big reasons people use Open Source software is to leverage older, outdated hardware or to have access to older, outdated software and data that the proprietary vendors leave behind.

> Why not just write the license in such a way that linking against the stable ABI requires your code to also be GPL licensed?

Well, for one thing, its dubious than ABI's are copyrightable (for much the same reasons as that is true for API's, see Oracle v. Google), so work derived from an existing products ABI quite likely doesn't need a copyright license, so therefore is unlikely to be effectively restrictable by way of a gratuitous copyright license.

Xcode is clang based

And used GCC before that.

Reply on news.ycombinator.com