help with 64-bit dlls for libcairo

[Dmitry Karasik]

Hello all,

I'm having problem finding/installing dll files for Strawberry-64 for Cairo,
and I'd like to ask for some help. My end result is that I'd like this
command

perl -MCairo -e 1

to succeed, but everything I tried somehow fails, subtly - the module compiles
fine, but it is the runtime that gives me headaches.

I tried to use binaries from different msys and mingw64 distros, but they
somehow don't work together with the Strawberry 64, resulting in cryptic
errors like "__gxx_personality_seh0 not found in libgraphite2.dll" .

So I'm thinking of two scenarios - either if I could reproduce the Strawberry
build myself, and download the correct binaries, - but I haven't found any info
how to do that. Or, would ask someone with live build setup to copy the following
dlls for me:

libgcc_s_seh-1.dll (or is it sjlj?)
libbz2-1.dll
libcairo-2.dll
libcairo.dll.a
libexpat-1.dll
libfontconfig-1.dll
libfreetype-6.dll
libglib-2.0-0.dll
libgraphite2.dll
libharfbuzz-0.dll
libiconv-2.dll
libintl-8.dll
libpcre-1.dll
libpixman-1-0.dll
libpng16-16.dll
zlib1.dll

(or their cousins with extra __ / other version numbers)

Maybe I'm doing it completely wrong? In any case I'd rather not build these from source, if
I could avoid it.

Thank you!

--
Sincerely,
Dmitry Karasik

[sisy...@optusnet.com.au]

-----Original Message-----
From: Dmitry Karasik
Sent: Sunday, March 12, 2017 6:22 PM
To: win32-...@perl.org
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

[sisy...@optusnet.com.au]

Hi,

I've just had reason to re-visit building of glib stuff with my own builds
of perl.

Having done that, I switched attention to x64 Strawberry 5.24.1 portable:
########################################
C:\>perl -V:archname
archname='MSWin32-x64-multi-thread';

C:\>perl -le "print $^X; print $];"
C:\_64\strawberry5.24.1\perl\bin\perl.exe
5.024001
########################################

I'm building (in cmd.exe shell) against msys2 provided x64 gtk3 binaries.
Import libs and headers are in C:\_64\msys64\mingw64\lib and
C:\_64\msys64\mingw64\include.
DLLs are in C:\_64\msys64\mingw64\bin.

I wanted to ensure that perl and gcc came before C:\_64\msys64\mingw64\bin
in the
PATH so I ran:

set
Path=C:\_64\strawberry5.24.1\perl\bin;C:\_64\strawberry5.24.1\c\bin;C:\_64\msys64\mingw64\bin;%PATH%

And I set the PKG_CONFIG_PATH env var appropriately with:

set PKG_CONFIG_PATH=C:\_64\msys64\mingw64\lib\pkgconfig

Then I tried building Glib-1.324.
First thing I discovered was that Strawberry's pkg-config.bat was not up to
the job, so I removed it.
This then meant that C:\_64\msys64\mingw64\bin\pkg-config.exe would be used.

Then I discover that I need to hide the msys2 ".a" static libs from the
build - otherwise an attempt to link to them is made (rather than linking to
the ".dll.a" import libs.)
So I hide the static libs by renaming them to ".a_static".

This allows 'make' to succeed, but then 'make test' throws up "The procedure
entry point pthread_setname_np could not be located in the dynamic link
library libwinpthread-1.dll".

This happens because the Glib.dll uses the "libwinpthread-1.dll" that perl
itself loaded at start up - rather than the gtk3 libwinpthread-1.dll that it
needs to use.
Under such a condition I know of no way of coercing Glib.dll into using the
libwinpthread-1.dll that it needs to use.
I can fix this, however, by removing the libwinpthread-1.dlls that are in
C:\_64\strawberry5.24.1\perl\bin and C:\_64\strawberry5.24.1\c\bin.

Now there's only one libwinpthread-1.dll available and 'make test' succeeds
(except for the one test that usually fails for me).

Install Glib-1.324 and move on to Cairo-1.106.
I strike the same problem with some other static libs that need to be
hidden.

With those static libs hidden, we then get to 'make test', where I get:

The procedure entry point __gxx_personality_seh0 could not be located in the
dynamic link library libstdc++-6.dll.

Different dll, same problem as with Glib - so I try removing the 2 instances
of
Strawberry's libstdc++-6.dll.
But this time it doesn't work - all we get is a slightly different error
message:

The procedure entry point __gxx_personality_sj0 could not be located in the
dynamic link library libstdc++-6.dll.

So ... perl needs one version of libstdc++-6.dll, and Cairo needs a
different version - and there is no way that I know such that we can get
perl and Cairo to use different versions of the file named libstdc++-6.dll.

We're snookered.

One solution is to build Glib, Cairo, etc. against static libraries. This
something that I have *not* tried. (But it might be do-able since MSYS2
provides us with static libs.)

Another solution is to use the compiler that built the msys2 binaries
(gcc-5.4.0, I think) to build perl, and then build Glib, Cairo, etc. using
that perl/compiler/gtk combo.
Since they all have the same libstdc++-6.dll and libwinpthread-1.dll,
they should all get on famously.

Typically, when snookered lie this, I create a copy of
C:\_64\msys64\mingw64\bin\libstdc++-6.dll (in the same directory) named
(say) xxxstdc++-6.dll. Then I edit Cairo.dll (and any other dll that needs
to use C:\_64\msys64\mingw64\bin\libstdc++-6.dll) to use xxxstdc++-6.dll.

It's a dreadful hack that can involve a lot of editing and renaming (through
flow-on effects), but it *does* work.

Anyone have any other solutions ?

Cheers,
Rob