On Mon, 2025-06-16 at 16:43 +0200, m...@rochus-keller.ch wrote: > > Thanks for your respones. > > @David: > > > I can imagine something that implements the libgccjit API and then > > > proxies the calls to different underlying target support libraries, > > but > > > that doesn't exist yet, and wouldn't you save any space on disk or > > > build times, alas. > > I will load the library via dlopen/dlsym to avoid static dependencies > anyway > and I assume by this very mechanism I would also be able to deal with > different > versions of the library without implementing a proxy.
That sounds like it should work, but see the caveat below... > > > > Not without a huge amount of work, as noted above. > > I understand, but at least building libgccjit so that the gcc > specific dependencies > like libgmp, libmpfr, libmpc can be avoided. Does build with -static > work for > libgccjit? To be honest, I'm not sure. You need to configure gcc with --enable- host-shared when enabling "jit", but maybe those flags are compatible? > Ideally I would the users offer a simple tar.gz download for each > architecture > and host system which they would reference by path from the IDE. > What do you think? Note that inasmuch as libgccjit.so implements the "code generation", it implements the code that goes from a high-level representation down to optimized assembler (analogous to, say, the cc1 binary in normal GCC usage), and has the code that "knows" how to implement the assembler and linker (analogous to the "gcc" "driver" binary in normal GCC usage) to go beyond justthe .s text-based version of the code. So to get object files or executables/libraries you'll also need an assembler and linker. This works for the single target case in that libgccjit.so does the same thing as "gcc" and invokes e.g. GNU as and ld with appropriate flags) - but if you're hoping to provide something per- target that users can download you're probably going to have to think about this too (sorry!) IIRC binutils supports all of its targets in one configuration/build, but the gcc "driver" logic might not have the smarts to do the right thing when invoking them (I'm not sure). So there *might* be some extra work there. If you haven't seen it yet, see: https://gcc.gnu.org/onlinedocs/jit/internals/index.html#overview-of-code-structure which has some diagrams that attempt to explain how it all fits together (for the jit use-case, at least). > > > @Basile > > Please not that I will use it for AOT, not for jit. Ironically, everyone using libgccjit is using it for AOT, rather than jit use-cases. Sorry (again) about the name... Hope this is constructive Dave
