|
|
On Wed, Nov 25, 2009 at 4:47 PM, Basile STARYNKEVITCH
<basile@xxxxxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxxxx>
>
> * 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?
This is completely broken. Instead link libiberty.a with --whole-archive
when plugins are enabled.
Richard.
> 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} ***
>
|
|