https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Arthur Cohen from comment #6) > (In reply to Richard Biener from comment #5) > > (In reply to Thomas Schwinge from comment #4) > > > If I understood Arthur correctly, GCC/Rust is going to effectively require > > > 'dlopen' (and therefore '--enable-plugin'?), so that means, if the > > > latter's > > > not available we have to auto-disable Rust language front end if enabled > > > '--enable-languages=all' vs. raise a 'configure'-time error if enabled via > > > explicit '--enable-languages=rust'? > > > > Not sure - --enable-plugin is not about dlopen, it's about exporting all > > GCCs internal symbols for use by a dlopened shared module. Is the > > macro processing requiring this or is it rather self-contained? > > > > Being able to dlopen() is something different. > > No, it does not require this and is rather self contained. Macro expansion > needs to be able to dlopen() compiled Rust libraries, which contain a > specific type of function our frontend calls as a macro. So we always need > to dlopen(). > > Is there anything similar in other frontends? If so, how does it work on > such platforms which do not support dlopen()? I'm not aware of other frontends absolutely requiring dlopen(), but the Modula-2 frontend uses a plugin for some extended diagnostics (but that requires a "real" plugin, with exporting symbols from GCC). I'm not aware of any abstraction for host shared module opening (to cover windows for example), I suppose in the end we need to have such a thing (like libiberty pex_* for execve/wait). Maybe there's functionality in gnulib for this. For now I suggest to look for dlopen(), there's # Some systems need dlopen save_LIBS="$LIBS" LIBS= AC_SEARCH_LIBS(dlopen, dl) DL_LIB="$LIBS" LIBS="$save_LIBS" AC_SUBST(DL_LIB) in gcc/configure.ac, so adding DL_LIB to the crab1 link should possibly suffice. -- You are receiving this mail because: You are on the CC list for the bug.
