StrawberryPerl / Perl-Dist-Strawberry

Tooling to build and package releases for Perl on Windows.
https://strawberryperl.com
Other
278 stars 48 forks source link

Trying to use ppm, cpanm and manual installation of Image::Magick to no avail #140

Open Jodyman-722 opened 11 months ago

Jodyman-722 commented 11 months ago

Trying to load Image-Magick-7.1.1-18.tar.gz onto Strawberry Perl V 5.32.1 built for MSWin32-x64-multi-thread, I get the following error in all the logs after perl Makefile.PL has run successfully and created 'libMagickCOre.a', and gmake creates this error:

C:\Program Files\ImageMagick-7.1.1-Q16\include/MagickCore/magick-baseconfig.h:279:6: **error: #error ImageMagick was build with a 64 channel bit mask and that requires a C++ compiler**
 #    error ImageMagick was build with a 64 channel bit mask and that requires a C++ compiler

I had already downloaded and installed the latest version of the Microsoft Visual C++ Redistributable package: VC_redist.x64.exe

Any help would be appreciated

hakonhagland commented 11 months ago

Image-Magick-7.1.1-18.tar.gz

@Jodyman-722 Are you referring to this bundle: https://github.com/ImageMagick/ImageMagick/archive/refs/tags/7.1.1-18.tar.gz ? Then I think you need to build the libraries first. See https://github.com/ImageMagick/ImageMagick-Windows for more information for building on Windows using Visual Studio. We are also working on building the Perl module in https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/139 and https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/138

twata1 commented 11 months ago

Perhaps Image::Magick is not supported by the latest ImageMagick switch to C++, in my opinion.

https://github.com/ImageMagick/ImageMagick/issues/6667#issuecomment-1731374988

In my case, on Strawberry Perl, I successfully built Image::Magick v7.1.0-0 using ImageMagick-7.1.1-12-Q16-HDRI-x64-dll.exe, but not Image::Magick v7.1.1-18 using ImageMagick-7.1.1-17-Q16-HDRI-x64-dll.exe.

shawnlaffan commented 11 months ago

The Visual Studio instructions are unlikely to work with Strawberry Perl as it uses a mingw gcc-based toolchain.

There is also a C++ compiler with strawberry perl. Look for g++.exe and c++.exe under the ...\c\bin directory.

Overall, though, the topic of this issue would seem to be already under discussion in #139

hakonhagland commented 11 months ago

Are you referring to this bundle: https://github.com/ImageMagick/ImageMagick/archive/refs/tags/7.1.1-18.tar.gz ?

@Jodyman-722 Sorry, I think I misunderstood. This is the full ImageMagick source (including PerlMagick), but you might be referring to just the PerlMagick sub directory? I now found that part here: https://imagemagick.org/archive/perl/Image-Magick-7.1.1-18.tar.gz

twata1 commented 11 months ago

It appears that Image::Magick v7.1.1-20 has just been released on metacpan. Perhaps it can be built using ImageMagick-7.1.1-20-Q16-HDRI-x64-dll.exe. (I have not tried mine yet.)

Edit: Sorry. I couldn't build it.

sisyphus commented 11 months ago

Perhaps it can be built using ImageMagick-7.1.1-20-Q16-HDRI-x64-dll.exe.

One problem with that executable is that it doesn't install the headers. From where does one obtain those files ? They also don't prpvide any import libraries - though those libraries can be generated from the dlls easily enough.

It turns out that when I built Image-Magick for mingw-built perl those few years ago, I did so against ImageMagick-6.9.2-5-Q16-HDRI. At that time they provided the headers, though I still had to construct the gcc-compatible import libs. (They did, at least provide MSVC-compatible import libs ('.lib') back then - but they are also missing from this latest release, AFAICS.)

Cheers, Rob

twata1 commented 11 months ago

@sisyphus

One problem with that executable is that it doesn't install the headers. From where does one obtain those files ?

During the installation process, I check the areas enclosed in the red box below.

Setup-ImageMagick-7 1 1-2--Q16-HDRI(64-bit)

And Check "Install legacy utilities (e.g. convert)" and proceed with the installation. After open the command prompt and adding the path to ImageMagick to the PATH environment variable and "cpan Image::Magick", previously that build was successful, as shown in the link below..

http://www.cpantesters.org/cpan/report/784aa14d-6e80-1014-a530-7500f0aa1848

Thank you,

Jodyman-722 commented 11 months ago

Wow, didn't know I'd get so many responses. Sorry, don't check my e-mail a lot. Yes, I had been talking about

Image-Magick-7.1.1-18.tar.gz

I do finally see Image-Magic-7.1.1-20.tar.gz available as well.

I think ya'll are on to something and it has to be the C++ compiler that comes with Strawberry Perl.

According to ImageMagick website, they say to download the latest Microsoft Visual C++ Redistributable Package:

VC_redist.x64.exe

I have installed that but I see Strawberry is using it's own version of gcc.

I don't know how to make it use the latest Microsoft VS 2022 C++ that Image Magic was created with. I think that is what the problem is.

Anyone know more about the build process that can help me figure this out? I'm sure everyone with Strawberry Perl is having the same issue. It does not affect version 7.1.1-12 which compiles just fine.

Thanks in advance!

Jody

Jodyman-722 commented 11 months ago

Looking at Strawberry Perl 5.32.1 Compiler: cc='gcc' ccflags =' -DWIN32 -DWIN64 -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields' optimize='-s -O2' cppflags='-DWIN32' ccversion='' gccversion='8.3.0' gccosandvers='' intsize=4 longsize=4 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long long' ivsize=8 nvtype='double' nvsize=8 Off_t='long long' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='g++' ldflags ='-s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"' libpth=C:\STRAWB~1\c\lib C:\STRAWB~1\c\x86_64-w64-mingw32\lib C:\STRAWB~1\c\lib\gcc\x86_64-w64-mingw32\8.3.0 libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc= so=dll useshrplib=true libperl=libperl532.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs dlext=xs.dll d_dlsymun=undef ccdlflags=' ' cccdlflags=' ' lddlflags='-mdll -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"'

Image Magic is using: convert --version Version: ImageMagick 7.1.1-18 Q16 x64 44b2ac8:20230923 https://imagemagick.org Copyright: (C) 1999 ImageMagick Studio LLC License: https://imagemagick.org/script/license.php Features: Channel-masks(64-bit) Cipher DPC Modules OpenCL OpenMP(2.0) Delegates (built-in): bzlib cairo flif freetype gslib heic jng jp2 jpeg jxl lcms lqr lzma openexr pangocairo png ps raqm raw rsvg tiff webp xml zip zlib Compiler: Visual Studio 2022 (193532217)

At the command line: gcc and c++ all come back to Strawberry Perl install of gcc with wrapper for c++:

c:\Strawberry\perl\site\bin>gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=C:/Strawberry/c/bin/../libexec/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-8.3.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/opt/build/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/opt/build/prerequisites/x86_64-w64-mingw32-static --with-mpc=/opt/build/prerequisites/x86_64-w64-mingw32-static --with-isl=/opt/build/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh, Built by strawberryperl.com project' --with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/opt/build/x86_64-830-posix-seh-rt_v6/mingw64/opt/include -I/opt/build/prerequisites/x86_64-zlib-static/include -I/opt/build/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/opt/build/x86_64-830-posix-seh-rt_v6/mingw64/opt/include -I/opt/build/prerequisites/x86_64-zlib-static/include -I/opt/build/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=' -I/opt/build/x86_64-830-posix-seh-rt_v6/mingw64/opt/include -I/opt/build/prerequisites/x86_64-zlib-static/include -I/opt/build/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/opt/build/x86_64-830-posix-seh-rt_v6/mingw64/opt/lib -L/opt/build/prerequisites/x86_64-zlib-static/lib -L/opt/build/prerequisites/x86_64-w64-mingw32-static/lib ' LD_FOR_TARGET=/opt/build/x86_64-830-posix-seh-rt_v6/mingw64/bin/ld.exe Thread model: posix gcc version 8.3.0 (x86_64-posix-seh, Built by strawberryperl.com project)

c:\Strawberry\perl\site\bin>c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=C:/Strawberry/c/bin/../libexec/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-8.3.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/opt/build/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/opt/build/prerequisites/x86_64-w64-mingw32-static --with-mpc=/opt/build/prerequisites/x86_64-w64-mingw32-static --with-isl=/opt/build/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh, Built by strawberryperl.com project' --with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/opt/build/x86_64-830-posix-seh-rt_v6/mingw64/opt/include -I/opt/build/prerequisites/x86_64-zlib-static/include -I/opt/build/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/opt/build/x86_64-830-posix-seh-rt_v6/mingw64/opt/include -I/opt/build/prerequisites/x86_64-zlib-static/include -I/opt/build/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=' -I/opt/build/x86_64-830-posix-seh-rt_v6/mingw64/opt/include -I/opt/build/prerequisites/x86_64-zlib-static/include -I/opt/build/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/opt/build/x86_64-830-posix-seh-rt_v6/mingw64/opt/lib -L/opt/build/prerequisites/x86_64-zlib-static/lib -L/opt/build/prerequisites/x86_64-w64-mingw32-static/lib ' LD_FOR_TARGET=/opt/build/x86_64-830-posix-seh-rt_v6/mingw64/bin/ld.exe Thread model: posix gcc version 8.3.0 (x86_64-posix-seh, Built by strawberryperl.com project)

Anyone know how to have gmake use Microsoft Visual C++ 2022 instead of gcc v8.3.0 and would this fix the issue?

Any help appreciated!

shawnlaffan commented 11 months ago

@Jodyman-722 - The Visual Studio files won't work with Strawberry Perl since it uses a mingw gcc toolchain (https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/140#issuecomment-1751484398). There has been good progress with the builds, documented in #139 (although it is now a relatively long thread).

Jodyman-722 commented 11 months ago

By the way, the reason this is so important, is because of the zero day vulnerability with Image Magick and version before 7.1.1.17 has a vulnerability with .webp images. It was fixed in Image Magic version 7.1.1.17.

I never had a problem with Image::Magic Perl Module until Image Magic changed their c++ compiler to Microsoft.

Again: Issue in gmake of:

C:\Program Files\ImageMagick-7.1.1-Q16\include/MagickCore/magick-baseconfig.h:279:6: error: #error ImageMagick was build with a 64 channel bit mask and that requires a C++ compiler

error ImageMagick was build with a 64 channel bit mask and that requires a C++ compiler

Jodyman-722 commented 11 months ago

@shawnlaffan

@Jodyman-722 - The Visual Studio files won't work with Strawberry Perl since it uses a mingw gcc toolchain (#140 (comment)). There has been good progress with the builds, documented in #139 (although it is now a relatively long thread).

I guess we are at an impasse then. I wonder if Active State Perl is having this issue with Image::Magick?

Can Strawberry Perl be recompiled using Visual C++?

Jodyman-722 commented 11 months ago

@twata1 - I have experienced the same Image Magic 7.1.1.12 and Image-Magick-7.1.0-0.tar.gz work together just fine. Maybe from IM 7.1.1.13 and beyond, they are using new C++ compiler.

shawnlaffan commented 11 months ago

@shawnlaffan

@Jodyman-722 - The Visual Studio files won't work with Strawberry Perl since it uses a mingw gcc toolchain (#140 (comment)). There has been good progress with the builds, documented in #139 (although it is now a relatively long thread).

I guess we are at an impasse then. I wonder if Active State Perl is having this issue with Image::Magick?

Successful builds are described in #139 so I would not say it is an impasse.

Can Strawberry Perl be recompiled using Visual C++?

Possibly, but it would entail a reasonable amount of re-engineering given all the third party libraries that ship with SP. A UCRT build might be a means around this (currently we build with MSVCRT).

Note that it is also possible to build one's own perl using Visual C++. https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/11#issuecomment-991895638

sisyphus commented 11 months ago

During the installation process, I check the areas enclosed in the red box below

Duh - I just ignored that box altogether after I read the first option. I should've known better :-( It has been a while since I've installed libraries that way, and I had forgotten that "Select Additional Tasks" often includes the option "Make the Installation Usable".

@twata, as regards http://www.cpantesters.org/cpan/report/784aa14d-6e80-1014-a530-7500f0aa1848 , did you have to build your own import libs ('.a') .... or were the provided MSVC import libs ('.lib') sufficient ... or were you able to link directly against the dlls ? AFTERTHOUGHT: Or was the build referred to in that report conducted against a mingw/msys2 build of ImageMagick ?

Cheers, Rob

sisyphus commented 11 months ago

The Visual Studio files won't work with Strawberry Perl ...

There is a caveat to that. There should be no problem with header and dll files. But the import libraries ('.lib' files) are probably incompatible.

I keep seeing advice that mingw doesn't need import libraries - that it will link directly to dlls. But if that's proving difficult to achieve, it is possible, to generate mingw-compatible import libraries (from the dlls). In this case, there's only 3 '.lib' files in the 'lib' folder, so I would think we just need to create mingw-compatible forms of those 3 libraries.

In that 'lib' folder, place copies of CORE_RLMagick++\.dll, CORE_RLMagickCore.dll, and CORE_RLMagickWand.dll (from the top-level folder). Also place the following gendef_IM.pl file in the same 'lib' folder, 'cd' to that folder, and run perl gendef_IM.pl, and the mingw-compatible import libs should be built. ## gendef_IM.pl ## # In Strawberry Perl, create mingw-compatible # import libs from dlls. # Here, we create libCORE_RLMagick++.a, # libCORE_RLMagickCore.a libCORE_RLMagickWand.a # but those 3 files can be renamed to whatever fits # the expectation. Or the script can be edited to # output import libs with a different name.
use strict; use warnings;

my @dlls = qw(CORE_RLMagick++.dll CORE_RLMagickCore.dll CORE_RLMagickWand.dll);

for my $dll(@dlls) { my $lib = (split /./, $dll) [0]; my $def = $lib . '.def'; $lib = 'lib' . $lib . '.a';

die "Failed to run 'gendef'" if system 'gendef', $dll;

die "Failed to run 'lib'" if system "dlltool", "--kill-at", "--input-def", "$def", "--output-lib", "$lib" ; }

Cheers, Rob

sisyphus commented 11 months ago

C:\Program Files\ImageMagick-7.1.1-Q16\include/MagickCore/magick-baseconfig.h:279:6: error: #error ImageMagick was build with a 64 channel bit mask and that requires a C++ compiler # error ImageMagick was build with a 64 channel bit mask and that requires a C++ compiler

Just comment out that line in magic-baseconfig.h and re-run 'gmake'. Seems to work for me - except that t/ping.t hangs during gmake test. All other test files pass their tests.

I had already built the mingw-compatible import libs (as described in my previous post). I'm not sure if that was needed. I also added the location of the dlls to my PATH, set CPATH to the location of the headers, and set LIBRARY_PATH to the location of the import libs (which now houses both '.a' and '.lib' import libs).

Cheers, Rob

twata1 commented 11 months ago

@sisyphus

@twata, as regards http://www.cpantesters.org/cpan/report/784aa14d-6e80-1014-a530-7500f0aa1848 , did you have to build your own import libs ('.a') .... or were the provided MSVC import libs ('.lib') sufficient ... or were you able to link directly against the dlls ? AFTERTHOUGHT: Or was the build referred to in that report conducted against a mingw/msys2 build of ImageMagick ?

At the time I just downloaded and installed ImageMagick-7.1.1-12-Q16-HDRI-x64-dll.exe from https://imagemagick.org/script/download.php#windows and was not aware of any import libraries. My concern was to do the following when installing:

Check "Install legacy utilities (e.g. convert)" Check "Install development headers and libraries for C and C++"

The output of convert.exe included in ImageMagick-7.1.1-12-Q16-HDRI-x64-dll.exe was the following attachment. output-convert.exe.txt

After adding C:\Program Files\ImageMagick-7.1.1-Q16-HDRI to the PATH environment variable on the command prompt, download Image-Magick-7.1.0-0.tar.gz from metacpan and extract and build as follows, the output result is attached below.

perl Makefile.PL
gmake
gmake test

perl-Makefile.PL.log gmake.log gmake-test.log

Thank you,

sisyphus commented 11 months ago

@twata1, I'm now getting essentially the same with ImageMagick-7.1.1-19-Q16-HDRI-x64-dll.exe. The only hack I've done is to comment out the line 279 in MagickCore/magick-baseconfig.h that was there for no other purpose than to unnecessarily throw an error.

With that done (and with the ImageMagick-7.1.1-Q16-HDRI in my path) , I can just do cpan -i Image::Magick, and it will successfully build and install Image-Magick-7.1.1.

Thanks for the pointers.

This is a much simpler approach than building against an MSYS2 ImageMagick installation. I don't know if both approaches result in identical milage,

UPDATE: Also works fine for me in my own Windows builds of gcc-built perls - so long as C:\d\ImageMagick-7.1.1-Q16-HDRI comes before D:\msys64\mingw64\bin in my PATH. Oddly, I can't get this to work with my MSVC-built perls. I'm getting syntax errors so perhaps 'cl' is not running in C++ mode.

Cheers, Rob