Update. With the recent addition of *make libtcc.dylib*, I tried to get two simultaneous compiler instances by 1) linking to libtcc.a (*-l tcc*) *and* (in the same program) 2) using dlopen/dlsym to load and use *libtcc.dylib*. This seems to work.
Is there any possibility that these two compilers share state? Also: many thanks to those working on macOS portability, the shared library build of libtcc, and the built-in variadics. -- karl On Tue, Jun 25, 2019 at 4:42 PM Karl Yerkes <karl.yer...@gmail.com> wrote: > >> Perhaps we've been coming at this from the wrong direction; >> I'm not quite sure one would need two compiler instances to recompile a >> single function. >> > > as far as i can tell "recompiling a function" is not a feature of libtcc. > you get "error: 'foo' defined twice" as you would with other compilers. > there's no way to delete a compiled function. > > >> >> TCC allows you to allocate memory for an object/function/program >> yourself- you call tcc_relocate with NULL for the 'ptr' parameter, and it >> returns >> the number of bytes needed to hold the object. >> > > you can relocate, but you cannot allocate ahead of time. also, in my > experience, the compiled function is still dependent on the tcc instance > that compiled it even after a relocation. delete the instance that compiled > *foo* and *foo* will sometimes crash. > > >> This means that that memory is no longer bound to or managed by TCC. >> > > not in my experience. look here: > > https://gist.github.com/kybr/9f8374fef992b96148f2d4311249ec3d > > >> I know when I've adapted TCC to cache function handlers, I just update >> the pointer to the handler function and then >> free() the old pointer; but this was single-threaded use, and I was >> disposing of TCC in between (re)compilations. >> >> For multi-threaded use, I believe you would just need a mutex to >> synchronize access the pointer. >> >> Have you tried this? Or is there some other stuff your code is doing that >> needs two compiler instances? >> > > i have no need of two compilers other than as a hack to recompile a > function. > > >> -Steve >> _______________________________________________ >> Tinycc-devel mailing list >> Tinycc-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/tinycc-devel >> >
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
