Crash on start rev 12550 : TypeNotRegistered
Hi,
Launching a clean build on a Win7 64bits raises an exception:
terminate called after throwing an instance of 'FactoryExceptions::TypeNotRegistered what(): svg:svg
On 2013-09-20 09:29 +0200, Yann Papouin wrote:
Launching a clean build on a Win7 64bits raises an exception:
terminate called after throwing an instance of 'FactoryExceptions::TypeNotRegistered what(): svg:svg
Same reported here: - Bug #1227956 “crash on startup. Windows XP, Inkscape rev 12549” https://bugs.launchpad.net/inkscape/+bug/1227956
Launching a clean build on a Win7 64bits raises an exception:
terminate called after throwing an instance of 'FactoryExceptions::TypeNotRegistered what(): svg:svg
Same reported here:
- Bug #1227956 “crash on startup. Windows XP, Inkscape rev 12549”
I have just added a patch to this bug. Why are there three different build system for compiling Inkscape actually?
Regards, Markus
2013/9/20 Markus Engel <p637777@...1081...>:
I have just added a patch to this bug. Why are there three different build system for compiling Inkscape actually?
Autotools is what was used since the beginning. btool was added later, because Autotools requires MSYS on Windows (basically a thin POSIX emulation layer), and it seems the great wise coders who wrought the Windows port preferred to write their own build tool rather than use MSYS. CMake was intended to replace both of those, but it doesn't have important features which exist in Autotools and btool, and adding them back requires writing lots of code in a poorly designed and verbose scripting language.
In December 2010, I tried to create an unified build system using Waf. I succeeded in adding practically all of the features in the Autotools and btool systems, but it required some hacks and modifications to Waf source. Things have changed now and I have far more experience due to using Waf to build software developed at my NMR laboratory - I think I could modify this system to work with a vanilla copy of Waf. The code is here: https://code.launchpad.net/~tweenk/inkscape/waf-build
If there is interest in unifying the build systems before the 0.49 release, I could dust off this code and make it work again with modern trunk.
Regards, Krzysztof
On Fri, Sep 20, 2013 at 06:17:41PM +0200, Krzysztof Kosiński wrote:
2013/9/20 Markus Engel <p637777@...1081...>:
I have just added a patch to this bug. Why are there three different build system for compiling Inkscape actually?
Autotools is what was used since the beginning. btool was added later, because Autotools requires MSYS on Windows (basically a thin POSIX emulation layer), and it seems the great wise coders who wrought the Windows port preferred to write their own build tool rather than use MSYS. CMake was intended to replace both of those, but it doesn't have important features which exist in Autotools and btool, and adding them back requires writing lots of code in a poorly designed and verbose scripting language.
Out of curiousity what was/is missing from cmake?
In December 2010, I tried to create an unified build system using Waf. I succeeded in adding practically all of the features in the Autotools and btool systems, but it required some hacks and modifications to Waf source. Things have changed now and I have far more experience due to using Waf to build software developed at my NMR laboratory - I think I could modify this system to work with a vanilla copy of Waf. The code is here: https://code.launchpad.net/~tweenk/inkscape/waf-build
If there is interest in unifying the build systems before the 0.49 release, I could dust off this code and make it work again with modern trunk.
Not sure how much time there is before 0.49, but in general build system changes can be a bit disruptive (bug fixers have to stop fixing bugs and learn the new system), so the optimal time to land infrastructure changes is right *after* a release. Plus 0.50 is a nice round number, perfect for featuring big codebase improvements like that. :-)
Might also want to think about if the build system is changed to make it more portable, also give consideration to other possible platforms that Inkscape isn't currently on but that someone might conceivably want to port to some day (e.g. mobile devices and whatnot.)
Bryce
2013/9/20 Bryce Harrington <bryce@...961...>:
On Fri, Sep 20, 2013 at 06:17:41PM +0200, Krzysztof Kosiński wrote:
Autotools is what was used since the beginning. btool was added later, because Autotools requires MSYS on Windows (basically a thin POSIX emulation layer), and it seems the great wise coders who wrought the Windows port preferred to write their own build tool rather than use MSYS. CMake was intended to replace both of those, but it doesn't have important features which exist in Autotools and btool, and adding them back requires writing lots of code in a poorly designed and verbose scripting language.
Out of curiousity what was/is missing from cmake?
- Doesn't generate the "distribution directory" which allows testing on Windows - Doesn't seem to have any support whatsoever for i18n (compiling message catalogs, updating translation templates, and so on) - Many configuration tests unimplemented - Outdated and broken tarball generation - Installation code only provided for Unix - No support for unit tests
All of these were implemented in the Waf build system, and I also added some experimental features, such as separate debug symbol files for all platforms.
Might also want to think about if the build system is changed to make it more portable, also give consideration to other possible platforms that Inkscape isn't currently on but that someone might conceivably want to port to some day (e.g. mobile devices and whatnot.)
I tested the system on Windows and Linux, and the same build scripts could be used with a very limited amount of platform-specific code. I guess it would also work well on OS X. The only dependency is Python.
Regards, Krzysztof
On Sep 20, 2013, at 2:03 PM, Bryce Harrington wrote:
On Fri, Sep 20, 2013 at 06:17:41PM +0200, Krzysztof Kosiński wrote:
2013/9/20 Markus Engel <p637777@...1081...>:
I have just added a patch to this bug. Why are there three different build system for compiling Inkscape actually?
Autotools is what was used since the beginning. btool was added later, because Autotools requires MSYS on Windows (basically a thin POSIX emulation layer), and it seems the great wise coders who wrought the Windows port preferred to write their own build tool rather than use MSYS. CMake was intended to replace both of those, but it doesn't have important features which exist in Autotools and btool, and adding them back requires writing lots of code in a poorly designed and verbose scripting language.
Out of curiousity what was/is missing from cmake?
FYI when I spoke in-person with the CMake developers they thought that it should work well for Inkscape, or take minimal support effort on their end.
On 20-9-2013 16:37, Markus Engel wrote:
Launching a clean build on a Win7 64bits raises an exception:
terminate called after throwing an instance of 'FactoryExceptions::TypeNotRegistered what(): svg:svg
Same reported here:
- Bug #1227956 “crash on startup. Windows XP, Inkscape rev 12549” https://bugs.launchpad.net/inkscape/+bug/1227956
I have just added a patch to this bug. Why are there three different build system for compiling Inkscape actually?
Could it be that the current code has the problem that is described here: http://stackoverflow.com/questions/9459980/c-global-variable-not-initialized...
-Johan
Could it be that the current code has the problem that is described here: http://stackoverflow.com/questions/9459980/c-global-variable-not-initialized...
-Johan
Yes, that's exactly our problem. That's why we disabled libinkscape.a in the other build systems and link together all the object files directly. I just don't know how to do that in build.xml I commented on that in Launchpad.
Regards, Markus
On 20-9-2013 23:35, Markus Engel wrote:
Could it be that the current code has the problem that is described here: http://stackoverflow.com/questions/9459980/c-global-variable-not-initialized...
-Johan
Yes, that's exactly our problem. That's why we disabled libinkscape.a in the other build systems and link together all the object files directly. I just don't know how to do that in build.xml I commented on that in Launchpad.
Fixed. Patch posted on Launchpad. Sleep. Now.
-j
I just committed the build fix for Windows. Now it no longer crashes. To avoid linker errors, I had to make a change to src/dom/svgimpl.cpp http://bazaar.launchpad.net/%7Einkscape.dev/inkscape/trunk/revision/12559/src/dom/svgimpl.cpp, but I am not sure it is the correct change. http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12559/src/...
If no-one complains, I guess it was broken/unused code.
Cheers, Johan
On 21-9-2013 0:51, Johan Engelen wrote:
On 20-9-2013 23:35, Markus Engel wrote:
Could it be that the current code has the problem that is described here: http://stackoverflow.com/questions/9459980/c-global-variable-not-initialized...
-Johan
Yes, that's exactly our problem. That's why we disabled libinkscape.a in the other build systems and link together all the object files directly. I just don't know how to do that in build.xml I commented on that in Launchpad.
Fixed. Patch posted on Launchpad. Sleep. Now.
-j
participants (7)
-
Bryce Harrington -
Johan Engelen -
Jon Cruz -
Krzysztof Kosiński -
Markus Engel -
su_v -
Yann Papouin