This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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

* 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

* every plugin could use all of

* the files should be changed.

Comments are welcome.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]