In MSYS2, I’ve only had success with static builds of lensfun. With dynamic build, missing support libraries; I handled two, then gave up…
At the moment, I’m not even getting cmake to run, when I’m doing the same things as in my Linux builds.
Here’s my cmake command for git-cloned lensfun 0.3.2:
$ cmake -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX="$MSYSTEM_PREFIX" -DBUILD_STATIC=ON ..
I discovered that it was restricting too strongly to lenses for the camera mount, meaning you couldn’t correct for adapted lenses, so I tweaked the search routines so that if you put a backslash ("\") as the first character in the search box, it stops taking into account the camera model.
1 Like
Since I’m done adding features for now, I think tomorrow I’ll work on updating the documentation to account for all the new features.
And then back to work on Monday.
Dynamic build of lensfun seems straightforward. my lasts build is lensfun_master_v0.3.95-517-g609148cc.
mkdir build
cd build
cmake -G “MSYS Makefiles” -DBUILD_TESTS=OFF -DCMAKE_INSTALL_PREFIX=<LensfunInstallDir> -DCMAKE_INSTALL_DATAROOTDIR=<LensfunInstallDir>/share
<PathToRepository>
-DCMAKE_BUILD_TYPE=Release
make
make install
be aware that the DB in your local repo seems not up to date. I use @ggbutcher SW to update it.
To use the library in your app build script
before cmake:
LENSFUN=<LensfunInstallDir>
PKG_CONFIG_PATH=“$LENSFUN”“/lib/pkgconfig:”$PKG_CONFIG_PATH
Copy the dll and the DB located in
$LENSFUN/share/lensfun/version_2
I see that I was using -G "Unix Makefiles" instead of MSYS Makefiles, but changing that alone didn’t help.
Next I’m going to try omitting the .., since @gaaned92’s seems to leave that off…
The … is how cmake finds the CMakeLists.txt file, in the parent directory, after you mkdir and cd into build from the top lensfun directory.
I understand that, and I had that before, but it wasn’t working so I had to try it. Unfortunately, Azure Pipelines doesn’t show any of the cmake output, so I have no idea what’s going wrong.
edit: it now does say that it can’t find a CMakeLists.txt file, so clearly it was running before… just it’s impossible to debug.
edit 2: seems like the reason it’s not showing any output is because it’s running inside of msys bash. Now I’m trying running cmake in whatever shell that azure gives us.
Oh.
A starting assumption for shell syntax would be PowerShell… ?
The syntax doesn’t really matter, it’s just running cmake.
It would be nice to understand what I’m working with, though, haha
Now it’s complaining about not being able to find the glib2 dependency, which I do have installed…
Maybe I need to manually find the glib2 library directory and tell cmake to look there.
I ran into that, IIRC I had to install, like, a version 2.0 of the glib library as what MSYS2 provides by default isn’t that.
WRT cmake, I think most of the parameters should be Powershell-safe, but in general you need to consider such parameter-by-parameter…
The tool I used most to work through the MSYS2 dependency issues was pacman -Ss <searchstring>, which brought up a list of available packages that match the string, and marked the ones that were already installed. And, there were a lot of missing things…
I’ve been finding the packages by simply googling "msys2 " but even when installing those packages, cmake doesn’t seem to find them.
@CarVac
Do you use MSYS2? In that vase you have to use the mingw64 shell to get a result as it brings all the needed environment variable.
And yes, you have to load the dependency packages of lensfun with pacman.
$ pacman -Ss glib2
mingw32/mingw-w64-i686-glib2 2.64.2-1
Common C routines used by GTK+ 2.4 and other libs (mingw-w64)
mingw64/mingw-w64-x86_64-glib2 2.64.2-1 [installé]
Common C routines used by GTK+ 2.4 and other libs (mingw-w64)
msys/glib2 2.54.3-3 [installé]
Common C routines used by GTK+ and other libs
msys/glib2-devel 2.54.3-3 (development)
glib2 headers and libraries
msys/glib2-docs 2.54.3-3
Documentation for glib2
then
$ pacman -S mingw-w64-x86_64-glib2
avertissement : mingw-w64-x86_64-glib2-2.64.2-1 est à jour – réinstallation
résolution des dépendances…
recherche des conflits entre paquets…Paquets (1) mingw-w64-x86_64-glib2-2.64.2-1
Taille totale installée : 21,95 MiB
Taille de mise à jour nette : 0,00 MiB:: Procéder à l’installation ? [O/n]
n
and the same for all needed packages. And you surely need mingw-w64-x86_64 packages.
1 Like
Cross-compiling for Windows is a PITA. Frankly, the cleanest approach I’ve tried to date has been linux-hosted mxe.cc. It seems to be stuck at gcc 5.5, which makes me sad, but I still use it to produce rawproc Windows binaries for releases.
MSYS2 on a Windows host with a desktop works okay, but it’s still not as convenient as mxe.cc.
@ggbutcher
You never were a fan of MSYS2 
MSYS2 on a Windows host with a desktop with a MINGW64 shell works okay to build applications
And you get a lot of ready to use up to date packages without effort.
It uses bash and you can run scripts developped on linux.
What could be easier?
I see a lot of people cross compiling for windows on linux with mingw64 also.
Actually, I like it a lot. I’m compiling with it right now, starting the work on a denoise threshold.
I switch-hit through the day on different computers. I’m typing this on a Win10 Lenovo Miix tablet, sitting with my wife at the kitchen table. When I sit at my desk I use a Ubuntu/AMD desktop computer, which is also where I run the build scripts for rawproc releases. For dev work, MSYS2 works nicely, once I got the dependencies straight. That included such as hand-compiling LittleCMS2 so it actually used threading.
For releases, I do static compile/link of the whole shebang, no good reason other than makes the wininstaller scrip easy, I guess. And mxe.cc defaults to a static toolchain, so it all just works. Every time I assemble a release, I just check out a new copy and kick off the compilation, go to lunch. When I come back I have a fresh gcc environment with which to integrate rawproc.
I’m going to attempt to build it locally on my windows laptop to see if it’s easier to debug this way.
1 Like