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