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

[Murray Cumming <murrayc murrayc com>]

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.

>   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.


-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com