Re: [sigc] libsigc++ and g++-4.3
On Sat, Dec 08, 2007 at 09:04:02PM +0100, Murray Cumming [EMAIL PROTECTED] was heard to say: On Sat, 2007-12-08 at 09:38 -0800, Daniel Burrows wrote: On Sat, Dec 08, 2007 at 02:54:16PM +0100, Murray Cumming [EMAIL PROTECTED] was heard to say: I think I did that in libsigc++ 2.1.x. Have you tried that? No, I wasn't actually aware of libsigc++ 2.1. Is there an -announce list I should be subscribed to? I don't particularly want people to use 2.1 yet unless they need to. I'd really like to know whether it builds for you. Fair enough. It doesn't die with the typedef'ing error in g++-4.3, but I did have to add a #include stdlib.h and #include string.h to test_copy_invalid_slot.cc: test_copy_invalid_slot.cc: In function ‘int main(int, char**)’: test_copy_invalid_slot.cc:22: error: ‘malloc’ was not declared in this scope test_copy_invalid_slot.cc:23: error: ‘memset’ was not declared in this scope test_copy_invalid_slot.cc:31: error: ‘free’ was not declared in this scope Daniel ___ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
Re: [sigc] libsigc++ and g++-4.3
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_listsigc::slotT_return, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil sigc::signal0T_return, T_accumulator::slot_list' /usr/include/sigc++-2.0/sigc++/signal.h:168: error: changes meaning of 'slot_list' from 'struct sigc::slot_listsigc::slotT_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
Re: [sigc] libsigc++ and g++-4.3
On Sat, Dec 08, 2007 at 02:54:16PM +0100, Murray Cumming [EMAIL PROTECTED] was heard to say: On Mon, 2007-07-09 at 21:02 +0200, Murray Cumming wrote: On Sun, 2007-06-17 at 08:19 -0700, Daniel Burrows wrote: 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? No, I wasn't actually aware of libsigc++ 2.1. Is there an -announce list I should be subscribed to? Daniel ___ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
Re: [sigc] libsigc++ and g++-4.3
On Sat, 2007-12-08 at 09:38 -0800, Daniel Burrows wrote: On Sat, Dec 08, 2007 at 02:54:16PM +0100, Murray Cumming [EMAIL PROTECTED] was heard to say: On Mon, 2007-07-09 at 21:02 +0200, Murray Cumming wrote: On Sun, 2007-06-17 at 08:19 -0700, Daniel Burrows wrote: 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? No, I wasn't actually aware of libsigc++ 2.1. Is there an -announce list I should be subscribed to? I don't particularly want people to use 2.1 yet unless they need to. I'd really like to know whether it builds for you. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
Re: [sigc] libsigc++ and g++-4.3
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_listsigc::slotT_return, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil sigc::signal0T_return, T_accumulator::slot_list' /usr/include/sigc++-2.0/sigc++/signal.h:168: error: changes meaning of 'slot_list' from 'struct sigc::slot_listsigc::slotT_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 [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
[sigc] libsigc++ and g++-4.3
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_listsigc::slotT_return, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil sigc::signal0T_return, T_accumulator::slot_list' /usr/include/sigc++-2.0/sigc++/signal.h:168: error: changes meaning of 'slot_list' from 'struct sigc::slot_listsigc::slotT_return, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil ' 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. 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. Thanks, Daniel ___ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
