Re: [sigc] libsigc++ and g++-4.3

[Murray Cumming <murrayc murrayc com>]

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.

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com