tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] Build glibc


From: Evan Langlois
Subject: Re: [Tinycc-devel] Build glibc
Date: Mon, 29 Sep 2014 12:46:27 -0500

UHmm ...

On Mon, Sep 29, 2014 at 7:45 AM, Sylvain BERTRAND <address@hidden> wrote:
You are jocking or you are quite unreasonable. We all know that those scripts are generated using the horrible autoconf or the

Yeah, they are hard to read, but I've gotten things to go that were broken by just commenting out the tests that failed or hard coding the correct values into the script.

I didn't edit the autoconf files, just the final configure.  I found it was a lot easier to edit the shell script than to learn why autoconfwas broke  and try fixing it.

Additionnaly, compiling the glibc with tinycc you will loose most inline assembly parts. Actually, I have not benchmarked the cost of C function epilog and prolog for significant libc functions and mecanisms (no inline atomic xchg...).

This part I'm confused about.  I'm not sure WHY someone would try to compile glibc under tcc other than to find and fix bugs and missing features in tcc.  So, the problems you mention should be things that the original poster is prepared to fix, and I would think they wouldn't be daunted by a shell script.

If they don't know how to fix these things, then why attempt to build the library with tcc at all?  Its not something you are likely to need to build more than once, so tcc's speed at compiling doesn't matter much.  This is a clear case where gcc's features and better code output are a clear winner over tcc.  Tcc can link with the gcc-compiled glibc, so the point I can think of is to find the flaws and missing features you mentioned and get them fixed, right?

You could even say that getting autoconf working was part of the job, but I tend to take a bottom up approach - fix the output, then figure out how to get the script-generator to produce similar output so I know whats going on and why it works, so I tend to begin by manually wire-n-duct-tape method and then go back and patch it cleanly once I know it works.  Once configure generates your Makefile, even if its a broken Makefile you have to manually tweak, then you can decide which things you want to fix from there because you've got a make to automate the rest.

reply via email to

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