This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Plugins always enabled in GCC 4.8?
- From: Basile Starynkevitch <basile at starynkevitch dot net>
- To: Diego Novillo <dnovillo at google dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 2 Apr 2012 07:37:56 +0200
- Subject: Re: Plugins always enabled in GCC 4.8?
- References: <20120331195124.527100bb3d7e0f84d884c7cd@starynkevitch.net> <4F78BD65.4010500@google.com>
On Sun, 01 Apr 2012 16:41:09 -0400
Diego Novillo <dnovillo@google.com> wrote:
> On 3/31/12 1:51 PM, Basile Starynkevitch wrote:
>
> > If we want to aim towards a more modular GCC made of several shared libraries, it seems
> > that we are requiring the host system to have dynamic libraries (which is not a big deal
> > today; all the major OSes running on developers desktop or laptop have them).
>
> I don't follow. Modularity does not require shared libraries.
Indeed, but when GCC is made of several shared libraries, it would be modular, since each
such shared library would be defined by a module.
(I mean that modules are a design thing existing at the source level, and each shared
library would implement one module; look into GTK/Gnome to feel what I mean: Pango,
Glib, Gio, Atk, .... are modules there and have libpango.so, libglib.so, libgio.so,
libatk.so ... at runtime..).
>
> > In that case, I think that we should always --enable-plugin at configure time, hence
> > making that configure switch useless (since always on).
>
> Plugins are auto-detected on systems that support it and always enabled.
I've heard that some Linux distributions (perhaps some version of RedHat?) explicitly
configure with --disable-plugin
>
> > More generally, I would like a description, or a list of host systems for GCC. What kind
> > of system services [e.g. dlopen, time, ...] to we require GCC to access to?
>
> The plugin support detection already asks these questions to the host
> system.
But the GCC contributor, and the plugin developer, needs a textual resource (i.e. a
set of header files, or a documented list of functions) of what functions are usable.
Current libiberty is a silly joke for plugin developers. Some functions from libiberty are
not callable from a plugin (because libiberty is statically linked inside cc1, and some
functions thus disappear; concretely a plugin cannot call pex_execute or xstrndup for
instance).
Cheers.
--
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 mine, sont seulement les miennes} ***