This is the mail archive of the gcc@gcc.gnu.org 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: Plugins always enabled in GCC 4.8?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]