Alternatives to Buildroot for Native Compilation and Testing?

[Jeffrey Walton]

On Fri, Mar 1, 2013 at 5:23 AM, Florian Fainelli <florian at openwrt.org> 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?

Jeff