Hi,
I do some things at beyond linuxfromscratch ( http://www.linuxfromscratch.org/blfs/view/svn/ ) and have recently started including 0.48.5 in my own builds. We have been using libsigc++-2.3.1 for some time (I guess that whoever added it did not realis it was a development version), so we went with 2.3.2. Unfortunately, that breaks inkscape-0.48.5. The specific change was announced at https://mail.gnome.org/archives/libsigc-list/2014-August/msg00000.html where it mentioned runtime errors for users who added their own visit_each overload. In fact, for 0.48.5 it broke the build, and the relevant message appeared to be :
/usr/include/sigc++-2.0/sigc++/visit_each.h:169:64: error: cannot convert ‘const sigc::adaptor_functor<sigc::bound_mem_functor0<void, SPDesktop> >’ to ‘int’ in initialization /usr/include/sigc++-2.0/sigc++/visit_each.h:169:29: warning: unused variable ‘do_visit_each’ [-Wunused-variable] { sigc::visitor<T_functor>::do_visit_each(_A_action, _A_functor); } ^ CXX device-manager.o Makefile:5958: recipe for target 'desktop.o' failed make[2]: *** [desktop.o] Error 1
Dropping back to 2.3.1 fixed it. One of my colleagues created a patch to locally revert that particular change in libsigc++ which also fixed the build.
My first question [ at last! ] is: Do you care about people who build 0.48 with libsigc++-2.3-series ? If you do, any ideas how to fix this ?
Thanks.
ĸen
Can you send the *entire* error there? I can't really determine where the troublesome line of code originated.
On Thu, Aug 7, 2014 at 3:15 PM, Ken Moffat <zarniwhoop@...3141...> wrote:
Hi,
I do some things at beyond linuxfromscratch ( http://www.linuxfromscratch.org/blfs/view/svn/ ) and have recently started including 0.48.5 in my own builds. We have been using libsigc++-2.3.1 for some time (I guess that whoever added it did not realis it was a development version), so we went with 2.3.2. Unfortunately, that breaks inkscape-0.48.5. The specific change was announced at https://mail.gnome.org/archives/libsigc-list/2014-August/msg00000.html where it mentioned runtime errors for users who added their own visit_each overload. In fact, for 0.48.5 it broke the build, and the relevant message appeared to be :
/usr/include/sigc++-2.0/sigc++/visit_each.h:169:64: error: cannot convert ‘const sigc::adaptor_functor<sigc::bound_mem_functor0<void, SPDesktop> >’ to ‘int’ in initialization /usr/include/sigc++-2.0/sigc++/visit_each.h:169:29: warning: unused variable ‘do_visit_each’ [-Wunused-variable] { sigc::visitor<T_functor>::do_visit_each(_A_action, _A_functor); } ^ CXX device-manager.o Makefile:5958: recipe for target 'desktop.o' failed make[2]: *** [desktop.o] Error 1
Dropping back to 2.3.1 fixed it. One of my colleagues created a patch to locally revert that particular change in libsigc++ which also fixed the build.
My first question [ at last! ] is: Do you care about people who build 0.48 with libsigc++-2.3-series ? If you do, any ideas how to fix this ?
Thanks.
ĸen
Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m.
Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, Aug 07, 2014 at 03:28:32PM -0400, Liam White wrote:
Can you send the *entire* error there? I can't really determine where the troublesome line of code originated.
It may take a little while (I forgot to save the log after copying that line to my notes), but the system is in a position where I should be able to recover to a backup from before libsigc++.
ĸen
On Thu, Aug 07, 2014 at 09:03:15PM +0100, Ken Moffat wrote:
On Thu, Aug 07, 2014 at 03:28:32PM -0400, Liam White wrote:
Can you send the *entire* error there? I can't really determine where the troublesome line of code originated.
It may take a little while (I forgot to save the log after copying that line to my notes), but the system is in a position where I should be able to recover to a backup from before libsigc++.
Didn't take too long, and I now see that the first error message was quite a bit earlier. Missed that amongst the warnings in my original -j 4 build. I'll attach a complete gzipped log (make -j1, 160K before zipping, which might be too big, now only 8K).
ĸen
I looked through the log and didn't find anything that we might be responsible for! Grepping through the 0.48.5 source code I saw no mention of the term "visit_each."
In fact, it looks as if sigc++ is conflicting with itself whenever #include <sigc++/functors/mem_fun.h> is reached! Maybe try removing that line and #include <sigc++/signal.h> instead.
On Thu, Aug 7, 2014 at 5:03 PM, Ken Moffat <zarniwhoop@...3141...> wrote:
On Thu, Aug 07, 2014 at 09:03:15PM +0100, Ken Moffat wrote:
On Thu, Aug 07, 2014 at 03:28:32PM -0400, Liam White wrote:
Can you send the *entire* error there? I can't really determine where
the
troublesome line of code originated.
It may take a little while (I forgot to save the log after copying that line to my notes), but the system is in a position where I should be able to recover to a backup from before libsigc++.
Didn't take too long, and I now see that the first error message was quite a bit earlier. Missed that amongst the warnings in my original -j 4 build. I'll attach a complete gzipped log (make -j1, 160K before zipping, which might be too big, now only 8K).
ĸen
Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m.
On Thu, Aug 07, 2014 at 05:12:50PM -0400, Liam White wrote:
I looked through the log and didn't find anything that we might be responsible for! Grepping through the 0.48.5 source code I saw no mention of the term "visit_each."
In fact, it looks as if sigc++ is conflicting with itself whenever #include <sigc++/functors/mem_fun.h> is reached! Maybe try removing that line and #include <sigc++/signal.h> instead.
On Thu, Aug 7, 2014 at 5:03 PM, Ken Moffat <zarniwhoop@...3141...> wrote:
Thanks for taking the time to look - I'd better take this to the libsigc-list at gnome.
ĸen
On Thu, Aug 07, 2014 at 11:59:47PM +0100, Ken Moffat wrote:
On Thu, Aug 07, 2014 at 05:12:50PM -0400, Liam White wrote:
I looked through the log and didn't find anything that we might be responsible for! Grepping through the 0.48.5 source code I saw no mention of the term "visit_each."
In fact, it looks as if sigc++ is conflicting with itself whenever #include <sigc++/functors/mem_fun.h> is reached! Maybe try removing that line and #include <sigc++/signal.h> instead.
On Thu, Aug 7, 2014 at 5:03 PM, Ken Moffat <zarniwhoop@...3141...> wrote:
Thanks for taking the time to look - I'd better take this to the libsigc-list at gnome.
It has now been fixed in libsigc++ - thanks again.
ĸen
On Thu, Aug 7, 2014, at 12:15 PM, Ken Moffat wrote:
Dropping back to 2.3.1 fixed it. One of my colleagues created a patch to locally revert that particular change in libsigc++ which also fixed the build.
My first question [ at last! ] is: Do you care about people who build 0.48 with libsigc++-2.3-series ? If you do, any ideas how to fix this ?
One note on this. I believe that the 'care' aspect is definitely present. The main question would be as to who on our side has time to spare to focus on it. Keeping forwards compatible is a good thing, but we do have more limited resources in terms of man-hours and people.
So please do not feel slighted if it takes some time to respond to individual aspects. We definitely are interested in improving our codebase and support.
On Thu, Aug 07, 2014 at 01:29:49PM -0700, Jon A. Cruz wrote:
On Thu, Aug 7, 2014, at 12:15 PM, Ken Moffat wrote:
Dropping back to 2.3.1 fixed it. One of my colleagues created a patch to locally revert that particular change in libsigc++ which also fixed the build.
My first question [ at last! ] is: Do you care about people who build 0.48 with libsigc++-2.3-series ? If you do, any ideas how to fix this ?
One note on this. I believe that the 'care' aspect is definitely present. The main question would be as to who on our side has time to spare to focus on it. Keeping forwards compatible is a good thing, but we do have more limited resources in terms of man-hours and people.
So please do not feel slighted if it takes some time to respond to individual aspects. We definitely are interested in improving our codebase and support.
Sorry, I did not intend to be abrupt, and certainly didn't intend to be rude. But I can well understand that this might fall into the patient: Doctor, it hurts if I do this. doctor: Well then, don't do that. category. I also understand your point about limited man-hours and people, particularly when you are focussing on a development rc.
ĸen
On Thu, Aug 7, 2014, at 01:58 PM, Ken Moffat wrote:
Sorry, I did not intend to be abrupt, and certainly didn't intend to be rude. But I can well understand that this might fall into the patient: Doctor, it hurts if I do this. doctor: Well then, don't do that. category. I also understand your point about limited man-hours and people, particularly when you are focussing on a development rc.
Oh, I definitely did not take it as you being rude. I just wanted to let you know that we cared about your info and any slowness on our part would just be lack of resources vs lack of interest.
Keeping our codebase working nicely with different versions of compilers and libs is one of the areas that I specifically care about, but at the moment I've been sidelined by having to deal with real-world concerns (stupid day-job issues, bleah). If Liam can't pin things down shortly I might be able to carve off some time myself in a little bit. I'd also been slowed by major breakages in my toolchain (I develop on a Mac), but the last of those blockers have been addressed not too long ago.
participants (3)
-
Jon A. Cruz -
Ken Moffat -
Liam White