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
