This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Cygwin support
On Fri, 14 Nov 2008, Brian Dessent wrote:
> "Joseph S. Myers" wrote:
>
> > As I understand it, there is an alternative - put all the shared code in a
> > DLL on Windows if configuring with plugins enabled, and link both the
> > plugins and cc1, cc1plus etc. with that DLL. If people wish to enable
>
> The problem with that approach is that people have so far said they want
> access to every aspect of the compiler from within the plugin, i.e. to
> poke and prod at the full symbol table, without being tied down by a
> limited, designated access route of a plugin API. This means you'd have
> to move essentially everything into this mega-DLL, leaving cc1 and
> friends as merely stubs that set a flag and then call into the DLL never
> to return, since anything left in cc1 would not be accessible from the
> plugin.
>
> That would present a problem to packagers. Since the code for all the
> language backends would be in this one mega-DLL, it would be impossible
> to install one language's compiler without installing all of them.
> Sure, you could still split it up into separate packages for the sake of
> the other runtime library support components and headers, but the user
> would still be paying the price in terms of disk and memory consumption
> of this mega-DLL that supports all languages when only using one of
> them.
Is there some reason there couldn't be one DLL for the code shared between
all languages and separate DLLs with each language's front end code? So a
plugin that only plugs in to the language-independent code would only need
the common DLL, and only plugins for front ends would need that front
end's DLL. cc1 would load just the two DLLs for C and for shared code,
not all of them.
--
Joseph S. Myers
joseph@codesourcery.com