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.

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]


PS. I hope that my RTLD_GLOBAL patch will be reviewed & accepted. It is essential (& tiny).

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]