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]

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

Dave Korn wrote:
Dave Korn wrote:
We might also artificially add a reference to each libiberty function
Or link it into cc1 et al. using "--whole-archive".

Sorry, I am not aware of this option. And are we sure it works on all
the systems GCC is supposed to run on?

Ach. It requires GNU ld, of course. We could just link the objects from the libiberty/ dir into cc1 (etc.) instead of the lib .a archive.

Anyway, I am not able to do that well. The point is that libiberty is designed to provide a common interface to all the many systems GCC is supposed to run on, and even if restricting ourselves to those having ELF & a working dlopen, that makes a lot. In other words, I am unfamiliar with libiberty (and I am not sure to understand why in 2009, with the existing Posix & OpenGroup standards, it is still required. I suppose it is a legacy).
Also, I don't know if we should patch libiberty or gcc/ directory to solve that (I am not sure if libiberty is legally a part of GCC; ie does the legal right to patch GCC is enough for libliberty, which is perhaps shared with other stuff like binutils).

The quick & dirty fix would be to add inside eg gcc-plugin.c a table of function pointers, or perhaps some code, referencing most (or preferably all) of libiberty functions.

While pluginifying MELT I have to add a lot of dirty patches to avoid (i.e. circumvent them) libiberty functions. This is a pity!


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]