Use dependency management system to bring in static freeimage compilation

[Brett208]

vcpkg came up in OP2Utility as an alternate way to load googletest/mock over nuget. I've been playing with it more. I generally like the lightweight feel of the console application. Also, I like that you don't have to sift through many random packages not created by a known/semi-trusted source. However, I have had general issues with both googletest and freeimage.

To install freeimage, I used the command:

vcpkg install freeimage:x86-windows-static freeimage:x64-windows-static

x86-windows-static is what vcpkg calls a triplet as it fully defines how the code was compiled. Downloading and installing these two triplets took 48 minutes. Ouch. We would have to somehow cache it for automated build with appveyor (if that is possible unpaid?).

I also had to add the following properties to my project file to tell Visual Studio to look for the static builds. (It defaults to looking for the dynamic builds and fails if they are not present).

<PropertyGroup Label="Globals">
  . . .
  <VcpkgTriplet Condition="'$(Platform)'=='Win32'">x86-windows-static</VcpkgTriplet>
  <VcpkgTriplet Condition="'$(Platform)'=='x64'">x64-windows-static</VcpkgTriplet>
</PropertyGroup>

Unfortunately, this produced a link error. by setting the linker property /FORCE:MULTIPLE the code compiled and the application seemed to run fine. I don't know how to fix these link errors. They seem to be caused by multiple definitions existing in the freeimage build process. Here are the errors turned to warnings by the property setting:

Warning LNK4006 TIFFfree already defined in FreeImage.lib(PluginTIFF.cpp.obj); second definition ignored OP2MapImager \OP2MapImager\tiff.lib(tif_unix.c.obj) 1
Warning LNK4088 image being generated due to /FORCE option; image may not run OP2MapImager \OP2MapImager\Release\OP2MapImager.exe 1
Warning LNK4006 _TIFFOpen already defined in FreeImage.lib(PluginTIFF.cpp.obj); second definition ignored OP2MapImager \OP2MapImager\tiff.lib(tif_unix.c.obj) 1
Warning LNK4006 __TIFFmalloc already defined in FreeImage.lib(PluginTIFF.cpp.obj); second definition ignored OP2MapImager \OP2MapImager\tiff.lib(tif_unix.c.obj) 1
Warning LNK4006 TIFFmemcmp already defined in FreeImage.lib(PluginTIFF.cpp.obj); second definition ignored OP2MapImager \OP2MapImager\tiff.lib(tif_unix.c.obj) 1
Warning LNK4006 TIFFmemcpy already defined in FreeImage.lib(PluginTIFF.cpp.obj); second definition ignored OP2MapImager \OP2MapImager\tiff.lib(tif_unix.c.obj) 1
Warning LNK4006 __TIFFmemset already defined in FreeImage.lib(PluginTIFF.cpp.obj); second definition ignored OP2MapImager \OP2MapImager\tiff.lib(tif_unix.c.obj) 1
Warning LNK4006 TIFFrealloc already defined in FreeImage.lib(PluginTIFF.cpp.obj); second definition ignored OP2MapImager \OP2MapImager\tiff.lib(tif_unix.c.obj) 1

Part of the reason I pursued vcpkg for freeimage was to get rid of freeimage.dll and bundle the code within OP2MapImager.exe. Unfortunately, the static x86 build for OP2MapImager is 6,332kb, much bigger than I was expecting. Perhaps I am missing a compiler settings.

So the results were mixed at best.

-Brett

[DanRStevens]

Ahh, thank you for looking into this.

Hmm, is there an old copy of FreeImage, perhaps installed using NuGet? That could cause redefinition errors if there are two copies being compiled together.

---

Static linking will produce a larger executable. It ends up containing the contents of the DLL stored in the EXE. Or at least parts of it that are used, depending on how good the linker is at stripping out unused code. That also depends on how intertwined the code base is.

Is new EXE size disproportionately larger than the old EXE size + old DLL size?

[Brett208]

I just created an empty project and added freeimage via vcpkg. I received the same errors so I suspect the problem is being caused by vcpkg somehow.

From the last release:

• exe size: 319kb
• freeimage.dll: 5.38mb

So linking them together made for a slightly large file. The newer version may be bringing in more from OP2Utility. Anyways, I was hoping to eliminate all the chunks of freeimage and its many dependencies that we are not using.

-Brett

[DanRStevens]

Ok, so it sounds like the final exe size is roughly what should be expected.

I suppose if we want to strip down the size, we could potentially use another smaller library. Maybe libpng would be sufficient for our purposes. That might also open up code licencing options. It might not be worth our time right now though.

---

Hmm, it looks like it's trying to link in two different libraries with the same symbols: FreeImage.lib OP2MapImager \OP2MapImager\tiff.lib (There's a tab in there, which might be telling)

[Brett208]

I added a comment to the appropriate issue in the vcpkg repository. It seems this is not an isolated problem on our end. See 1279.