Alternatives to Buildroot for Native Compilation and Testing?

[Florian Fainelli]

On 03/01/2013 02:48 PM, Jeffrey Walton wrote:
> 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?

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