On 03/01/2013 02:48 PM, Jeffrey Walton wrote:
On Fri, Mar 1, 2013 at 5:23 AM, Florian Fainelli <[email protected]> wrote:
Hello,
On 02/28/2013 10:17 PM, Jeffrey Walton wrote:
Hi All,
Are there any alternatives for testing uClibc on the native platform?
I don't need a complete embedded system (which is what Buildroot
appears to provide). In addition, Buildroot does not provide the
compiler I want to use.
Buildroot also builds the toolchain if asked for, or you can use a project
which is dedicated to building a toolchain such as crosstool-ng for
instance.
Lack of familiarity is hindering me. All I want to do is:
make CC=clang <other CFLAGS>
make test
What are the alternatives for building? My apologies for my ignorance.
I do not think clang can build uClibc right now,
Yes, it looks like you are right (not questioning you, agreeing with you).
__atribute__((align)) is causing me problems. It appears Clang claims
to be GNUC 4/GCC 4.2.1 (cf, $ clang -dM -E -x c /dev/null | grep -i
gnuc), but its missing Function and Variable attribute support. ("Work
around for compiler error parsing 'aligned' attribute? (Bug 11071)?",
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-February/028280.html).
if you want to actually
patch uClibc so it builds with it, I would welcome that.
Absolutely. We are more than happy to give back anything we have.
The embtoolkit project has announced very recently support for clang-based
toolchains for user-space applications [1], although they explicitly
mention uClibc was built using gcc.
Clang is a very important tool for me (and my kind) since it appears
to have the most advanced static and dynamic analysis capabilities.
Clang 3.3 is very impressive with its -fsanitize=XXX features. For
example, -fsanitize=memory provides dmalloc like checking without any
extra steps (just a compilation flag).
I've encountered similar compile problems with Intel's ICPC (C++
compiler). ICPC would botch 2 compilation units (2 of about 75) which
would cause a link error. I would delete the 2 *.o files produced by
ICPC, recompile them with GCC (G++), and then perform the final link.
I might try the same trick with Clang - compile what I can with Clang
and then use GCC for the gaps.
Modifying the compiler is well above my paygrade, and I probably won't
entertain the idea.
Can you think of any other tricks for uClibc/Clang?
The Linux kernel has some pretty decent low-level compiler abstraction
in linux/compiler.h, I would definitively use that as a starting base to
abstract out all the compiler specifics that is currently being used in
uClibc (such as replacing various __attribute__ annotations with a
pre-processor definition of it).
Besides that, I think you will have to go through the painful process of
building, analyzing the error and fixing it until it builds fine, and
hopefully run fine too.
Good luck!
--
Florian
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
