forcing most functions of libiberty in plugin-enabled cc1

[Basile STARYNKEVITCH]

Hello All,

A plugin using a function in libiberty like make_temp_file fail to be dlopen-ed, because cc1 don't have it.

We did discuss in
    http://gcc.gnu.org/ml/gcc/2009-07/msg00166.html &
    http://gcc.gnu.org/ml/gcc/2009-07/msg00157.html
the usefulness of linking all (or at least most of) libliberty.a inside cc1 for plugin usage.

As the first message http://gcc.gnu.org/ml/gcc/2009-07/msg00166.html demonstrates, linking several times a shared 
library like libiberty is not good and may trigger subtile bugs.

So the standard answer: plugins needing libiberty should link that library themselves is not good.

The attached patch to trunk rev 154648 is a quick & dirty trick to force cc1 when plugins are enabled to link many such 
functions. It just declares an array of function pointers.

I really don't want to recode pex_execute and make_temp_file and friends in my MELT plugin. I am sure other plugins will 
want to use libliberty. And we already have it...


###### gcc/ChangeLog ####
2009-11-25  Basile Starynkevitch  <basile@starynkevitch.net>

	* plugin.c: added inclusion of libliberty.h & md5.h
	(funptr_t) Added new type local to this file.
	(plugin_libiberty_function_table_that_should_not_be_used): Added.

#########

I did check with nm that the resulting cc1 has all the functions.

Ok for trunk?

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} ***
-------------- next part --------------
A non-text attachment was scrubbed...
Name: forcelibiberty-for-plugins-rev154648.diff
Type: text/x-patch
Size: 3395 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20091125/944ce4bb/attachment.bin>