Re: Dietlibc + tcc

> I can imagine that... There is some pretty gcc-specific code in there.
> You'll have a hard time trying to compile it with anything else.

That's bad. Sane libraries should work with sane compilers ;)
(GCC 4.5.1 is _awfully_ slow here; tcc compiles at 0.8 c)
I just thought tcc compatilibity was some kind of wanted, because of the
tcc specific sections.

>> 1. Odd options (-isystem) and the like
>
> -isystem causes gcc to add the named directory to the _beginning_ of the
> include directory search list, instead of the end. That should cause it to
> forget about the standard headers in /usr/include, as they aren't
> compatible with dietlibc.
>
> Unless tcc has its own way of doing that, you cannot do much about it.

It's the default case.

>> 2. This piece of code (__v_printf.c):
>>
>> union { char*s; } u_str;
>> #define s u_str.s
>>
>
> Where's the problem? tcc cannot compile it? Error message?

lib/__v_printf.c:192: field not found: u_str

> Well, someone will have thought something about this at the time of
> writing... I guess. Nonetheless, it is legit C, conforming to the C
> grammar as defined by ISO 9899:1999. If tcc cannot compile the above, that
> means it's broken.

A comment would have been useful.

>> 3. alloca is ubiquitiously used, but defined nowhere.
>>
>
> Unless prohibited by -fno-builtin or -fno-builtin-alloca, that function is
> a gcc builtin. There is no sensible way to write it outside of the
> compiler. alloca() allocates memory on the stack. That is, it decreases
> the stack pointer. Can't do that in a separate function.

Hm. There seem to be some patches to provide it; didn't knew it had to
be a compiler builtin (which seems odd to me, but well).

Aiju