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