After removing the duplicate member on line 100, I was able to proceed
further, but then came upon another issue.

I got error messages that lead me to adding the line:
#include <memory>
to gtkmm-2.3.1/gtk/gtkmm/toolbar.h

But now I'm getting other interesting compilation errors:
 g++ -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"gtkmm\" -I../../gtk
-I../../../gtkmm-2.3.1/gtk -I../../pango -I../../../gtkmm-2.3.1/pango
-I../../atk -I../../../gtkmm-2.3.1/atk -I../../gdk
-I../../../gtkmm-2.3.1/gdk -I../../gtk -I../../../gtkmm-2.3.1/gtk
-I/usr/include/glibmm-2.3 -I/usr/lib/glibmm-2.3/include
-I/usr/lib/sigc++-1.2/include -I/usr/include/sigc++-1.2
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/X11R6/include -I/usr/include/pango-1.0
-I/usr/include/freetype2 -g -O2 -Wall -c
../../../gtkmm-2.3.1/gtk/gtkmm/toolbar.cc -Wp,-MD,.deps/toolbar.TPlo 
-fPIC -DPIC -o .libs/toolbar.o
../../../gtkmm-2.3.1/gtk/gtkmm/toolbar.cc: In method `class
Gtk::Toolbar_Helpers::ToolList & Gtk::Toolbar::tools()':
../../../gtkmm-2.3.1/gtk/gtkmm/toolbar.cc:416: initialization of
non-const reference type `class
auto_ptr<Gtk::Toolbar_Helpers::ToolList> &'
../../../gtkmm-2.3.1/gtk/gtkmm/toolbar.cc:416: from rvalue of type
`auto_ptr<Gtk::Toolbar_Helpers::ToolList>'
/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/memory:40:
in passing argument 1 of
`auto_ptr<Gtk::Toolbar_Helpers::ToolList>::operator
=(auto_ptr<Gtk::Toolbar_Helpers::ToolList> &)'
../../../gtkmm-2.3.1/gtk/gtkmm/toolbar.cc: In method `const class
Gtk::Toolbar_Helpers::ToolList & Gtk::Toolbar::tools() const':
../../../gtkmm-2.3.1/gtk/gtkmm/toolbar.cc:428: initialization of
non-const reference type `class
auto_ptr<Gtk::Toolbar_Helpers::ToolList> &'
../../../gtkmm-2.3.1/gtk/gtkmm/toolbar.cc:428: from rvalue of type
`auto_ptr<Gtk::Toolbar_Helpers::ToolList>'
/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/memory:40:
in passing argument 1 of
`auto_ptr<Gtk::Toolbar_Helpers::ToolList>::operator
=(auto_ptr<Gtk::Toolbar_Helpers::ToolList> &)'
make[1]: *** [toolbar.lo] Error 1
make[1]: Leaving directory `/usr/src/gtkmm/gtkmm-2.3.1-build/gtk/gtkmm'
make: *** [all-recursive] Error 1

And everything I've read on this seems to indicate a programming error
that says the following construct is illegal c++:
    tools_proxy_ = tools_proxy_ptr_type(new ToolList);

Created attachment 22399 [details] [review]
Allow build against gcc-2.95.x

Thanks, but you are patching generated files. Please see
http://www.gtkmm.org/bugs.shtml
for patching help.

That's ok, I don't feel too bad about that.  Just consider it an
advisory patch.  That is, "Oh, we need to fix our tools and/or input
so that achieves this goal."

I'll do what's necessary to get the darned thing to build, and report
back to you that these are issues.  But I simply don't have time to
help  with every single detail.

Hell, it certainly wasn't obvious to me that any of those files were
generated when I do something like ``vi +100
gtkmm-2.3.1/gtk/gtkmm/radioaction.h''

I am happy to apply a patch for this.

There is a chance that we will not support gcc 2.96 in future, because
we might use a newer libsigc++ that can not support it. On the mailing
list I am asking who needs 2.96 and why? Maybe you could reply to that.

Hi.

I'm on way too many email lists now as it is (if there was an NNTP
interface available, I'd use it).  So I'll just comment here.  I did
read the threads in the archives however.

First, let me explain that I have been maintaining my own home-grown
Linux system since 1994.  It's Linux from scratch before
linuxfromscratch existed.  I usually keep bleeding edge on most
things, but lately (last couple of years or so) I have slacked off a
bit and not followed the 2.5 kernels.  Since the Linux kernel, for a
long time, did not like to build with any gcc-3 [note: I just checked
2.6.1-rc2, and at least the docs there still recommend 2.95.x, x>=3],
I stuck with gcc-2.  This also forced me to stay with glibc-2.2.5. 
Now, I know that I can run two different versions of gcc, however
since the same `gcc' cannot  handle -V for 2.x and 3.x (-V only works
withing the same major). I didn't feel there was anything to really be
gained by upgrading; it wasn't worth the effort of trying to keep gcc2
and gcc3 executables.

A few other things pushed this as well.

For instance, gpc only works with gcc2.  And I've always wanted to
play with gpc (in my ohhhh so ample spare time :-).

It turns out that since gcc2 doesn't support C99 by default, I've
discovered a lot of code that would not build against non-C99
compilers being put out by people (stuff in Gnome, stuff on CPAN,
etc).  To paraphrase a well known saying, "All the world is not gcc."
 With the fact that a lot of compilers are not C99 capable yet, my
bleeding edge updates have helped me submit a LOT of patches to
various projects.  I imagine I could probably configure gcc3 to not do
 C99 by default, but since I've not looked into upgrading, I've not
bothered doing that research.

I don't do any C++ programming, so the personal need for the better
C++ support simply isn't there.

Now, those are the reasons why *I* still use 2.95.*.  Basically it
comes down to I'm lazy and it's useful for finding issues in the `C'
world.  But I admit that for C++, it sucks.

Some points to consider though:

Ignore RedHat completely.  2.96 does not exist.  Consider 2.95.3 (or
2.95.4 which is really cvs-tip from the 2_95 branch).  Just because RH
doesn't support the older compiler doesn't mean other people don't.
You can buy support for older RH from Progeny.  Heck, Sun continues to
build Java against RH6.2 or something like that.  A better solution
would be to look at what Debian supports in their unstable branch (or
wherever the comparable gtkmm stuff would live).

All the world is not Linux, either.  Someone pointed out that one of
the BSD's is using gcc-2.95.*.  What do other current OS's support in
their C++ environments as far as compatibilty goes?  I think that's a
far better guage.

If going to require the newer libsigc++, then yeah, definitely go
ahead an use modern C++ features and don't worry about backwards
compatibility.

However, I would strongly advise against specifically checking against
 version numbers of compilers.  That is just too fragile (regressions,
branching, etc) and only works for g++.  Instead, do feature checks
against whatever C++ compiler is being used.  As bug, like this one,
appear, then add it as a feature check and say "Your compiler does not
support feature XYZ."

Well, that's a lot of babbling.  :->

I guess it could all be summarized with this:  Go ahead and require
modern C++ features, but try to catch support for them up front with
autoconf.

> if there was NNTP interface available, I'd use it

Apparently these people have a newsgroup gateway:
http://marc.theaimsgroup.com/?l=gtkmm&r=1&w=2#gtkmm

Thanks. So, you seem to need gcc 2.9* becuase your need it to build
your kernel. Other mainstream distros don't have this problem - I
guess that they either use 2 compilers or they can compile the kernel
and user space apps with the same compiler. So I believe that it is
not a real problem. Of course, I also believe that linuxfromscratch
people actually enjoy having these problems.

So, I guess we'll drop the gcc 2.9* support. But thanks for showing us
that we needed to think about it.

We will not try to support gcc 2.9* for gtkmm 2.4, but we will happily
apply patches that anyone provides. Please reopen this bug if you have
a patch that fixes this for you.