From: Dmitry Karasik
Sent: Sunday, March 12, 2017 6:22 PM
Subject: help with 64-bit dlls for libcairo
libgcc_s_seh-1.dll (or is it sjlj?)
It depends upon the compilers exception handling - which could dwarf2, seh
My rule is to use a compiler that provides sjlj exception handling - and I
think Strawberry does the same. (The 'gcc --version' output should mention
the flavour of exception handling.)
Hence, they'll have a libgcc_s_sjlj-1.dll but, if you need
libgcc_s_seh-1.dll then you'll have to go to a mingw64 version of gcc that
was built with seh exception handling.
And I don't know what would happen if you simply stayed with your sjlj
compiler and made a libgcc_s_seh-1.dll available.
I would more expect that if you've got a dll that's looking for
libgcc_s_seh-1.dll, then you need to switch to a gcc compiler that has that
I believe you can statically link these particular dlls (ie
libgcc_s_dw2-1.dll or libgcc_s_seh-1.dll or libgcc_s_sjlj-1.dll) into your
app - thereby ensuring that they're not required at runtime. And I think
this is the approach that Strawberry takes with libgcc_s_sjlj-1.dll.
Maybe I'm doing it completely wrong? In any case I'd rather not build
these from source, if I could avoid it.
Gtk-perl is the most frustrating thing I've ever struck.
It's now got to the stage that my Gtk+ installation is so out of date that
I'm faced with updating it if I want to continue providing useful Glib ppm
packages .... and that means again going through agonies that I'm not too
keen on re-visiting.