Plugins always enabled in GCC 4.8?

Plugins always enabled in GCC 4.8?

[Basile Starynkevitch]

Hello All,

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). 

In that case, I think that we should always --enable-plugin at configure time, hence
making that configure switch useless (since always on).

What do you think?

Do we aim at running next GCC on systems without dynamic libraries or withour plugins?
(If yes, why and which ones)?

Likewise, I also hope that next GCC will be only C++ compilable (and that we remove the
ability to compile it with C)


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?


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

Re: Plugins always enabled in GCC 4.8?

[Diego Novillo]

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.


> 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.

> Likewise, I also hope that next GCC will be only C++ compilable (and that we remove the
> ability to compile it with C)

This will only happen if someone does the work.  Hope produces no patches.

> 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.


Diego.

Re: Plugins always enabled in GCC 4.8?

[Basile Starynkevitch]

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

Re: Plugins always enabled in GCC 4.8?

[Richard Guenther]

On Mon, Apr 2, 2012 at 7:37 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> 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

SUSE does.  And until we get a real plugin API we will continue to do so.

Richard.

Re: Plugins always enabled in GCC 4.8?

[Basile Starynkevitch]

On Mon, Apr 02, 2012 at 10:44:41AM +0200, Richard Guenther wrote:
> On Mon, Apr 2, 2012 at 7:37 AM, Basile Starynkevitch
> <basile@starynkevitch.net> wrote:
> > 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:

> > I've heard that some Linux distributions (perhaps some version of RedHat?) explicitly
> > configure with --disable-plugin
> 
> SUSE does.  And until we get a real plugin API we will continue to do so.


I suppose that internally at SUSE you have a well defined criteria of what a
real plugin API should be.

Unfortunately, I (Basile) have no precise idea of what such a criteria
should be.

(it probably could be related to what I believe "being modular" means, but
AFAIU "being modular" have different meanings to different persons on this
gcc@ list, and there is no consensus here).

As a plugin developer, I call "plugin API" whatever is "available" as
callable from plugins, so for me the plugin API is just the set of headers
under $(gcc -print-file-name=plugin/include), which I agree is not very sexy
today, but is the only things plugin developers can have today.

So it seems that "real plugin API" has no consensual definition yet.

A simple example is libiberty: should it be part of the plugin API? If yes,
every function there (including pex_execute & xstrndup which current plugins
cannot use, because libiberty is statically linked, ... etc etc ad nauseam).
If libiberty is not part of the plugin API, how should plugin writers obtain
similar services?

Regards.

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

Re: Plugins always enabled in GCC 4.8?

[Gabriel Dos Reis]

On Mon, Apr 2, 2012 at 12:37 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> 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 feel that you are moving the goal post, and you are either
confusing the notion of modularity with something else you have not
been asking until now.  I find that a bit worrisome.

As pointed out by Diego, modularity and shared libraries are orthogonal
notions.  Modularity does not require shared libraries, not does it
provide them.

A long time ago, GCC was designed on purpose in a way that entangled
all levels of abstractions for fear that making it modular would encourage
proprietary work based on GCC without the benefits of contribution back.
Eventually the argument was won that we can make GCC follow
less contrived software engineering practices without giving away the
treasure.  You appear to be moving in directions that may give pause to
those who championed better separation of concerns in GCC.

-- Gaby

Re: Plugins always enabled in GCC 4.8?

[Basile Starynkevitch]

On Mon, Apr 02, 2012 at 05:40:37AM -0500, Gabriel Dos Reis wrote:
> On Mon, Apr 2, 2012 at 12:37 AM, Basile Starynkevitch
> <basile@starynkevitch.net> wrote:
> > 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 feel that you are moving the goal post, and you are either
> confusing the notion of modularity with something else you have not
> been asking until now.  I find that a bit worrisome.

What I was just saying that if a software is properly organized as a set of
well defined shared libraries (on current GNU/Linux systems), then these
shared libraries are defining an organisation of modules and bring ipso
facto some modularity. Of course, a modular software can be linked
statically, because IMHO modules are mostly a property of the source code,
not of the binary. (And a set of dynamically linked libraries can stay messy,
e.g. if it had circular dependencies).

(For instance, ocaml may not have shared libraries, but does have modules at
the language level.)


I also am in favor of having a software linked dynamically with shared
libraries, for a very pragramtical reason: If a software has shared
libraries, then modifying one such library in its implementation (not its
interface) is very often easier for the developer, who can, thanks to the
dynamic linking, test and use his improved shared library more easily and
more quickly. In particular, if GCC were made of shared libraries, I believe
that the build time would be much faster for the developer (ie the GCC
contributor), and this is a big comfort in practice.



> 
> As pointed out by Diego, modularity and shared libraries are orthogonal
> notions.  Modularity does not require shared libraries, not does it
> provide them.

Indeed. But I would think that properly designed shared libraries make a
modular software (of course, the design could be poor; at the worst mutually
circularily depending shared libraries don't give any modularity).

> 
> A long time ago, GCC was designed on purpose in a way that entangled
> all levels of abstractions for fear that making it modular would encourage
> proprietary work based on GCC without the benefits of contribution back.

Yes, but I thought that position was de jure abandoned once the licence
permitted plugins (I was understoooding the heated debate on the runtime
exception license was exactly that, and also I understood that debate has
ended).


> Eventually the argument was won that we can make GCC follow
> less contrived software engineering practices without giving away the
> treasure. 

I certainly don't want to open that debate again, and I really think it was
settled long time ago (ie.e. when the runtime exception license has been
last published, legally enabling the possibility of plugins).

> You appear to be moving in directions that may give pause to
> those who championed better separation of concerns in GCC.


I am not sure to understand that last sentence (I had to read it 4 times,
with different ways of understanding it). But I certainly don't understand
why you feel that my wish of having a collection of named and identified
modules in GCC is not a way of wanting seperation of concerns in GCC. If GCC
had an organisation in well identified modules (each having a name), why
would that go against seperation of concerns? I feel quite the opposite (see
Gnome/Gtk as my favorite example). And if GCC had well identified modules,
it would be easy (useful, but not necessary, just possible & comfortable) to
make it a collection of shared libraries (of course, we still would give the
ability to disable shared libraries at configure time to those wanting
that).


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 mines, sont seulement les miennes} ***

Re: Plugins always enabled in GCC 4.8?

[Gabriel Dos Reis]

On Mon, Apr 2, 2012 at 6:17 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:

>> You appear to be moving in directions that may give pause to
>> those who championed better separation of concerns in GCC.
>
>
> I am not sure to understand that last sentence (I had to read it 4 times,
> with different ways of understanding it). But I certainly don't understand
> why you feel that my wish of having a collection of named and identified
> modules in GCC is not a way of wanting seperation of concerns in GCC.

Where do you take that feeling from?

-- Gaby

Re: Plugins always enabled in GCC 4.8?

[Richard Guenther]

On Mon, Apr 2, 2012 at 2:38 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Mon, Apr 2, 2012 at 6:17 AM, Basile Starynkevitch
> <basile@starynkevitch.net> wrote:
>
>>> You appear to be moving in directions that may give pause to
>>> those who championed better separation of concerns in GCC.
>>
>>
>> I am not sure to understand that last sentence (I had to read it 4 times,
>> with different ways of understanding it). But I certainly don't understand
>> why you feel that my wish of having a collection of named and identified
>> modules in GCC is not a way of wanting seperation of concerns in GCC.
>
> Where do you take that feeling from?

And what does this all have to do with always enabling plugins or not?

Richard.

> -- Gaby

Re: Plugins always enabled in GCC 4.8?

[Joern Rennecke]

Quoting Basile Starynkevitch <basile@starynkevitch.net>:

> I also am in favor of having a software linked dynamically with shared
> libraries, for a very pragramtical reason: If a software has shared
> libraries, then modifying one such library in its implementation (not its
> interface) is very often easier for the developer, who can, thanks to the
> dynamic linking, test and use his improved shared library more easily and
> more quickly. In particular, if GCC were made of shared libraries, I believe
> that the build time would be much faster for the developer (ie the GCC
> contributor), and this is a big comfort in practice.

I don't see that.  Re-linking cc1 / cc1plus is reasonably fast.  And you'll
have to rebuild all the target libraries for a full test, no matter if
you have a monolithic exectuable or one with lots of dsos.  But in the
latter case, you'll have to dynamically link against numerous
dso for each library file compilation.

Where we could save rebuilding time is in cutting unwanted header
file dependencies, like tm.h included by frontends.
So, in that sense, more modularity helps build times.

But any gain from not statically re-linking the full executable is likely
already lost by more resource-hungry -fpic compilation, and even more
so by the dynamic link overhead.

Time savings when compiling the compiler with lto might be more noticable,
but only because you add additionaly boundaries which severely limit of
what lto can do for you.  lto and fast turn-around times don't mix very
well, anyway.