Rebuild of the Debian archive with clang

http://clang.debian.net/

by yungchin • 14 years ago

175 54 14 years ago

clang.debian.net

lysium• 14 years ago

Looks like the most comprehensive list of differences between clang and gcc. I'm amazed.

Apparently, most differences are either because clang and gcc use different standards or interpret them differently.

Also, only 9% of the Debian packages have issues, meaning clang is getting more and more worth considering.

valisystem• 14 years ago

If you put basic standard compliance aside, it also strips down the errors from arguable code to horrifying coding practice.

http://clang.debian.net/status.php?version=3.0&key=VARIA...

http://clang.debian.net/status.php?version=3.0&key=NON-P...

newman314• 14 years ago

What could be nice is if the error pages could suggest possible fixes for the errors that have "will never support". Might be helpful to guide bug-fixers (esp. ones that are starting out).

aidenn02• 14 years ago

Really I never got the argument for disallowing variable-length arrays at the end of a C structure. I completely agree with disallowing non-PoD variable-length arrays as well as variable-length arrays in the middle of a structure though.

frownie2• 14 years ago

However this doesn't proove that clang produce error-free (was afar the compiklation goes) executables.

frownie2• 14 years ago

Opps, type : : "(as far as the compilation goes)"

stingraycharles2• 14 years ago

No one can ever prove such a thing. Neither can it be proven that gcc or any compiler for that matter produces error-free executables. What this does, however, is providing information and analysis about the quality of the clang compilation process as compared to gcc.

ars• 14 years ago

No can prove it, but at least the GCC version are actually run by people - these version and created, but never actually used.

He should do some fuzz testing of these programs, with the exact same fuzz sent to the GCC versions, and then report any differences. But collecting the "results" would be hard - it's not always visible in output, you'd have to track system calls and IO.

iso8859-1• 14 years ago

It can be proven, see CompCert C compiler: http://compcert.inria.fr/compcert-C.html.

abc_lisper• 14 years ago

Doesn't Apple use clang for OS X? If it does, that's as good a validation as any for me.

gtufano• 14 years ago

Another (IMHO better) validation is that FreeBSD compiles the kernel with clang: http://wiki.freebsd.org/BuildingFreeBSDWithClang

smackfu• 14 years ago

Isn't most of their code in Objective C? Does that use clang too?

InclinedPlane• 14 years ago

And? Nobody expects that gcc, or intel's reference compilers, or Microsoft's compilers produce provably correct output.

How could they? The C standard contains ambiguity in several areas.

tomdeakin• 14 years ago

Would be really interested to see what caused those segfaults! But the link in the table just goes to the table.

nitrogen• 14 years ago

Here's one from one of the logs (http://clang.debian.net/logs/2012-01-12/libgtkada2_2.14.2-5_...):

  Building libgtkada.so.2.14.2
  cd obj-shared; x86_64-linux-gnu-gcc -shared -fPIC -Wl,--as-needed \
  	  -o libgtkada.so.2.14.2 -Wl,-soname,libgtkada.so.2.14.2 glib*.o gdk*.o \
  	  gtk*.o pango*.o misc.o misc_broken.o -lgtk-x11-2.0 -lgdk-x11-2.0 \
  	  -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 \
  	  -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype \
  	  -lfontconfig -lgobject-2.0 -lgmodule-2.0 \
  	  -lgthread-2.0 -lrt -lglib-2.0   -lgnat -lX11
  Segmentation fault

In this case it looks like the compiler is crashing when invoking the linker (I'm assuming that x86_64-linux-gnu-gcc has been aliased to clang).

The others: http://clang.debian.net/status.php?version=3.0&key=SEG_F...

rbanffy3• 14 years ago

This is seriously amazing and will, certainly, improve all the codebases involved. Sylvestre and the others involved deserve a lot of good karma for this.

Going a step further, wouldn't it be great if all packages had automated tests that could easily be run on the 91% of the packages that were successfully built?

sylvestre2• 14 years ago

Thanks. I appreciate ! :)

rbanffy3• 14 years ago

Thank you.

unwind2• 14 years ago

Amazing list.

I was frustrated that I didn't manage to figure out how to locate the results for a given package, if there were any.

Without that, how should I (as a package upstream owner) know if I need to fix my code, or at least analyze the results with respect to my particular package?

maxerickson• 14 years ago

The build logs are all together:

http://clang.debian.net/logs/2012-01-12/

(I guess the ones with a 'b' appended are for clang)

unwind2• 14 years ago

Fantastic, just what I was after. Thanks a lot!

And phew, my package was not listed. :)

viraptor3• 14 years ago

If there was even an easy way to get involved in OpenSource development in general - this is it. It's pretty much a list of trivial 1-line bugs to fix!

sylvestre2• 14 years ago

And I will be happy to help contributors in this task!

udp• 14 years ago

And patches to generate, mailing lists to find and emails to write. If only every open source project were on GitHub.

viraptor3• 14 years ago

That's also something I meant by getting involved in open source. I'm sure for some projects you'll have to figure out its local rules, sometimes maybe even explain to the developers what's clang, why the change is required to support it and why they should care. It's the whole experience, not only code change ;)

lhnn• 14 years ago

Why is everyone itching to get off of GCC? Or is it all just posturing, to get GCC to work harder now that it has competition?

getsat• 14 years ago

GCC is becoming larger and more unmaintainable with each release. Competition in this space has been pretty sorely lacking for quite some time. The OpenBSD folks are also pushing PCC as a GCC alternative.

It'll be nice to have a BSD-licenced GCC equivalent for distribution with FreeBSD/OpenBSD, too.

Clang also has REALLY great error messages compared to GCC. It will tell you exactly where you forgot a comma, semicolon, quote, etc. instead of randomly pointing to some line around the error in question.

cliffbean2• 14 years ago

It is useful to keep in mind a common confusion.

Apple and various BSD's stopped updating GCC around version 4.2, the last GPLv2 version, which is approximately 4 years old now. For people who only develop on those platforms, this is what "GCC" means. So when someone from Apple or someone with an obvious BSD bias talks about how much better clang is than "GCC", they're usually talking about how much better clang is than an old unmaintained version of GCC.

clang does have strengths, but when we make comparisons, we should be clear about what it is we're comparing.

gillianseed2• 14 years ago

Well Clang/LLVM is also becoming larger with each release. As for GCC becoming more 'unmaintainable', can you point me to anything supporting that notion? It's certainly not unmaintainable now as proven by them regularly releasing new improved versions which serve as the de facto compiler toolchain for open source systems.

Also when speaking of GCC and how old and full of cruft it is, you need to realize that it's code base is being continously improved with each new release with a strong focus on modularity. It's not the same codebase as it was back in 1987.

I'm very happy Clang/LLVM exists and progressing at a great pace as I see increased availability of open source compiler toolchains as something awesome. Also LLVM really does have some great features like the best-in-class error reporting and it also serves an undeniable purpose as a jit framework for numerous projects.

That said I don't understand those trying to push the idea of GCC being obsolete (unless they are nurturing some political/licence based crusade) as it's a very mature compiler toolchain targeting a large number of architectures and (atleast for me) quite importantly generating faster code than Clang/LLVM.

Also the notion that companies would be afraid of GCC strikes me as odd given that we have Red Hat, IBM, Google, CodeSourcery, Suse etc employing full-time GCC developers.

I hope to see these compiler toolchains continously going neck to neck in the future and thus provide the open source ecosystem with two first class options each with their respective strenghts.

falling• 14 years ago

sane error messages are worth the switch alone.

nas• 14 years ago

Even if everyone doesn't switch, having more than one widely used open-source C compiler would be healthy. If anything, it allows some non-portable code to be found and fixed. Also, competition is healthy. The different compiler developers can choose to focus on specific areas of improvement (e.g. compile speed vs executable speed) rather than a one-size-fits-all approach.

gillianseed2• 14 years ago

Fully agreed, having two open source, free compiler toolchains with which you can fully build your software stack beats having to rely on just one. And like you said competition is always good. Of course that is why it's better if both compilers continue to flourish, which is what I'm hoping/expecting will be the case.

lambda• 14 years ago

This kind of work is valuable even without getting rid of GCC. Each compiler has a slightly different implementation of warnings; getting the code to compile under two compilers can find issues that you wouldn't find under just one compiler.

It also increases flexibility for developers. Perhaps I prefer to use Clang for its better error messages, or because I find it easier to target at a new platform that I'm working on. If the code already runs under Clang, then that's work I don't have to do. Clang can also be used as an independent parser more easily for GCC, so tools that use it to generate code browsing information or the like benefit from the code already being parseable with Clang.

Compiling under another compiler will also catch more of the cases in which you're depending on non-portable behavior or extensions, which increases the likelihood that you will be able to run it under static analyzers like Coverity, Clang Analyzer, Klee, Splint, or the like.

Basically, beyond wanting to move away from GCC, there is real value in putting work into making sure that everything compiles under another compiler. It's like making sure your web site works on multiple browsers; it can help you catch errors earlier, allow people to use better debugging tools, widen your audience, and help future-proof you.

Now, there are some people who are itching to get away from GCC. For one thing, it is a bigger, older, wartier project, that is harder to work with. People find Clang and LLVM more modular and extensible. For another, there are some companies that are deathly afraid of the GPLv3, and won't touch anything to do with it (Apple in particular, as well as some other embedded device manufacturers I believe). But there are many reasons for wanting to make sure that your software compiles under Clang, and not all of them mean that you want to ditch GCC, just that Clang provides additional value as well.

Rebuild of the Debian archive with clang

Related Stories