On Mon, 2007-07-09 at 21:02 +0200, Murray Cumming wrote: > On Sun, 2007-06-17 at 08:19 -0700, Daniel Burrows wrote: > > Hi all, > > > > I've been doing some test builds with g++-4.3 (on Debian, naturally), > > to see what sort of preparation will be needed before it's released as > > stable. One of the packages I was trying to build bombed with this > > error: > > > > /usr/include/sigc++-2.0/sigc++/signal.h:1675: error: declaration of > > 'typedef struct sigc::slot_list<sigc::slot<T_return, sigc::nil, sigc::nil, > > sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil> > > > sigc::signal0<T_return, T_accumulator>::slot_list' > > /usr/include/sigc++-2.0/sigc++/signal.h:168: error: changes meaning of > > 'slot_list' from 'struct sigc::slot_list<sigc::slot<T_return, sigc::nil, > > sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil> >' > > I'm not using this compiler yet, so I can't really investigate this > properly. > > > The typedef in question is protected by a #ifdef and a comment saying > > that it exists only for backwards compatibility. If I edit the include > > file in /usr/include that declares the corresponding #define and remove > > it, my compile succeeds. > > I'd be very tempted to remove that in out libsigc++ 2.2 version if it > seems necessary. Hopefully it's only API in a header, and not part of > the shared library.
I think I did that in libsigc++ 2.1.x. Have you tried that? > > This also causes the build of the library itself to fail. Is it safe > > for me to just remove the problematic #define from the headers entirely? > > I'd like to have future-proof packages if possible. > > You shouldn't do that in a distro package, ideally, but you might have > no choice. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list