[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Add support of musl-libc to tinycc

From: avih
Subject: Re: [Tinycc-devel] Add support of musl-libc to tinycc
Date: Sat, 13 May 2017 10:31:56 +0000 (UTC)

 On Saturday, May 13, 2017 10:01 AM, grischka <address@hidden> wrote:

>> 3. It seems that (with musl) tcc needs stdarg.h included before stdio.h, or else

> You could create a stdio.h in <tccdir>/include ...

While I could do that (and thanks, wasn't aware of #include_next), va_list et-al
are required by more than one std include file. The headers which need it could
also change over time. My hope was to find a reasonably inter-operable way to
communicate it between the libc and tcc.

Rich Felker noted that musl expects __builtin_va* intrinsic or predefined
macros, which to me doesn't sound unreasonable. While the subject seems to have
drawn some responses with workarounds (your reply included), I haven't yet seen
a response which states that it's a bad idea for tcc to follow.

Is it a bad idea for tcc to follow?

>> 4. Initializers of NAN fail with "division by 0 in a constant", but I was _not_

> tcc knows __nan__

Yup, I was aware of it and I forgot to mention that it works. However, as I
noted in my followup email about the NAN subject, the main question here, IMHO,
is whether or not 0.0f/0.0f should be allowed in static-storage initializer.

If it's allowed, then it's probably best to fix it in tcc. But if not, then musl
does something which breaks tcc, and it needs to be communicated somehow between
tcc and musl. Or work around it in tcc, for instance by replacing NAN with
__nan__ before musl's headers get a chance to do a bad substitution.

> > 5. tcc dislikes some #defines ...

> According to the standard "#define ... defined" is undefined.
> Undefined identifiers however evaluate to 0: ...

Right. So this one is mpv's fault. Good solution :)

>> All that being said, after replacing the NANs with 0, moving include stdarg to
>> the top, and modifying the #define, mpv builds with tcc cleanly and runs fine
>> on alpine (with video, opengl, audio, etc).

> Doesn't sound too bad ;)
> --- grischka

And I even forgot to mention the best part: tcc did it more than 20x faster!

More build info:
- I used unofficial configure + Makefile because the official build system (waf)
doesn't know tcc and I couldn't fix it easily.
- Using 15W mobile Haswell CPU.
- configure completed in 1.1s with tcc, 3.5s with gcc
- make -j4 for ~150 C files completed in 1(!).0s with tcc, 26s with gcc.

So yeah, not bad at all indeed :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]