Re: [GCC Steering Committee] Android sub-port reviewer
On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote: > I volunteer as the reviewer for Android sub-port. > > Android/Bionic support is an extension over Linux port and is being gradually > added for more and more architectures. I wrote the original Android GCC > support for ARM (under a watchful design eye of Joseph Myers), and know how > the bits fit together. > > As adding Android support to a new architecture requires changes to that > architecture, the architecture maintainer will have the power of veto for the > Android-related changes. One of the members of SC raised a good point about whether architecture maintainers would prefer to handle the Android patches themselves. My intention is to spare you the additional headache of dealing with Android, but, well, maybe you like it :-). Richard E., Jan, Richard S., Do you want to handle Android changes by yourself or do you want to delegate? Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
Re: Plugins always enabled in GCC 4.8?
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.
gcc-4.8-20120401 is now available
Snapshot gcc-4.8-20120401 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120401/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 186057 You'll find: gcc-4.8-20120401.tar.bz2 Complete GCC MD5=18c32b5773a538f4ba36c330ee83c242 SHA1=ed9a05207fb77bee0478117578ed64d34d35bc57 Diffs from 4.8-20120325 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Plugins always enabled in GCC 4.8?
On Sun, 01 Apr 2012 16:41:09 -0400
Diego Novillo 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: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
