* Plugins always enabled in GCC 4.8? @ 2012-03-31 17:51 Basile Starynkevitch 2012-04-01 20:41 ` Diego Novillo 0 siblings, 1 reply; 10+ messages in thread From: Basile Starynkevitch @ 2012-03-31 17:51 UTC (permalink / raw) To: gcc 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} *** ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Plugins always enabled in GCC 4.8? 2012-03-31 17:51 Plugins always enabled in GCC 4.8? Basile Starynkevitch @ 2012-04-01 20:41 ` Diego Novillo 2012-04-02 5:38 ` Basile Starynkevitch 0 siblings, 1 reply; 10+ messages in thread From: Diego Novillo @ 2012-04-01 20:41 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Plugins always enabled in GCC 4.8? 2012-04-01 20:41 ` Diego Novillo @ 2012-04-02 5:38 ` Basile Starynkevitch 2012-04-02 8:44 ` Richard Guenther 2012-04-02 10:40 ` Gabriel Dos Reis 0 siblings, 2 replies; 10+ messages in thread From: Basile Starynkevitch @ 2012-04-02 5:38 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc 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} *** ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Plugins always enabled in GCC 4.8? 2012-04-02 5:38 ` Basile Starynkevitch @ 2012-04-02 8:44 ` Richard Guenther 2012-04-02 9:33 ` Basile Starynkevitch 2012-04-02 10:40 ` Gabriel Dos Reis 1 sibling, 1 reply; 10+ messages in thread From: Richard Guenther @ 2012-04-02 8:44 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: Diego Novillo, gcc 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Plugins always enabled in GCC 4.8? 2012-04-02 8:44 ` Richard Guenther @ 2012-04-02 9:33 ` Basile Starynkevitch 0 siblings, 0 replies; 10+ messages in thread From: Basile Starynkevitch @ 2012-04-02 9:33 UTC (permalink / raw) To: gcc 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} *** ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Plugins always enabled in GCC 4.8? 2012-04-02 5:38 ` Basile Starynkevitch 2012-04-02 8:44 ` Richard Guenther @ 2012-04-02 10:40 ` Gabriel Dos Reis 2012-04-02 11:17 ` Basile Starynkevitch 1 sibling, 1 reply; 10+ messages in thread From: Gabriel Dos Reis @ 2012-04-02 10:40 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: Diego Novillo, gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Plugins always enabled in GCC 4.8? 2012-04-02 10:40 ` Gabriel Dos Reis @ 2012-04-02 11:17 ` Basile Starynkevitch 2012-04-02 12:38 ` Gabriel Dos Reis 2012-04-02 13:05 ` Joern Rennecke 0 siblings, 2 replies; 10+ messages in thread From: Basile Starynkevitch @ 2012-04-02 11:17 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Diego Novillo, gcc 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} *** ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Plugins always enabled in GCC 4.8? 2012-04-02 11:17 ` Basile Starynkevitch @ 2012-04-02 12:38 ` Gabriel Dos Reis 2012-04-02 12:43 ` Richard Guenther 2012-04-02 13:05 ` Joern Rennecke 1 sibling, 1 reply; 10+ messages in thread From: Gabriel Dos Reis @ 2012-04-02 12:38 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: Diego Novillo, gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Plugins always enabled in GCC 4.8? 2012-04-02 12:38 ` Gabriel Dos Reis @ 2012-04-02 12:43 ` Richard Guenther 0 siblings, 0 replies; 10+ messages in thread From: Richard Guenther @ 2012-04-02 12:43 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Basile Starynkevitch, Diego Novillo, gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Plugins always enabled in GCC 4.8? 2012-04-02 11:17 ` Basile Starynkevitch 2012-04-02 12:38 ` Gabriel Dos Reis @ 2012-04-02 13:05 ` Joern Rennecke 1 sibling, 0 replies; 10+ messages in thread From: Joern Rennecke @ 2012-04-02 13:05 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: Gabriel Dos Reis, Diego Novillo, gcc 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-04-02 13:05 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-31 17:51 Plugins always enabled in GCC 4.8? Basile Starynkevitch 2012-04-01 20:41 ` Diego Novillo 2012-04-02 5:38 ` Basile Starynkevitch 2012-04-02 8:44 ` Richard Guenther 2012-04-02 9:33 ` Basile Starynkevitch 2012-04-02 10:40 ` Gabriel Dos Reis 2012-04-02 11:17 ` Basile Starynkevitch 2012-04-02 12:38 ` Gabriel Dos Reis 2012-04-02 12:43 ` Richard Guenther 2012-04-02 13:05 ` Joern Rennecke
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).