libiberty should be a shared library when cc1 has plugin enabled.

[Basile Starynkevitch <basile at starynkevitch dot net>]

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} ***