Cannot build Inkscape with newest Mingw, devlibs36
XP SP3, 32 bit.
I had been happily building inkscape branch lp988601 on XP using a version of mingw with gcc 4.6.2 and devlibs32. Yesterday I tried to upgrade this build environment, and while it builds to completion, the resulting inkscape does not run. Method
1. mv ming mingw_save 2. Download mingw-getinst-20120426.exe from sourceforge. Run it, install C,C++ compilers and Mingw Devel. This resulted in gcc 4.7.2 and w32api and iconv installed (the latter two had to be installed separately last time.). 5. bzr checkout --lightweight lp:inkscape-devlibs devlibs Move the folder to /c/progs/devlibs36. 6. modify mingwenv.bat in inkscape directory to use /c/progs/devlibs36. 7. g++ buildtool.cpp -o btool -fopenmp btool -version BuildTool v0.9.9multi 8. bzr revert bzr update bzr revno (11707) btool clean btool (builds to completion) inkscape\inkscape -> BOOOM! inkscape.exe has encountered a problem and needs to close. We are sorry for the inconvenience. 9. gdb file inkscape.exe inkscape.dbg run Program received signal SIGSEGV, Segmentation fault. 0x66533a06 in libglibmm-2!_ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag () from C:\progs\inkscape6\inkscape\libglibmm-2.4-1.dll (gdb) bt #0 0x66533a06 in libglibmm-2!_ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag () from C:\progs\inkscape6\inkscape\libglibmm-2.4-1.dll #1 0x664e086b in libglibmm-2!_ZN4Glib7ustringC1EPKc () from C:\progs\inkscape6\inkscape\libglibmm-2.4-1.dll #2 0x00bd9e58 in _GLOBAL__sub_I__ZN8Inkscape10FontListerC2Ev () #3 0x00d4a280 in __PRETTY_FUNCTION__.45203 () #4 0x00a5c1fc in aspell_config_retrieve () at ./common/string.hpp:79 #5 0x00000000 in ?? () 10. md5sum libglib* 18e88b04da123bf05b07ff60a4e96654 *libglib-2.0-0.dll 80c15c2a1c5d002ce72d2fa35212ad92 *libglibmm-2.4-1.dll
11. My understanding was that all of the dll's had to be recompiled to work with the newer compiler due to a change in the calling convention, however many of the dll's in devlibs36 have the same md5sum's as do the ones in devlibs32. libglibmm isn't one of these, but libglib is, as is aspell and aspell-import.
Suggestions???
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Hi,
De : mathog <mathog@...1176...> 2. Download mingw-getinst-20120426.exe from sourceforge. Run it, install C,C++ compilers and Mingw Devel. This resulted in gcc 4.7.2 and w32api and iconv installed (the latter two had to be installed separately last time.).
It's a known issue, compiling with gcc4.7 deosn't work and you need 4.6 (4.5 should also work) instead. Note that it's unrelated to the new devlibs. Compiling with r32 and gcc4.7 would also fail.
- My understanding was that all of the dll's had to be recompiled to
work with the newer compiler due to a change in the calling convention, however many of the dll's in devlibs36 have the same md5sum's as do the ones in devlibs32. libglibmm isn't one of these, but libglib is, as is aspell and aspell-import.
Some libs are downloaded directly from ftp.gnome.org, when they are provided as win32 binaries. It's the case for gtk, glib, and some dependencies. But other libs, such as glibmm, atkmm, gtkmm, cairo, cairomm, are local builds. We could of course compile everything from the source, but keep in mind that some libs are somewhat tricky to compile on Windows...
Regards, -- Nicolas
Hello, please note: you must not use the original mingw from sourceforge but the TDM-port. See: http://wiki.inkscape.org/wiki/index.php/Win32Port
The difference is the stack model; we use TDM-gcc sjlj whereas the original gcc use the dw2 model.
You can only link libraries using same model.
best regards,
Adib. -- On Tue, Nov 13, 2012 at 7:15 PM, Nicolas Dufour <nicoduf@...48...> wrote:
Hi,
De : mathog <mathog@...1176...> 2. Download mingw-getinst-20120426.exe from sourceforge. Run it, install C,C++ compilers and Mingw Devel. This resulted in gcc 4.7.2 and w32api and iconv installed (the latter two had to be installed separately last time.).
It's a known issue, compiling with gcc4.7 deosn't work and you need 4.6 (4.5 should also work) instead. Note that it's unrelated to the new devlibs. Compiling with r32 and gcc4.7 would also fail.
- My understanding was that all of the dll's had to be recompiled to
work with the newer compiler due to a change in the calling convention, however many of the dll's in devlibs36 have the same md5sum's as do the ones in devlibs32. libglibmm isn't one of these, but libglib is, as is aspell and aspell-import.
Some libs are downloaded directly from ftp.gnome.org, when they are provided as win32 binaries. It's the case for gtk, glib, and some dependencies. But other libs, such as glibmm, atkmm, gtkmm, cairo, cairomm, are local builds. We could of course compile everything from the source, but keep in mind that some libs are somewhat tricky to compile on Windows...
Regards,
Nicolas
Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
OK, will fall back to previous mingw.
On 13-Nov-2012 11:26, the Adib wrote:
Hello, please note: you must not use the original mingw from sourceforge but the TDM-port. See: http://wiki.inkscape.org/wiki/index.php/Win32Port
The difference is the stack model; we use TDM-gcc sjlj whereas the original gcc use the dw2 model.
You can only link libraries using same model.
Except that has never been the case in my experience. I have always used the mingw from sourceforge and it has worked fine. (Well, except until the Mingw upgrade that brought in the 4.7.2 compiler.) In build.xml there is a reference to an ligcc_s_sjlj-1.dll. Other than linking to that dll, how else does the compiler know what type of exception handling to use, compiler or switch maybe?
Is it maybe the case that gcc 4.7.2 for windows finally changed from sjlj to dw2 exception handling and that is what is breaking things?
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Did you try the gcc 4.7 with the sjlj stack from TDM?
Adib.
On Tue, Nov 13, 2012 at 8:49 PM, mathog <mathog@...1176...> wrote:
OK, will fall back to previous mingw.
On 13-Nov-2012 11:26, the Adib wrote:
Hello, please note: you must not use the original mingw from sourceforge but the TDM-port. See: http://wiki.inkscape.org/wiki/index.php/Win32Port
The difference is the stack model; we use TDM-gcc sjlj whereas the original gcc use the dw2 model.
You can only link libraries using same model.
Except that has never been the case in my experience. I have always used the mingw from sourceforge and it has worked fine. (Well, except until the Mingw upgrade that brought in the 4.7.2 compiler.) In build.xml there is a reference to an ligcc_s_sjlj-1.dll. Other than linking to that dll, how else does the compiler know what type of exception handling to use, compiler or switch maybe?
Is it maybe the case that gcc 4.7.2 for windows finally changed from sjlj to dw2 exception handling and that is what is breaking things?
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 11/14/2012 04:04, the Adib wrote:
Did you try the gcc 4.7 with the sjlj stack from TDM?
Adib.
On Tue, Nov 13, 2012 at 8:49 PM, mathog <mathog@...1176...> wrote:
OK, will fall back to previous mingw.
On 13-Nov-2012 11:26, the Adib wrote:
Hello, please note: you must not use the original mingw from sourceforge but the TDM-port. See: http://wiki.inkscape.org/wiki/index.php/Win32Port
The difference is the stack model; we use TDM-gcc sjlj whereas the original gcc use the dw2 model.
You can only link libraries using same model.
Listen, it's deeper than that, C/C++ ABI between GCC 4.6 and 4.7 for Win32 has also changed, but mangling did not. So you could link, but the final results will not work.
On 14-Nov-2012 02:57, JonY wrote:
Listen, it's deeper than that, C/C++ ABI between GCC 4.6 and 4.7 for Win32 has also changed, but mangling did not. So you could link, but the final results will not work.
How then does the mingw with the 4.7 itself work? Is it maybe all C code and not affected by this C++ specific change?
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 11/15/2012 01:07, mathog wrote:
On 14-Nov-2012 02:57, JonY wrote:
Listen, it's deeper than that, C/C++ ABI between GCC 4.6 and 4.7 for Win32 has also changed, but mangling did not. So you could link, but the final results will not work.
How then does the mingw with the 4.7 itself work? Is it maybe all C code and not affected by this C++ specific change?
The -mms-bitfields option is now on by default, struct offset alignments has changed. In C++ __thiscall is now used for non-variadic class methods.
If you don't know what these means, it means the underlying code generated by GCC has changed and no longer compatible with older pre-compiled code.
participants (4)
-
JonY -
mathog -
Nicolas Dufour -
the Adib