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

[Basile STARYNKEVITCH <basile@starynkevitch.net>]

Dave Korn wrote:
> Basile STARYNKEVITCH wrote:
>   
>> Dave Korn wrote:
>>     
>>>> We might also artificially add a reference to each libiberty function
>>>> from
>>>> cc1.     
>>>>         
>>>   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!

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