Re: [Tinycc-devel] [ELF][Relocatable] undefined global symbols will confuse binutils bfd if not set to STT_NOTYPE

2023-10-27 Thread draco
On Thu, Oct 26, 2023 at 07:15:11PM +0200, draco wrote: >/Sylvain,/ >// >/it seems to me, like this patch breaks the windows builds, maybe for/ >/exactly the same reason, ldd gets confused./ >// >/See the github mirror of tinycc, it has some automated builds and the/ >/win32

[Tinycc-devel] [ELF][Relocatable] undefined global symbols will confuse binutils bfd if not set to STT_NOTYPE

2023-10-26 Thread draco
Sylvain, it seems to me, like this patch breaks the windows builds, maybe for exactly the same reason, ldd gets confused. See the github mirror of tinycc, it has some automated builds and the win32 part starts breaking with linker errors against libtcc exactly after picking up your patch:

Re: [Tinycc-devel] Help with tcc_add_symbol // pe_find_import in 0.9.27

2022-06-21 Thread draco
grishka, thank you so much for pointing me in the right direction. I was able to solve the problem (more or less) with this hint, though this means to patch tclDecls.h and tclIntDecls.h, two headers I took in from the tcl Source, so a bit problematic to maintain. Furthermore, the

Re: [Tinycc-devel] Relative paths of include files are not normalised, which can break #pragma once

2023-07-06 Thread draco
Hermann, I tested your patch a bit, seems to work as expected and brings tcc win32 back to it's normal speed. Can you upload it to the mob? Thank you! Michael ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

[Tinycc-devel] TinyCC as selfcontaining compiler

2023-06-06 Thread draco
Dear TinyCC community, first: Thanks for all the work that goes into maining tcc all the years, I'm a regular reader of the mailing list. I developed a little add-on//patch to TinyCC which I call ziptcc. It enables tcc to read include files etc from a single zip or even from it's own exe (if

[Tinycc-devel] libtcc without tcclib1 on Emscripten

2023-08-12 Thread draco
You could try adapting something like c-embed https://github.com/weigert/c-embed to tinycc. I made a zip enabled version of tcc, https://github.com/MichaelMiR01/ziptcc_dev but this still opens the zipfile, so not a solution for your problem. But it patches tcc without modifications to the

Re: [Tinycc-devel] Relative paths of include files are not normalised, which can break #pragma once

2023-06-26 Thread draco
Thanks Herman for pushing the #pragma once fix. I'm developing and maintaining tcc4tcl and ziptcc patches and both re#define open, close and read to work. In your patch you are reintroducing fopen, fclose, fread. May I ask if this is neccessary and if not may I ask you to switch this to open,

Re: [Tinycc-devel] Relative paths of include files are not normalised, which can break #pragma once

2023-06-28 Thread draco
Pragma once is implementation defined, so I ponder a bit on the definition… 1. pragma once is defined on the file level, while regular source code can be amalgamated to a single source and in fact this is what the preprocessor does 2. does pragma once exclude the whole file from

Re: [Tinycc-devel] Question about in-memory compilation, target

2024-02-11 Thread draco via Tinycc-devel
You're right, I didn't verify closely, but the ABI is still intact. Sorry... Am 10.02.24 um 22:12 schrieb Eric Raible: > This means, that not only the public API changes, but also the > libtcc.dll/so ABI, making all programs using libtcc crash without warning. > > Is this intended? > > Michael

[Tinycc-devel] win32 build missing runmain.o

2024-02-17 Thread draco via Tinycc-devel
Hi grischka, regarding your latest patch introducing runmain.c I found that the according buil-tcc.bat is unchanged, thus runmain.o is not build. It would be great, if you could include this to get tcc up and running under win32/64 :-) Thanks a lot! Michael --

Re: [Tinycc-devel] Question about in-memory compilation target

2024-01-16 Thread draco via Tinycc-devel
Is it possible to keep, use and then release the compiled code after the initial compiler instance has been deleted (ie: after tcc_delete). Actually I strugled with the same problem and found a partial solution: If you look up the code in libtcc.c, in function tcc_delete is the line