Hello All, Perhaps libiberty should be a shared library, not a static one, linked from cc1, when GCC has plugin enabled.
I noticed the following in the MELT branch (while trying to build MELT as a GCC-Trunk plugin). Some functions of libiberty.h are not linked in cc1 (because cc1 don't call them, and libliberty.a is a static library, not a shared one). A concrete example is make_temp_file. It is used in gcc.c but not in the entire cc1, and one could imagine a plugin might want it. But if a plugin calls it, the dlopen of that plugin fails with undefined symbol: make_temp_file. Of course, for that simple case a workaround is possible (at least on Linux): use a standard temporary file function like tmpfile() instead of make_temp_file. But it seems to me that a plugin can call a libliberty function only if that function is already referenced (e.g. called) from cc1. This is not the case of all libiberty functions. We might also artificially add a reference to each libiberty function from cc1. Or we should at least document (perhaps as a comment in libiberty.h) that all these functions are not available from plugins. Linking statically libiberty.a into a plugin is not recommended (because *.so should not contain non PIC code on many platforms). If we did link dynamically libiberty.so: * execution time (of cc1) might suffer a bit, because perhaps calling a function in a dynamic library could be slower than calling it in a static library. * every plugin could use all of libliberty.so * the Makefile.in files should be changed. Comments are welcome. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
