[Top][All Lists]

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

Re: [Tinycc-devel] Almost added a feature, but I broke things

From: Kyryl Melekhin
Subject: Re: [Tinycc-devel] Almost added a feature, but I broke things
Date: Thu, 24 Dec 2020 10:38:31 -0500

>I figured a lot of people would like, that >libtcc can hold a virtual read-only file >system, so that you don't actually need to >have an include, lib and libtcc directory for >a project to use libtcc.

Is that so? I can kind of see where you are coming from, but this is not the right way to solve it. It creates unnecessary dependency bloat, and even a lot more headache for anybody willing to take time and read though that. If you want I can send you my custom amalgamated version of TCC which is literally 1 c file, does not depend on tcclib, because it has it in it's source already, all the assembly routines for stuff like alloca, are written in extended asm syntax and they work. There is no need to run make to compile, just gcc tinycc.c and some platform flags is enough. You also don't need to worry about header files, because you can always make your own, just write extern printf(...) bla bla and it will work. That's basically how I use tcc, it's so much easier to work with and maintain especially now that i have wrote a special version of tcc which can correctly amalgamate any C source code just like compiler sees it, no assumptions because tcc implements complete preprocessor spec. 

On Thu, Dec 24, 2020, 06:29 Joshua Scholar <joshuascholar@gmail.com> wrote:
If anyone who knows this project better than me can help it would be wonderful.

I decided to add a feature I figured a lot of people would like, that libtcc can hold a virtual read-only file system, so that you don't actually need to have an include, lib and libtcc directory for a project to use libtcc.

Warning, I'm a windows user, so I'm probably doing this on a different system than most of you.

Now that I think about it, my choice to do it by embedding a zip file and linking miniunzip and libz in was probably a poor one for efficiency.  Those parts are working, so I'll leave it alone until I get the bugs I caused out, unzipping, buffering the unzipped data every time, allocating and deallocating the memory for those buffers and putting a global lock on the miniunzip calls waste time, and if people want to use libtcc as something like a jit, they probably would prefer the speed to the memory. 

Also, and even more convincing, embedding libz and the latest version of minizip (which has forked off from libz) into the project and making it work on every platform would be a nightmare.

But never mind that for now, my current state is:
tcc works for making .o files and .a files and the results are byte equivalent the previous version - and it doesn't need the directories to exist to do it.

But libtcc_test silently fails, and I can't get this version of tcc to make exe files and -run doesn't work.

But since I didn't make a visual studio solution file, I'm just working off the command line, I haven't been able to use a debugger and I'm lost for why everything compiles without complaint and runs without complaint, but not everything works.

To get help from the compiler I replaced the int type for posix handles with a struct type for a wrapped handle that can read from this virtual file system.  Since the types can't be substituted without error, I should have caught all the spots where I need to change things.

Joshua Scholar
Tinycc-devel mailing list

reply via email to

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