[devlibs-gtk3] Inkscape crashes with ImageMagick related commands

Apparently the crashes have different causes.

1. Opening a file from a long path triggers the following console error:
---
terminate called after throwing an instance of 'Magick::ErrorBlob'
  what(): Magick: UnableToOpenBlob `C:\Documents and Settings\All Users\Documents\Mes images\├ëchan
tillons d'images\Hiver.jpg': No such file or directory @ error/blob.c/OpenBlob/2641
----
Opening the same file from a shorter path (c:\Hiver.jpg) works.

2. Running the Oil Paint, Median and Reduce Noise raster extensions triggers a pop-up (nothing in the console) with the following messages.
--- With Oil Paint:
(inkscape.exe:1340): glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: Magick: MemoryAllocationFailed `'@ error/paint.c/OilPaintImage/619
--- With Median and Reduce Noise:
(inkscape.exe:1340): glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: Magick: MemoryAllocationFailed `'@ error/statistic.c/StatisticImageChannel/2783

3. Some other raster extensions (Add Noise, Dither), Inkscape crashes with no pop-up or console message.

All the other raster extensions work as expected (at least with the default values and the ones I have tested).

Crash 1 occurs in extension/internal/image-resolution.cpp (ImageResolution::readmagick).
The same code doesn't crash with the official devlibs.

Same issues reproduced when using imagemagick-6.8.7 (last IM version) instead of imagemagick-6.8.2 (devlibs-gtk3 version).

I've notice some type errors in the raster extensions (we use an "int" where IM expects a double, or a float instead of a size_t...), but I'm not sure it's directly related to our crashes.

Some details on crash 1:
* It's not due to the length of the path, but on the special character in "Échantillons d'images".
* The path seems to be wrong indeed, and that's the reason why the code goes to the ImageMagick fallback (it should be correctly opened by the jfif function). It's not specific to the devlibs, but affects the Inkscape trunk.
* It crashes in the IM fallback because the try/catch block doesn't catch the image.read exception (with the official devlibs, the exception is caught and ignored, and thus the imported image has a default resolution).

Thus we have two bugs for crash 1:
1.a. Wrong path when there are special characters (Inkscape trunk). Doesn't lead to a crash itself, but prevent the import code from using the image resolution.
1.b. Exception not caught in the IM fallback (devlibs-gtk3), that causes the crash.

That bug really reminds me of bug #173116 (Gtk::PixbufError exception not caught in Windows)...

... BTW, it seems that bug #173116 is back with the original devlibs.

did you build with "--shared-libgcc" ? I believe that was one of the pieces important to fix bug #173116

Also occurs when copy-pasting from an external application.

> did you build with "--shared-libgcc"

I thought the Opensuse libs were compiled with SJLJ, not DW2, and thus that the flag is not required. But since we see exceptions not caught, I guess you are right.
Unfortunately, it defeats the purpose of getting rid of manually build dependencies...

@Johan - I misunderstood your comment. libgcc needs to be shared when compiling Inkscape, not it's dependencies...
Thus adding -shared-libgcc in the build.xml file (link flags) solves issues 1 (partially) and 2, and bug #173116. Change committed revision 34. I've also added some exception handling code trunk revision 12836 to help debugging IM code.

But unfortunately Inkscape still crashes with:
1bis. Copy-pasting from an external application (again due to the ImageMagick resolution fallback).
3. Add Noise and Dither extensions.

@Jazz: i also didn't know how to apply --shared-libgcc :-)

Jazz, something just hit me: you download the binaries of a bunch of libs right? Those are built with mingw (not TDM), so they will have DW2 exception handling (right?). Then you compile some others using TDM -> SJLJ exception handling. If we are mixing exception handling styles... I'm surprised the whole thing links, actually :-) I'll see if I can build with standard mingw.

It links with standard MinGW after disabling aspell, but then Inkscape crashes on boot because it cannot find __gxx_personality_v0 in libstdc++-6.dll.