Re: help with 64-bit dlls for libcairo
[email protected] Tue, 14 Mar 2017 21:48:05 +1100
| Newsgroups | perl.win32.vanilla |
|---|---|
| Message-ID | <5735339B3DEA4C21902E4842E4C9187C@OwnerPC311012> |
-----Original Message----- From: Dmitry Karasik Sent: Sunday, March 12, 2017 6:22 PM To: [email protected] 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 or sjlj. 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 file. 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. Cheers, Rob