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