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

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

Ralf Wildenhues wrote:
> * Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST:
>   
> > While Ralf's point about static data is valid, the functions likely to
> > be in libiberty on any platform supporting plugins should not suffer
> > from this problem.
> >     
>
> Solaris 9 and IRIX 6.5 support dlopen; gnulib documents them as missing
> setenv, and of course they are tertiary platforms only.  However, I
> wouldn't be surprised if plugins such as melt used setenv, esp. if they
> spawn other processes, e.g., to compile code.
>
>   
MELT is not currently using setenv yet, but may very easily need to use 
it. MELT does spawn processes already and uses getenv.
> > If you're concerned about it, then build a subset.  I've considered a
> > separation of libiberty into replacements and utilities, anyway.
> >     
>
> Why would that help in this case?  Even if the static data issue
> concerns one set of these functions only now (does it?), it won't
> prevent anyone from adding problems to the other set tomorrow, unless
> you also introduce a policy that libiberty functions be safe against
> multiple entities.

I do agree with this point.


Currently, in plugin mode, MELT does not use libiberty any more (which 
is a shame). So far, the only functions annoying me are pex_execute & 
friends (-in plugin mode MELT is simply calling system-) and 
choose_tmpdir (-in plugin mode MELT just calls tmpnam, which is pityful).


But we really need to decide if all of libiberty is usable in plugins. I 
believe it should be usable in plugins, because that is the easiest way 
to prototype future GCC core code: make it a plugin, and when it is 
ready & mature, propose it as a patch. I think that plugins are a new 
possibility in GCC, and FSF owned plugins should be welcomed (sadly I 
know that most people disagree with that).

We could also state that libiberty is becoming deprecated (in favor of 
recent standards like some flavor of Posix, ...). [I am half joking; I 
understand that they are many platforms requiring libiberty]

But we need to state a clear policy about libiberty & plugins. Can 
plugins use all of libiberty or should they use only functions already 
called by cc1?

[I am not able to propose a patch about this libiberty point because I 
do not understand all the portability issues]

Regards.

PS. I hope that my RTLD_GLOBAL patch 
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00497.html will be reviewed 
& accepted. It is essential (& tiny).

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