Build Image::Magick from MSYS2 using Strawberry Perl gcc and perl

[hakonhagland]

Refer to #138 for background. I would like to try to build Image::Magick with Strawberry Perl. On Linux I can build the module using:

$ ./configure --with-perl=/home/hakon/perlbrew/perls/perl-5.38.0/bin/perl --prefix=/opt/image-magick
$ make
$ sudo make install

In #138 ït was suggested to use MSYS2, quote from @sysiphus:

IIUC, it should be pretty much the same with Strawberry Perl, but you'll be running the commands in the MSYS2 shell.
I take it that the --with-perl argument designates which perl is to be used for the building of the ImageMagick library.
So you could use MSYS2 perl for that - which might make it easier wrt the Cairo stuff that @shawnlaffan mentioned.
You would want to ensure that, in the MSYS2 shell, gcc identifies StrawberryPerl's C compiler, so you might need to modify MSYS2's path for that,

Also @sysiphus reported later in that issue:

Eventually it terminates with:
CC coders/MagickCore_libMagickCore_7_Q16HDRI_la-tiff.lo
coders/tiff.c:109:13: fatal error: zstd.h: No such file or directory
109 | # include <zstd.h>
| ^~~~~~~~
compilation terminated.
make[1]: *** [Makefile:10344: coders/MagickCore_libMagickCore_7_Q16HDRI_la-tiff.lo] Error 1
make[1]: Leaving directory '/d/s/ImageMagick'
make: *** [Makefile:6243: all] Error 2

@sisyphus As a first step, I tried to reproduce the error you got. However, I got a different error:

• I have installed MSYS2 previously,
• downloaded the ImageMagick main branch
• Found paths to Strawberry Perl and gcc:

$ /c/Strawberry/c/bin/gcc.exe --version
gcc.exe (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /c/Strawberry/perl/bin/perl.exe --version
This is perl 5, version 38, subversion 0 (v5.38.0) built for MSWin32-x64-multi-thread

• Modified PATH and ran configure and then make:

$ export PATH=/c/Strawberry/c/bin:$PATH

$  ./configure --with-perl=/c/Strawberry/perl/bin/perl.exe 2>&1 | tee configure_log.txt

$ make 2>&1 | tee make_log.txt
[...]
  CC       coders/MagickCore_libMagickCore_7_Q16HDRI_la-jpeg.lo
  CC       filters/MagickCore_libMagickCore_7_Q16HDRI_la-analyze.lo
  CCLD     MagickCore/libMagickCore-7.Q16HDRI.la
C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: MagickCore\\.libs\\libMagickCore_7_Q16HDRI_la-blob.o: in function `EOFBlob':
C:\msys2\home\hakon\test\ImageMagick/MagickCore/blob.c:1270: undefined reference to `BZ2_bzerror'
C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: MagickCore\\.libs\\libMagickCore_7_Q16HDRI_la-blob.o: in function `ErrorBlob':
[...]
collect2.exe: error: ld returned 1 exit status
make[1]: *** [makefile:7214: MagickCore/libMagickCore-7.Q16HDRI.la] Error 1
make[1]: Leaving directory 'C:/msys2/home/hakon/test/ImageMagick'
make: *** [makefile:6243: all] Error 2

Here are the complete log files from configure and make: configure_log.txt and make_log.txt.

[shawnlaffan]

It would seem the perl path is only needed to compile the perl bindings at the same time as the main ImageMagick system.

Compiling the bindings separately might be a simpler approach.

From https://imagemagick.org/script/advanced-linux-installation.php (with added linebreaks for readability):

--without-perl 	disable build/install of PerlMagick, or

By default, PerlMagick is conveniently compiled and installed as part of 
ImageMagick's normal configure, make, sudo make install process. 
When --without-perl is specified, you must first  install ImageMagick, 
change to the PerlMagick subdirectory, build, and finally install PerlMagick. 
Note, PerlMagick is configured even if --without-perl is specified. 
If the argument --with-perl=/path/to/perl is supplied, 
/../path/to/perl is be taken as the PERL interpreter to use. 
This important in case the perl executable in your PATH is not PERL5, 
or is not the PERL you want to use.

[hakonhagland]

Can't we just build and install ImageMagick, then build PerlMagick against that installed library?

Maybe. Let me try this on Linux first

@sisyphus It did not work for me on Linux, added bug report here: ImageMagick/ImageMagick#6763

[hakonhagland]

The Makefile.PL has some instructions specifically for Strawberry Perl, including:

# 1) You need to have installed ImageMagick Windows binaries from
# https://imagemagick.org/script/binary-releases.php#windows

@sisyphus Interesting. I also found this site for building ImageMagick using Visual Studio on Windows:

https://github.com/ImageMagick/ImageMagick-Windows

It could be interesting to test, but not sure if it will help with building the Perl module

[hakonhagland]

the modified PATH is reset to some default value within this new shell

Added a discussion for how to pass the updated PATH to the libtool shell here:

ImageMagick/ImageMagick#6766

[sisyphus]

Of course, I can't be certain of that until I work out how to work around that error.

Turned out to be fairly simple. Here's the procedure I followed from start to finish.

In MSYS2's (or Cygwin's) bash shell, clone the current github ImageMagick into D:\s\ImageMagick:

$ git clone https://github.com/ImageMagick/ImageMagick /cygdrive/d/s/ImageMagick3

In MSYS2 shell, build this source using the same compiler that StrawberryPerl uses.
This compiler is available from:
https://github.com/brechtsanders/winlibs_mingw/releases/download/13.1.0-16.0.5-11.0.0-msvcrt-r5/winlibs-x86_64-posix-seh-gcc-13.1.0-mingw-w64msvcrt-11.0.0-r5.zip
Use that compiler in preference to the one that ships with StrawberryPerl, as the one that ships with StrawberryPerl has (for our intents and purposes) been polluted by the inclusion of some 3rd party libraries.
It seems that we need to use the msys2 version of those "pollutent" libraries, rather than StrawberryPerl's version.
(At least, using StrawberryPerl's compiler, the ImageMagick github source won't build successfully.)
For me, this gcc-13.1.0 has been installed in C:\winpos-gcc-1310\mingw64\bin.
My (portable) StrawberryPerl is in C:/sp/_64/sp-5.38.0-PDL
I need to install the ImageMagick library into StrawberryPerl's c/bin, c/lib and c/include folders.

Owner@DESKTOP-88J497T MINGW64 ~
$ gcc --version
-bash: gcc: command not found
Owner@DESKTOP-88J497T MINGW64 ~
$ export PATH=$PATH:/c/winpos-gcc-1310/mingw64/bin
Owner@DESKTOP-88J497T MINGW64 ~
$ gcc --version
gcc.exe (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Owner@DESKTOP-88J497T MINGW64 ~
$ cd /d/s/ImageMagick3
Owner@DESKTOP-88J497T MINGW64 /d/s/ImageMagick3
$ ./configure --prefix=/c/sp/_64/sp-5.38.0-PDL/c CPPFLAGS=-I/c/winpos-gcc-1310/mingw64/include LDFLAGS=-L/c/winpos-gcc-1310/mingw64/lib

Then, when 'configure' step has completed, we build using MSYS2's 'make' utility:
$ make
Then, when 'make' step has completed:
$ make check
For me, 4 of the 87 test files reported "FAIL". All others passed.
Then, when 'make check' has concluded:
$ make install

In C:\sp_64\sp-5.38.0-PDL\c\lib, create a copy of the newly installed libMagickCore-7.Q16HDRI.dll.a, named libMagickCore.dll.a (because the Image-Magick-7.1.1 build expects the import library to have the shortened name).

Then, open up a new cmd.exe shell running StrawberryPerl.
In that shell 'cd' to the unpacked Image-Magick-7.1.1 source:

C:\sp_64\sp-5.38.0-PDL>D:
D:>cd \s\Image-Magick-7.1.1
D:\s\Image-Magick-7.1.1> set CPATH=%CPATH%;C:\sp_64\sp-5.38.0-PDL\c\include\ImageMagick-7
D:\s\Image-Magick-7.1.1> set LIBRARY_PATH=%LIBRARY_PATH%;C:\sp_64\sp-5.38.0-PDL\c\lib\ImageMagick-7


Because I've built in the MSYS shell, there are some dlls in D:\msys64\mingw64\bin that need to be found for the Image-Magick-7.1.1 (perl module) build to succeed.
They also need to be found when the Image-Magick-7.1.1 (perl module) is loaded.
So I also append D:\msys64\mingw64\bin to the PATH:

D:\s\Image-Magick-7.1.1> set PATH=%PATH%;D:\msys64\mingw64\bin


To make sure this perl build I'm about to do doesn't reference any ImageMagick dlls in D:\msys64\mingw64\bin (placed there earlier by pacman), I rename the extension of those 3 dlls from ".dll" to ".dll_hide".

The following patch to C://sp/_64/sp-5.38.0-PDL/c/include/ImageMagick-7/MagickCore/magick-config.h provides a fairly simple hack that enables the perl module to build.
All it does is comment out 3 short sections of pre-processing code:

$ diff -wu magick-config.h_orig magick-config.h
--- magick-config.h_orig        2023-10-08 16:28:51.606113500 +1100
+++ magick-config.h     2023-10-08 15:39:20.749668400 +1100
@@ -66,9 +66,11 @@
 #endif

 /* Number of bits in a pixel Quantum (8/16/32/64) */
+/*
 #ifndef MAGICKCORE_QUANTUM_DEPTH
 # error "you should set MAGICKCORE_QUANTUM_DEPTH"
 #endif
+*/

 /* check values */
 #if MAGICKCORE_QUANTUM_DEPTH != 8
@@ -82,9 +84,11 @@
 #endif

 /* whether HDRI is enable */
+/*
 #if !defined(MAGICKCORE_HDRI_ENABLE)
 # error "you should set MAGICKCORE_HDRI_ENABLE"
 #endif
+*/

 #if MAGICKCORE_HDRI_ENABLE
 # define MAGICKCORE_HDRI_SUPPORT 1
@@ -117,9 +121,11 @@
 #endif

 /* whether HDRI is enable */
+/*
 #if !defined(MAGICKCORE_HDRI_ENABLE)
 # error "you should set MAGICKCORE_HDRI_ENABLE"
 #endif
+*/

 #if MAGICKCORE_HDRI_ENABLE
 # define MAGICKCORE_HDRI_SUPPORT 1

Then run perl Makefile.PL, gmake test, gmake install.

Cheers,
Rob

[hakonhagland]

The following patch to C://sp/_64/sp-5.38.0-PDL/c/include/ImageMagick-7/MagickCore/magick-config.h provides a fairly simple hack that enables the perl module to build.

@sisyphus It would be interesting to know more details on why this hack is needed..

[hakonhagland]

error "MAGICKCORE_QUANTUM_DEPTH is not 8/16/32/64 bits"

Added possible fix here: ImageMagick/ImageMagick#6770

[hakonhagland]

Refer to: #139 (comment) :

Use that compiler in preference to the one that ships with StrawberryPerl, as the one that ships with StrawberryPerl has (for our intents and purposes) been polluted by the inclusion of some 3rd party libraries.
It seems that we need to use the msys2 version of those "pollutent" libraries, rather than StrawberryPerl's version.

@sisyphus Maybe we should investigate this more? It would be better if we could use the one that ships with StrawberryPerl, right?

[shawnlaffan]

It would be good to know which libraries aren't working.

It could be clashes where SP provides DLLs that are also provided by Winlibs, e.g. there is libbz.dll (Winlibs) and libbz2-1__.dll (SP).

Previous discussion starts here: #57 (comment)

[sisyphus]

It would be good to know which libraries aren't working.

@shawnlaffan, I re-tried building with StrawberryPerl's compiler and struck no significant issues this time. (Dunno what happened last time, when it all went to shit.)

So ... for the msys2 build of ImageMagick, I appended my Strawberry c/bin to the PATH, set CPPFLAGS to the location of Strawberry c/include, set LDFLAGS to the location of Strawberry c/lib and set --prefix to the location of Strawberry c folder.

However, I think the build used the stuff in the MSYS2 installation - and probably no stuff (except for the compiler) from Strawberry Perl.
'make check' failed the 4 usual files, and 'make install' put the completed build into the appropriate places within my Strawberry location.

When building Image-Magick-7.1.1 (which is done in the cmd.exe shell that my portableshell.bat opens up), I had to append D:\msys64\mingw32\bin to the PATH to get 'gmake test' to succeed.
And I still need to have D:\msys64\mingw\bin in the PATH to use the module. (It is, however, using the ImageMagick dlls that were installed (by MSYS2's 'make install') into Strawberry's c/bin folder.

There's at least 50 dlls from my MSYS2 installation that are needed at Inage-Magick-7.1.1 runtime. (I got sick of trying to track them all down.)

Cheers,
Rob

[hakonhagland]

This thread has now become so long that I think it will be difficult to follow it in the future. Would it be an idea to create separate documentation for how to install Perl XS modules under Strawberry Perl? For example a main document "Installing-XS-modules.md" with links to sub documents for specific modules, like "Image-Magick.md" ? Then we could condense (make more readable) the findings that we have done in this thread (#139) into that documentation file (the steps needed to install the module) for the future. What do you think @shawnlaffan and @sisyphus ?

[genio]

@hakonhagland Start using the Wiki to make said .md and once ironed out sufficiently there, we can either put it in the main repo or just link to it.

[hakonhagland]

Start using the Wiki to make said .md

@genio Good idea, I created a new issue for this here: #141 where we can continue the discussion.

[hakonhagland]

Refer to #139 (comment)

And I still need to have D:\msys64\mingw\bin in the PATH to use the module.

@sisyphus We should investigate this further, we do not want any dependencies back to msys2 after the perl module has been installed, right? Then, for example if you later choose to delete MSYS2 from your machine the perl module will stop to work.

[shawnlaffan]

The list of DLL dependencies can be obtained using App::PP::AutoLink. Use that to pack a perl file that uses Image::Magick. The list of detected DLLs is printed to the console and can then be edited to copy the needed files to a new location.

I should really extract the DLL search logic into something cleaner but it will work well enough if it's a one-off process.

I've already used it to package the Gtk2 files as an Alien module (there are also PPMs for 5.38 if anyone is interested - look under the releases). https://github.com/shawnlaffan/perl-alien-gtkstack-windows/

[sisyphus]

@sisyphus](https://github.com/sisyphus) We should investigate this further, we do not want any dependencies back to msys2 after the perl module has been installed, right?

Personally, that doesn't bother me too much.
But I think it's fair enough to want to avoid that dependency

Is the solution just proposed by @shawnlaffan acceptable ?
Building in the MSYS2 shell apparently creates dependencies on thegtk2/3 dlls - and those dlls need to be found at runtime.

You could look at building against the standalone MSVC ImageMagick library that ImageMagick-7.1.1-19-Q16-HDRI-x64-dll.exe installs.
For me, that library needs just just one hack - line 279 of its ImageMagick-7.1.1-Q16-HDRI\include/MagickCore/magick-baseconfig.h needs to be commented out.
Append the location of the ImageMagick-7.1.1-Q16-HDRI library to the PATH.
Then Image-Magick-7.1.1 (perl module) builds straight out of the box on Strawberry Perl.

---------------------------------------------- Welcome to Strawberry Perl Portable Edition! * URL - http://www.strawberryperl.com/ * see README.TXT for more info ---------------------------------------------- Perl executable: C:\sp\_64\sp-5.38.0\perl\bin\perl.exe Perl version : 5.38.0 / MSWin32-x64-multi-thread

C:\sp_64\sp-5.38.0>D:

D:>set PATH=%PATH%;C:\d\ImageMagick-7.1.1-Q16-HDRI

D:>cd \s\Image-Magick-7.1.1

D:\s\Image-Magick-7.1.1>perl Makefile.PL
Gonna create 'libMagickCore.a' from 'C:\d\ImageMagick-7.1.1-Q16-HDRI\CORE_RL_MagickCore_.dll'
Checking if your kit is complete...
Looks good
Generating a gmake-style Makefile
Writing Makefile for Image::Magick
Writing MYMETA.yml and MYMETA.json

D:\s\Image-Magick-7.1.1-5>gmake test
Running Mkbootstrap for Magick ()
"C:\sp_64\sp-5.38.0\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 644 "Magick.bs"
"C:\sp_64\sp-5.38.0\perl\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- Magick.bs blib\arch\auto\Image\Magick\Magick.bs 644
"C:\sp_64\sp-5.38.0\perl\bin\perl.exe" "C:\sp_64\sp-5.38.0\perl\lib\ExtUtils/xsubpp" -typemap C:\sp_64\sp-5.38.0\perl\lib\ExtUtils\typemap -typemap D:\s\Image-Magick-7.1.1-5\typemap Magick.xs > Magick.xsc
"C:\sp_64\sp-5.38.0\perl\bin\perl.exe" -MExtUtils::Command -e mv -- Magick.xsc Magick.c
gcc -c -I"C:\d\ImageMagick-7.1.1-Q16-HDRI\include" -DWIN32 -DWIN64 -D__USE_MINGW_ANSI_STDIO -fdiagnostics-color=never -DPERL_TEXTMODE_SCRIPTS -DMULTIPLICITY -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D__USE_MINGW_ANSI_STDIO -fwrapv -fno-strict-aliasing -mms-bitfields -Os -DVERSION="7.1.1" -DXS_VERSION="7.1.1" "-IC:\sp_64\sp-5.38.0\perl\lib\CORE" -D_LARGE_FILES=1 -DHAVE_CONFIG_H Magick.c
"C:\sp_64\sp-5.38.0\perl\bin\perl.exe" -MExtUtils::Mksymlists
-e "Mksymlists('NAME'=>"Image::Magick", 'DLBASE' => 'Magick', 'DL_FUNCS' => { }, 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);"
g++.exe Magick.def -o blib\arch\auto\Image\Magick\Magick.xs.dll -mdll -s -L"C:\sp_64\sp-5.38.0\perl\lib\CORE" -L"C:\sp_64\sp-5.38.0\c\lib" -L"D:/s/Image-Magick-7.1.1-5" -L"C:\d\ImageMagick-7.1.1-Q16-HDRI\lib" Magick.o "C:\sp_64\sp-5.38.0\perl\lib\CORE\libperl538.a" "libMagickCore.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libmoldname.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libkernel32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libuser32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libgdi32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libwinspool.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libcomdlg32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libadvapi32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libshell32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libole32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\liboleaut32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libnetapi32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libuuid.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libws2_32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libmpr.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libwinmm.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libversion.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libodbc32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libodbccp32.a" "C:\sp_64\sp-5.38.0\c\x86_64-w64-mingw32\lib\libcomctl32.a" -Wl,--enable-auto-image-base
"C:\sp_64\sp-5.38.0\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 755 blib\arch\auto\Image\Magick\Magick.xs.dll
cp Magick.pm blib\lib\Image\Magick.pm
AutoSplitting blib\lib\Image\Magick.pm (blib\lib\auto\Image\Magick)
"C:\sp_64\sp-5.38.0\perl\bin\perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/.t
t/blob.t .......... ok
t/composite.t ..... ok
t/filter.t ........ ok
t/getattribute.t .. ok
t/montage.t ....... ok
t/ping.t .......... ok

t/read.t .......... ok
t/setattribute.t .. ok
t/write.t ......... ok
All tests successful.
Files=9, Tests=273, 2 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU)
Result: PASS

D:\s\Image-Magick-7.1.1>

Initially, I had trouble with t/ping.t hanging ... but that's not happening any more.
It seems that, if this ImageMagick-7.1.1-Q16-HDRI installation is in the path, then there's no need to specify CPATH or LIBRARY_PATH.

Of course, you still need ImageMagick-7.1.1-Q16-HDRI in Strawberry Perl's PATH.
I reckon (untested) you could install the entire ImageMagick-7.1.1-Q16-HDRI installation into Strawberry's c/bin/ImageMagick-7.1.1-Q16-HDR folder, append that folder to the PATH (in the portableshell.bat) and then Image-Magick-7.1.1 is all ready to build/test/install/run as soon as you open up a new shell.

I now don't know where I got this ImageMagick-7.1.1-19-Q16-HDRI-x64-dll.exe from.
It's mentioned somewhere in one of these current ImageMagick discussions.

You need to tell the installer (when prompted) to install the extra (essential) stuff, and remember that magick-baseconfig.h needs that simple fix mentioned earlier in this post.

Cheers,
Rob

[shawnlaffan]

The advantage of the Alien approach is that it saves the files under .../site/lib/auto/share. The Alien package then adds itself to the path when it is used on the right OS and build type, and is a no-op otherwise (at least that's how I've implemented Alien::GtkStack::Windows). One could also probably use File::ShareDir directly but the Alien infrastructure makes installation and use easier.

The limitation is that each calling script needs a use Alien::XYZ statement at the top, or the PERL5OPT variable needs to be updated.

[hakonhagland]

but the Alien infrastructure makes installation and use easier.

@shawnlaffan Does this mean that the needed libraries can be packed together with the Alien? So there will be no need to install Image::Magick from source (or download the binary release) before installing the perl module? That would be great!

A quick search on metacpan shows that a alien module already exists: https://metacpan.org/pod/Alien::ImageMagick
Wonder why the Perl module Image::Magick is not using it for windows?
As I understand, then when Image::Magick is installed on windows it could check if libraries are missing and then install Alien::ImageMagick if needed to get the libraries?

[hakonhagland]

Referring to #139 (comment) and #139 (comment) :

$ make 2>&1 | tee make_log.txt
[...]
C:\msys2\home\hakon\test\ImageMagick/MagickCore/blob.c:1270: undefined reference to `BZ2_bzerror'

Going back to my initial attempt at building, it would be interesting to know more about this linker error so I created a separate issue for this here: ImageMagick/ImageMagick#6777

[shawnlaffan]

@shawnlaffan Does this mean that the needed libraries can be packed together with the Alien? So there will be no need to install Image::Magick from source (or download the binary release) before installing the perl module? That would be great!

Yes, that is the general principle. For the Gtk2 case all the relevant files from the bin, lib and share dirs have been packed.

A quick search on metacpan shows that a alien module already exists: https://metacpan.org/pod/Alien::ImageMagick Wonder why the Perl module Image::Magick is not using it for windows? As I understand, then when Image::Magick is installed on windows it could check if libraries are missing and then install Alien::ImageMagick if needed to get the libraries?

Alien::ImageMagick uses an older style approach that also does not work on Windows since it uses Unix syntax. It should be possible to update it to use Alien::Build but there would still be the need to get all the dependencies in place. That is perhaps best done using a second Alien, or it could be done as a build step on Windows.

[hakonhagland]

It should be possible to update it to use Alien::Build but there would still be the need to get all the dependencies in place. That is perhaps best done using a second Alien, or it could be done as a build step on Windows.

@shawnlaffan Created a new issue to track this idea, see #142