Building hugin etc. on Windows in MSYS2 mingw64

[johnfi...@gmail.com]

I just finished building a fork of hugin and a fork of libpano13 and unmodified enblend on Windows using MSYS2 / mingw64

I tested barely more than opening an existing project, so there is a good chance some operations won't work because of errors I made in building.

I ran into a massive string of problems.  The non trivial ones and how I kludged around each are described below.  I'd really appreciate some information on how I might have solved or avoided any or all of these problems more cleanly (other than telling me not to use mingw64).

If some or all of these don't have great answers, I hope my description will help anyone else who wants to build hugin this way.  I was working with a fork of hugin and libpano1, but I'm nearly certain that nothing that went wrong nor any of my kludges would be different if this was not a fork.

First I got MSYS2

https://www.msys2.org/

Then I used lots of pacman commands to install lots of packages I expected to need.  I didn't make a good list.  But it is pretty obvious what is missing when you try CMake and pretty easy to find the name and install the package with pacman.  You can't get hugin itself or panotool13 or enblend that way.  But I wanted to build those myself anyway.  I think building libpano13 is necessary.  No pre-built binaries are compatible.  But I'm pretty sure you could use pre-built binaries instead of building enblend.  I followed online advice to use ninja instead of make.  I don't think that caused any of these problems.

Lots of problems were in wxWidgets.  Online discussion of the first wxWidgets problem (described below) gave the opinion that the MSYS mingw64 package for wxWidgets puts things in the wrong place.  I'm not an expert, but that seems wrong to me and I think instead CMake looks in the wrong place.  The online suggestion for that was rebuild wxWidgets correctly.  For most of the other wxWidgets problems, I think the MSYS package for wxWidgets is at fault and rebuilding it would be best.  I never found online info of those problems.  I kludged things to live with the bad wxWidgets rather than sidetrack into building a good one.

cmake can't find wxWidgets
I followed the instructions here.  The line numbers there are obsolete.  But correct places are easy to find by searching for MSYS
https://forums.wxwidgets.org/viewtopic.php?f=19&t=47555#p202984

even after it find wxWidgets

CMake Error at src/hugin1/CMakeLists.txt:27 (MESSAGE):

It is looking for a manifest that I think it should not need and which certainly is not provided by the wxWidgets package.  I gave it a different version of the manifest.  Like almost all my kludges, I edited a line in CMakeCache.txt and then reran CMake:

WINDOWS_DPI_MANIFEST:FILEPATH=C:/msys64/mingw64/include/wx-3.1/wx/msw/amd64.manifest

It still can't find other parts of wxWidgets

-- wxWidgets DLL path: WXWIDGETS_DLL_PATH-NOTFOUND

A large fraction of the things it can't find are in the correct place for MSYS mingw64 which is /msys64/mingw64/bin

CMake find functions seem to have lots of built in knowledge of MSYS mingw64, but it doesn't seem to work.  If there was a good way to tell it that things are generally in /msys64/mingw64/binI'd like to know that.  I had to individually tell it each thing

WXWIDGETS_DLL_PATH:PATH=C:/msys64/mingw64/bin

/include/vigra/separableconvolution.hxx:1413:13: error: ISO C++17 does not allow dynamic exception specifications
 1413 |             throw(PreconditionViolation)

My understanding of this error is that the vigra package in MSYS is too old and a newer copy would be better.  So adding that to the set of things I build myself would be cleaner.  BUT instead, I noticed that is fixed in two .hxx files

 stdconvolution.hxx
 separableconvolution.hxx

In the newer vigra and I noticed that the change to those two files would not impact the binaries.  It would be wrong to copy all the .hxx files from the newer version without rebuilding the binaries.  But copying those two without rebuilding is safe.

-- Could not find OPTIONAL package OPENEXR
-- Found OPENEXR: C:/msys64/mingw64/lib/libImath.dll.a;C:/msys64/mingw64/lib/libIlmImf.dll.a;C:/msys64/mingw64/lib/libIex.dll.a;C:/msys64/mingw64/lib/libHalf.dll.a;C:/msys64/mingw64/lib/libIlmThread.dll.a;C:/msys64/mingw64/lib/libz.dll.a

I never understood that one and I never fixed it, even when I fixed the later OPENEXR problem.  I have never understood any of the common cases in trying to use CMake on windows where the message that it found something is right next to the message that it could not.  Can anyone tell me what part of hugin won't work as a result of this optional item missing?  Also what is the actual thing that is missing?

CMake Error at CMakeModules/win_bundle.cmake:107 (MESSAGE):
  OpenEXR dlls not found in search path

That was hard to diagnose and I'm not sure I diagnosed/fixed it correctly.  If I diagnosed it correctly, that cmake file thinks things are part of OPENEXR that are not in openexr but are in babl.  So in msys:

pacman -S mingw64/mingw-w64-x86_64-babl

then in CMakeCache.txt

OPENEXR_BIN_DIR:PATH=C:/mingw64/lib/babl-0.1/

enblend-enfuse files not found.

I had expected the ninja install command in this environment to do something comparable to what sudo make install had done in Fedora (put the binaries in a standard place where they will be found) and I initially failed to notice that did not happen when I gave that command for enblend.  So the CMake for hugin could not find enblend.  But I was only doing that as a first cut anyway.  Going forward I actually will want my enblend binaries in a nonstandard place.  So this is a change I would have done later if I hadn't needed it now:

ENBLEND_DIR:PATH=C:/msys64/home/johnf/enblend/bin

Need to set builder (HUGIN_BUILDER) manually

Would have been easy if I knew what a "builder" is.  I thought it was a tool, like ninja.  But it apparently is me.

HUGIN_BUILDER:STRING=jfine

src/hugin_base/panotools/PanoToolsInterface.h:50: warning: "NOMINMAX" redefined

I didn't want to sort out the "right" conditionals there for the interaction of win32/msys/mingw

It was simpler to just wrap the #define NOMINMAX inside a #IFNDEF  NOMINMAX

That is safe from a wide range of possibilities of environment conflict.

src/hugin1/hugin/huginApp.cpp:382:5: error: 'wxTaskBarJumpList' was not declared in this scope
src/hugin1/ptbatcher/BatchFrame.cpp:1291:9: error: 'wxTaskBarButton' was not declared in this scope

I really think the MSYS package of wxWidgets is at fault on this one, and this is the best reason to rebuild that from source code and find a way to fix it there.  By kludging around this problem, I think I've taken away a cute bit of windows functionality.  But I don't think I've badly broken anything.  Anyway, I added && 0 to the end of the innermost #IF at each of those spots to just disable that feature in my local source code.  Some better solution is clearly needed.  This is the most unacceptable kludge I did in this project.

Once it all built, I needed a directory I could run it from, which is apparently what ninja install does, except that for hugin (unlike enblend) it suddenly cares about a bunch more things that it hadn't found before and hadn't earlier cared that it hadn't found.

The first was exiftool.exe, which is not in the MSYS system, so I made the edit:

EXIFTOOL_EXE_DIR:PATH=C:/Tools

I expect it will be elsewhere on your system (after you download it).

The rest of these were all in C:/msys64/mingw64/bin which is the only correct place for them in an MSYS/mingw64 system.  As I asked before, is there any general way to tell CMake that?  Or it has to be one at a time?

For one at a time, the trick is knowing the right filename from the abstract filename.  I looked and guessed and in some cases it was a difficult guess:

TIFF_DLL-NOTFOUND
TIFF_DLL:FILEPATH=C:/msys64/mingw64/bin/libtiff-5.dll
JPEG_DLL-NOTFOUND
JPEG_DLL:FILEPATH=C:/msys64/mingw64/bin/libjpeg-8.dll
PNG_DLL-NOTFOUND
PNG_DLL:FILEPATH=C:/msys64/mingw64/bin/libpng16-16.dll
ZLIB_DLL-NOTFOUND
ZLIB_DLL:FILEPATH=C:/msys64/mingw64/bin/zlib1.dll
VIGRA_DLL-NOTFOUND
VIGRA_DLL:FILEPATH=C:/msys64/mingw64/bin/libvigraimpex.dll
EXIV2_DLL-NOTFOUND
EXIV2_DLL:FILEPATH=C:/msys64/mingw64/bin/libexiv2.dll
GLEW_DLL-NOTFOUND
GLEW_DLL:FILEPATH=C:/msys64/mingw64/bin/glew32.dll
SQLITE3_DLL-NOTFOUND
SQLITE3_DLL:FILEPATH=C:/msys64/mingw64/bin/libsqlite3-0.dll
FFTW3_DLL-NOTFOUND
FFTW3_DLL:FILEPATH=C:/msys64/mingw64/bin/libfftw3-3.dll

For some reason, it did not care that it had not found pano13.dll

It would not run unless that also was copied to the place ninja install put all those others.

Then it also wanted PTmender.exe but wanted the directory of that not the FILEPATH

PANO13_EXE_DIR:PATH=C:/msys64/home/johnf/buildpano/tools

On your system that will be wherever PTmender.exe ended up when you built libpano13

After fixing those and some super trivial things it runs.  Gradually, I'll figure out what parts of it might be broken.

[johnfi...@gmail.com]

src/hugin1/hugin/huginApp.cpp:382:5: error: 'wxTaskBarJumpList' was not declared in this scope
src/hugin1/ptbatcher/BatchFrame.cpp:1291:9: error: 'wxTaskBarButton' was not declared in this scope

I seriously misunderstood the situation when I kludged past the above problem earlier.

Reviewing it, I now understand those two hugin files are including the wrong variant of taskbarbutton.h

There is one in wx-3.1/wx/  and another in wx-3.1/wx/msw

There are other .h files that similarly have those two variants and for those .h files other hugin source files correctly decide to use wx/msw instead of wx/ during this build.

I don't yet understand why this isn't a problem for everyone building hugin in Windows.  Obviously it is not that common a problem.  But I don't yet see a reason that it would be specific to msys2.  I'll research it more some other time, unless someone answers this before then.

[johnfi...@gmail.com]

On Monday, March 14, 2022 at 9:17:34 PM UTC-4 johnfi...@gmail.com wrote:

Reviewing it, I now understand

Actually, I was even more wrong that time.

I'm gradually understanding more about this problem, but still don't know the basic cause.

When wxUSE_TASKBARBUTTON is defined as 0, you can't use those classes.

But why that symbol is defined as 0 in msys2/mingw64, I don't understand.

For now, I think the right answer is to test that symbol before using those classes.