Exiv2

Arnold

You set the compiler/bits using Microsoft's vcvars.bat script before you run contrib/cmake/msvc/cmakeBuild.cmd. CMake (and cmakeBuild.cmd) detects the compiler/bits from the environment. For your convenience there is a script contrib/cmake/msvc/vcvars.bat to make it easy to call Microsoft's vcvars.bat script.

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\Users\rmills>cd gnu\github\exiv2\exiv2\contrib\cmake\msvc

C:\Users\rmills\gnu\github\exiv2\exiv2\contrib\cmake\msvc>vcvars 2015 32
Success Environment for Visual Studio 14.0 = 2015 32

C:\Users\rmills\gnu\github\exiv2\exiv2\contrib\cmake\msvc>cmakeBuild
calling cmakeDefaults.cmd
checking that ..\..\.. exists
_EXIV2_ = C:\Users\rmills\gnu\github\exiv2\exiv2
testing VSINSTALLDIR "C:\Program Files (x86)\Microsoft Visual Studio 14.0\" 
testing architecture
Platform = Win32 (x86)
determine generator
GENERATOR = Visual Studio 14 2015
testing out of source build
...
... lots and lots of stuff for about 5 minutes
...
Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:07.62

C:\Users\rmills\gnu\github\exiv2\exiv2\contrib\cmake\msvc>dist\2015\Win32\dll\Release\bin\exiv2 --verbose --version
exiv2 0.26 001a00 (32 bit build)
Copyright (C) 2004-2017 Andreas Huggel.

Thank you, but ..

if I run vcvars 2015 32 in the same directory where I built the default, I get

D:\pkg\C++\MSVC2015\exiv2\trunk\build>vcvars 2015 32
already installed

If I open another DOS window, I get

D:\>cd \pkg\C++\MSVC2015\exiv2\trunk\build

D:\pkg\C++\MSVC2015\exiv2\trunk\build>vcvars 2015 32
Success Environment for Visual Studio 14.0 = 2015 32

D:\pkg\C++\MSVC2015\exiv2\trunk\build>cmakeBuild --verbose --exiv2 .. --static
calling cmakeDefaults.cmd
checking that .. exists

..... and ends with:

---------- EXIV2 building with cmake ------------------

++++++++++++++++++++++++++++++++++++++++++++++++++++++
CD = D:\pkg\C++\MSVC2015\exiv2\trunk\build\work\exiv2
cmake -G "Visual Studio 14 2015" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=D:\pkg\C++\MSVC2015\exiv2\trunk\build\dist\2015\Win32\static\Release -DCMAKE_LIBRARY_PATH=D:/pkg/C++/MSVC2015/exiv2/trunk/build/dist/2015/Win32/static/Release/bin -DCMAKE_INCLUDE_PATH=D:/pkg/C++/MSVC2015/exiv2/trunk/build/dist/2015/Win32/static/Release/include -DEXIV2_ENABLE_NLS=OFF -DEXIV2_ENABLE_BUILD_SAMPLES=ON -DEXIV2_ENABLE_WIN_UNICODE=OFF -DEXIV2_ENABLE_SHARED=OFF -DEXIV2_ENABLE_DYNAMIC_RUNTIME=OFF -DEXIV2_ENABLE_WEBREADY=OFF -DEXIV2_ENABLE_CURL=ON -DEXIV2_ENABLE_SSH=OFF -DEXIV2_ENABLE_VIDEO=OFF "D:\pkg\C++\MSVC2015\exiv2\trunk"
CMake Error: Error: generator : Visual Studio 14 2015
Does not match the generator used previously: Visual Studio 14 2015 Win64
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
"*** cmake errors in EXIV2 ***"

D:\pkg\C++\MSVC2015\exiv2\trunk\build>

Would this be due to the reworking?
and if so, any expected date when the rework will be usable?

Arnold

Use:

D:\pkg\C++\MSVC2015\exiv2\trunk\build> cmakeBuild.cmd --rebuild .....

I hope that worked for you.

I'd like to say a few more things about this:

1) contrib\cmake\msvc\vcvars.bat

The reason it's called "vcvars.bat" is to say "Go and find Microsoft's vcvars.bat and run it". Microsoft have changed the directories and scripts with almost every release of Visual Studio. I've tried to simplify that with contrib\cmake\msvc\vcvars.bat, so that you just say contrib\cmake\msvc\vcvars.bat VSedition [32|64]

2) contrib\cmake\msvc\cmakeBuildAll.cmd

When I'm using/debugging cmakeBuild.cmd, I usually run cmd.exe from cmd.exe

.....> cmd.exe
.....> vcvars 2015 64
.....> cmakeBuild ...
....
.....> exit
.....> cmd.exe
.....> vcvars 2005 64
.....> cmakeBuild ...
....
.....> exit

You'll see there is a script contrib\cmake\msvc\cmakeBuildAll.cmd:

for %%a in (32) do for %%v in (2010 2008 2005) do cmd /c "vcvars %%v %%a && cmakeBuild %* 2>&1"

.....> cmakeBuildAll.cmd --rebuild --static

For years, I developed Exiv2 using the msvc/exiv2.sln It supports {x64|x86} {release|debug} {static|dll}. Luis is working hard to persuade me to remove the msvc solution which he describes as "madness". It's not madness. It works well and supports 2005/8/10/12/13/15/18, although the Visual Studio project convertor from 2012 on-wards takes about 5 minutes to run and produces loads of unhelpful messages and warnings about nothing. Today, I do Exiv2 development on MacOS-X/CMake.

Thank You for using Exiv2. I'll be interested to receive your feedback as I'm always looking for ways to improve every aspect of Exiv2 including the build.

I'll try to document my experience here a bit more, though it will come in bits and pieces.
If I wait to the end, it'll be too much of a jumble, I'd expect.

First I'll try to carry on with the Cmake process, though I much prefer the .sln path.
I had seen the msvc/exic2.sln file, but because I have had unsatisfactory and frustrating experiences with MSVC update for such files, I usually avoid that path, especially of the upgrade spans several MSVC versions.

More about my luck with that approach though in another post.

For the Cmake process:
the default in the build file assumes exiv2 to live at ../trunk, but extracting the zip file from the download site puts that info into trunk-exiv2

The idea of using the 'cleanup' option --rebuild needs more emphasis, or make the default for 32-bit, which still seems to be the more likely requirement, at least for the time being.

Another way to give more helpful information: display more information in response to --help.
Specifically say
--config Release|Debug
--generator - spell out more of what 'strings' will be acceptable

When I tried --generator 2015, admittedly likely ambiguous, the error response was very detailed :-)
but, is it really realistic to have the users spell out

Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files.
Optional [arch] can be "Win64" or "ARM".

and, if we do, will we need quotes around the strings with spaces?
can we we specify x86 or 32-bit for arch? or is there only provision for 64-bit & ARM?

But most importantly, for me, can I & how do I request Unicode???

msvc.sln issues

As you mentioned, the upgrade to MSVC 2015 took a bit of time, but completed, to my surprise, without errors, though there were lots of warnings & messages :-)

The first issue when trying to compile the whole project I ran into was that the source files for expat, and possibly others, are not part of the extracted data.

Since I am really only interested, at least for now, in libexiv2, I tried to only compile that sub-project by itself.

The issue, in this case, was the detail the all of the zlib headers needed for this library live in directories which include the zlib version number.
The other issue is that there are config headers which live in directories dependent on the configuration and other details.

in my case, I had to add the following paths to get a compile:

D:\pkg\C++\MSVC2015\exiv2\trunk\build\zlib-1.2.8
D:\pkg\C++\MSVC2015\exiv2\trunk\build\dist\2015\Win32\static\Debug\include

For the time being, I kept the paths absolute, though relative paths, as used in the rest of the .sln file would be preferable.

Again, can I compile for UNICODE?? How??

Would environment variables pointing to expat, zlib etc sources make life easier wrt using different versions of these libs??

Thanks for the feedback. Lots of stuff for me to think about.

Regrettfully, I didn't make --unicode an option in contrib\cmake\msvc\cmakeBuild.cmd because I never thought about it. I will fix this in v0.26.1. For the moment, you have to edit the script

C:\Users\rmills\gnu\exiv2\0.26>grep --line-number UNICODE contrib/cmake/msvc/*.cmd
contrib/cmake/msvc/cmakeBuild.cmd:288:              -DEXIV2_ENABLE_WIN_UNICODE=OFF        -DEXIV2_ENABLE_SHARED=%ENABLE_SHARED% ^

C:\Users\rmills\gnu\exiv2\0.26>

Your comments about the defaults for cmakeBuild.cmd are very useful. The script cmakeBuild.cmd was added for v0.26 and you are the first user to discuss it with me. I'll be reviewing the documentation in contrib\cmake\msvc\ReadMe.txt for our up-coming "dot" release v0.26.1. I'll make sure your comments are reflected in that document.

Luis is working with great enthusiasm to replace the msvc solution/project files and the Linux ./configure script with a combination of Conan+CMake. Today he submitted his first version of our Conan support. Conan is Python based build technology which understands dependencies. Exiv2 has dependencies on zlib, expat, libssh, openssl and curl. With v0.26.1 we want to enable the user to link different versions of Adobe XMPsdk. It remains to be proven that Conan+CMake will enable us to simplify the build and dependencies on all platforms, however we are optimistic. Exiv2 v0.26.1 will remain backwards compatible with v0.26. We will continue to support all existing build methods and the CMake+Conan support will be be introduced as "experimental".

Thank for taking the time to give me feedback. Working on open-source can be a lonely business. I usually only hear from people who want something fixed or changed. When I develop Exiv2, I "do my best", however user feedback is rare. Thank you for taking the time to write down your thoughts. Constructive criticism is always helpful. Thank You very much.

Thanks for your feedback about the msvc/solution files.

You should place the code for expat and zlib into directories "parallel" to exiv2. This is documented in msvc/ReadMe.txt

I don't like having to have the expat and zlib in "parallel" directories, however it's quite easy to set up and I provide build project files for expat and zlib in the exiv2.sln. I did this because the MSVC support provided by expat and zlib was not good.

To configure the msvc build, please edit include\exiv2\exv_msvc.h There's a setting there for UNICODE. This file is part of the libexiv2 project and labelled "MSVC only" in the project explorer.

Thanks for the feedback. Very much appreciated. Thank You.

If only all open source software forums were as responsive as this one ;-)
Thank you.
I certainly can relate to the issues of the many and various versions of those essential supporting libraries and how to keep them up-to-date and in-sync with the rest of the code one is working with - made worse by cross-platform & OS differences.
For myself, using Windows basically came down to a more intuitive debugger, mainly because of experience at work, where Linux was not an option ;-)
I have dabbled with Linux and similar Unix-derivatives (mainly Solaris), but always ended up going back to what I knew best and usually the debugging facility was a very important part of the move. At times the multitude of 'flavours' and sometimes brick-wall differences - to the uninitiated newb - did not help keep me in the Linux 'fold. ;-)
My main toolkit now includes wxWidgets, where Unicode is a must with the current releases, along with the need to handle more than plain ASCII text, which also needs either MS multi-byte strings or Unicode.
The problem of some of my projects depending on several of these supporting libraries has always been a frustrating experience for me, to the point of often enough installing a specific version for each project - usually the version current when the project was started - to make sure any changes in the library code would not upset anything over the years that most projects live.
These are then updated only when the new version of the libraries includes something essential for the project's operation or makes it possible to remove a limitation imposed by those libraries.

As for the notes in the read.me files, it is a very valid point and I can only say in my 'defense'- there is always the issue of RTFM :-) coupled to the fact that this project contains a number of read.mes and after reading a number of them, it becomes hard to remember just what one read where and in relation to which issue.

Later on this week, I will try the suggested fixes and report back on how I made/make out.

Thank you for your kind comments about the forum. I enclose my updated version of the code and documentation in contrib/cmake/msvc Comments and feedback welcome.

I've always really liked Visual Studio as a development environment. It's easy to target your build, great debugging and wonderful object browser, MFC and good GUI design tools. In the open-source world, I've been surprised by the Windows-hostility (mostly based on ignorance of Visual Studio). Light-weight cross platform GUI hardly exist. Qt and wx are both huge things.

I try to "silo" my ReadMe.txt files. If you're working in contrib/cmake/msvc, everything you need to know should be in that file. And in msvc/ - all you need should there. But you know, mistakes get made. And when I document everything, folks don't read it and say "It's insufficient and it's too long".

Anyway, it's nice to work with you. Good luck in your endeavours. Speak later in the week.

As for the size of Qt & wx, I only know a bit about wx, next to nothing about Qt & I suppose trying to be all things to all things makes for a lot of wrappers and shims :-(

Regarding readmes, I can relate to your observation "too long & insufficient" :-) I know well enough from my own way of leaving myself extensive 'breadcrumbs' about my 'history' of any particular project. When I get back to it some time later either for further work or to fix issues, sometimes what I can find what I need, other times, even though I know I have faced the same error or warning a number of times, any record of the earlier 'solution' is nowhere to be found.

I suppose that is/was the motivation behind the Linux type config script tests. In applications, the solution is checking & reporting issues resulting from bad assumptions by the user, but in libraries and compile scripts, it is a bit harder.

Back to the real issues :-)
cmake --help

no mention of --unicode

-------------
in the builds of interest, even though I use the option --static, the scripts seem to be building DLLs

A question: the debug versions of the libs & DLLs have a 'd' suffix, would it be possible to add a 'u' suffix for the Unicode builds?

After replacing the original 2 build scripts with the new ones,
for either the Unicode or non Unicode build, expat & zlib build OK, but it is the DLLs that get built, not libs
non Unicode:

D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\contrib\cmake\msvc>cmakebuild --rebuild --verbose --config Debug --static
calling cmakeDefaults.cmd
checking that ..\..\.. exists
EXIV2 = D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk
testing VSINSTALLDIR "C:\Program Files (x86)\Microsoft Visual Studio 14.0\"
testing architecture
Platform = Win32 (x86)
The system cannot find the batch label specified - echo
GENERATOR = Visual Studio 14 2015
testing out of source build
testing compiler
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
...............

---------- EXIV2 building with cmake ------------------

++++++++++++++++++++++++++++++++++++++++++++++++++++++
CD = D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\contrib\cmake\msvc\work\exiv2
cmake -G "Visual Studio 14 2015" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\contrib\cmake\msvc\dist\2015\Win32\static\Debug -DCMAKE_LIBRARY_PATH=D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/dist/2015/Win32/static/Debug/bin -DCMAKE_INCLUDE_PATH=D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/dist/2015/Win32/static/Debug/include -DEXIV2_ENABLE_NLS=OFF -DEXIV2_ENABLE_BUILD_SAMPLES=ON -DEXIV2_ENABLE_WIN_UNICODE=OFF -DBUILD_SHARED_LIBS=OFF -DEXIV2_ENABLE_DYNAMIC_RUNTIME=OFF -DEXIV2_ENABLE_WEBREADY=OFF -DEXIV2_ENABLE_CURL=ON -DEXIV2_ENABLE_SSH=OFF -DEXIV2_ENABLE_VIDEO=OFF "D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk"

..............

Link:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe /ERRORREPORT:QUEUE /OUT:"D:\pkg\C++\MSVC2015\exiv
2\exiv2-0.26-trunk\trunk\contrib\cmake\msvc\work\exiv2\src\Debug\exiv2d.dll" /INCREMENTAL /NOLOGO /LIBPATH:"D:/pkg/C+
/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/dist/2015/Win32/static/Debug/bin" /LIBPATH:"D:/pkg/C+/MSV
C2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/dist/2015/Win32/static/Debug/bin/Debug" ..\..\..\dist\2015\Win3
2\static\Debug\lib\zlibd.lib ..\..\..\dist\2015\Win32\static\Debug\lib\expat.lib ..\xmpsdk\Debug\xmpd.lib ..\..\..\di
st\2015\Win32\static\Debug\lib\expat.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut3
2.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed
/DEBUG /PDB:"D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/work/exiv2/src/Debug/exiv2d.pdb" /SU
BSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cma
ke/msvc/work/exiv2/src/Debug/exiv2d.lib" /MACHINE:X86 /SAFESEH /machine:X86 /DLL exiv2lib.dir\Debug\asfvideo.obj
exiv2lib.dir\Debug\basicio.obj
exiv2lib.dir\Debug\bmpimage.obj
exiv2lib.dir\Debug\canonmn.obj

.................

exiv2lib.dir\Debug\localtime.obj
  exiv2lib.dir\Debug\getopt_win32.obj
     Creating library D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/work/exiv2/src/Debug/exiv2d.l
  ib and object D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/work/exiv2/src/Debug/exiv2d.exp
xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol _imp_XML_ParserCreateNS referenced in function
 "public: _thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@QAE@XZ) [D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-
trunk\trunk\contrib\cmake\msvc\work\exiv2\src\exiv2lib.vcxproj]
xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol __imp__XML_SetElementHandler referenced in funct
ion "public: __thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@QAE@XZ) [D:\pkg\C++\MSVC2015\exiv2\exiv2-0.
26-trunk\trunk\contrib\cmake\msvc\work\exiv2\src\exiv2lib.vcxproj]
xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol __imp_XML_SetCharacterDataHandler referenced in
 function "public: __thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@@QAE@XZ) [D:\pkg\C++\MSVC2015\exiv2\ex
iv2-0.26-trunk\trunk\contrib\cmake\msvc\work\exiv2\src\exiv2lib.vcxproj]

============
Unicode build

D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\contrib\cmake\msvc>vcvars 2015 x86
Success Environment for Visual Studio 14.0 = 2015 x86

D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\contrib\cmake\msvc>cmakebuild --rebuild --verbose --config Debug --static --unicode
calling cmakeDefaults.cmd

...............
---------- EXIV2 building with cmake ------------------

++++++++++++++++++++++++++++++++++++++++++++++++++++++
CD = D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\contrib\cmake\msvc\work\exiv2
cmake -G "Visual Studio 14 2015" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\contrib\cmake\msvc\dist\2015\Win32\static\Debug -DCMAKE_LIBRARY_PATH=D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/dist/2015/Win32/static/Debug/bin -DCMAKE_INCLUDE_PATH=D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/dist/2015/Win32/static/Debug/include -DEXIV2_ENABLE_NLS=OFF -DEXIV2_ENABLE_BUILD_SAMPLES=ON -DEXIV2_ENABLE_WIN_UNICODE=ON -DBUILD_SHARED_LIBS=OFF -DEXIV2_ENABLE_DYNAMIC_RUNTIME=OFF -DEXIV2_ENABLE_WEBREADY=OFF -DEXIV2_ENABLE_CURL=ON -DEXIV2_ENABLE_SSH=OFF -DEXIV2_ENABLE_VIDEO=OFF "D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk"
.............

Creating library D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/work/exiv2/src/Debug/exiv2d.l
  ib and object D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/work/exiv2/src/Debug/exiv2d.exp
xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol _imp_XML_ParserCreateNS referenced in function
 "public: __thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@@QAE@XZ) [D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-
trunk\trunk\contrib\cmake\msvc\work\exiv2\src\exiv2lib.vcxproj]

====================

Loading the exiv2.sln file for MSVC 2015 in trunk\contrib\cmake\msvc\work\exiv2 & trying to build the debug version gives me:
3 failing projects
4>------ Build started: Project: exiv2lib, Configuration: Debug Win32 ------
4> Creating library D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/work/exiv2/src/Debug/exiv2d.lib and object D:/pkg/C++/MSVC2015/exiv2/exiv2-0.26-trunk/trunk/contrib/cmake/msvc/work/exiv2/src/Debug/exiv2d.exp
4>xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol _imp_XML_ParserCreateNS referenced in function "public: _thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@QAE@XZ)
4>xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol __imp__XML_SetElementHandler referenced in function "public: __thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@QAE@XZ)
4>xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol __imp_XML_SetCharacterDataHandler referenced in function "public: _thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@QAE@XZ)
4>xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol __imp__XML_SetProcessingInstructionHandler referenced in function "public: __thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@QAE@XZ)
4>xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol __imp_XML_SetCommentHandler referenced in function "public: _thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@QAE@XZ)
4>xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol __imp__XML_SetCdataSectionHandler referenced in function "public: __thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@QAE@XZ)
4>xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol __imp_XML_SetNamespaceDeclHandler referenced in function "public: _thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@QAE@XZ)
4>xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol __imp__XML_SetUserData referenced in function "public: __thiscall ExpatAdapter::ExpatAdapter(void)" (??0ExpatAdapter@QAE@XZ)
4>xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol __imp_XML_Parse referenced in function "public: virtual void __thiscall ExpatAdapter::ParseBuffer(void const *,unsigned int,bool)" (?ParseBuffer@ExpatAdapter@UAEXPBXI_N@Z)
4>xmpd.lib(ExpatAdapter.obj) : error LNK2019: unresolved external symbol __imp__XML_ParserFree referenced in function "public: virtual __thiscall ExpatAdapter::~ExpatAdapter(void)" (??1ExpatAdapter@UAE@XZ)
4>D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\contrib\cmake\msvc\work\exiv2\src\Debug\exiv2d.dll : fatal error LNK1120: 10 unresolved externals

-------------
18>------ Build started: Project: geotag, Configuration: Debug Win32 ------
18>geotag.obj : error LNK2019: unresolved external symbol _imp_XML_ParserCreate referenced in function _catch$?parseTime@YA_JPBD_N@Z$0
18>geotag.obj : error LNK2019: unresolved external symbol __imp__XML_SetElementHandler referenced in function __catch$?parseTime@YA_JPBD_N@Z$0
18>geotag.obj : error LNK2019: unresolved external symbol __imp_XML_SetCharacterDataHandler referenced in function _catch$?parseTime@YA_JPBD_N@Z$0
18>geotag.obj : error LNK2019: unresolved external symbol __imp__XML_SetUserData referenced in function __catch$?parseTime@YA_JPBD_N@Z$0
18>geotag.obj : error LNK2019: unresolved external symbol __imp_XML_Parse referenced in function __catch$?parseTime@YA_JPBD_N@Z$0
18>geotag.obj : error LNK2019: unresolved external symbol __imp__XML_ParserFree referenced in function __catch$?parseTime@YA_JPBD_N@Z$0
18>D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\contrib\cmake\msvc\work\exiv2\samples\Debug\geotag.exe : fatal error LNK1120: 6 unresolved externals

------------------
16>------ Build started: Project: exiv2, Configuration: Debug Win32 ------
16>D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\src\actions.cpp(2121): error C2664: 'std::string Exiv2::ws2s(const std::wstring &)': cannot convert argument 1 from 'std::string' to 'const std::wstring &'
16> D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\src\actions.cpp(2121): note: Reason: cannot convert from 'std::string' to 'const std::wstring'
16> D:\pkg\C++\MSVC2015\exiv2\exiv2-0.26-trunk\trunk\src\actions.cpp(2121): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called

Slow down, you're going too fast.

1) Can we add u for Unicode? Yes, I think so. <exiv2>/CMakeLists.txt has the code:

550 rmills@rmillsmbp:~/gnu/exiv2/0.26 $ grep --line-number -B 3 -A 1 CMAKE_DEBUG_POSTFIX CMakeLists.txt  
111-if( MSVC )
112-    # cmake_policy(SET CMP0008)
113-    ADD_DEFINITIONS(-DPSAPI_VERSION=1) # to be compatible with <= WinVista (#905)
114:    set(CMAKE_DEBUG_POSTFIX "d")
115-endif( MSVC )
551 rmills@rmillsmbp:~/gnu/exiv2/0.26 $ 

2) Linking DLLs, instead of statics.
Exiv2 is static (there's no exiv2 dll), however it links expat.dll and zlib.dll

This was fixed in July https://github.com/Exiv2/exiv2/issues/11 You can patch the fix into your code. However I'll fix it on master because Luis recently disturbed my fix on GitHub exiv2/exiv2.git. I hope to fix it in the next day or two.

3) All this output. Are you reporting issues with Visual Studio+UNICODE+32+static Is this msvc/exiv2.sln or CMake generated exiv2.sln Can you isolate the lethal combination for me please?

4) Are there more questions I failed to notice?

OK, I'll slow down ;-)
Perhaps I'd best wait till things settle down with exiv2?

I'll put in a request to redmine for the 'u' decoration - sometime later today.

As for my 'output' samples: my first reply was from
trunk\contrib\cmake\msvc>cmakebuild --rebuild --verbose --config Debug --static

&&

trunk\contrib\cmake\msvc>cmakebuild --rebuild --verbose --config Debug --static --unicode

the second reply was output from my attempts to use the sln file (presumably) generated by the above attempts to use cmakebuild

In general, I think you have addressed all my questions.

My main interest is using exiv2lib in a Unicode build because I need to handle UTF-8 for European languages other than English with all their 'funny' characters, including potentially Cyrillic scripts/fonts.
To avoid multiple file dependencies, I prefer static linking of all bits and pieces, but I can live with using DLLs if necessary.

Earlier today, I have used exiv2.exe as it was build without Unicode and when I dump all of the metadata in a PNG file with UTF8 strings, it naturally displays a garbled string.

This particular project is part of my work on our family tree and my efforts to 'weld' details of interest to the png documents, so that the data can be searched using suitable DAM software. It all started out with my attempts to find out where and how the metadata was stored, since not all utilities look for or save the 'same' data in the same place. There are just too many image metadata 'standards' and nothing to search and/or edit the data, other than Exiftool which seems to handle them all - but it is a bit cumbersome to run from the command line in a GUI environment.

Some time ago I had tried to use the XMP SDK from Adobe directly, but even then UTF-8 seemed to be an issue and when I corresponded with some of Adobe's people, I never did get the issue resolved.
From the looks of things, though, even Exiv2 uses the XMP SDK and I do hope that UTF-8 won't be the problem this time as well ;-)

Thanks for the explanation about your project.

Exiv2's XMP support is a wrapper over the Adobe XMPsdk. We locate the XMP/xml and feed it into Adobe's code. I cannot predict anything about XMPsdk's UTF-8 handling. Let's wait until we identify an issue and I will try to help.

To avoid confusion with the work being done by Luis, I am focusing our discussion on the released version of Exiv2 v0.26. Please remove the modified files which I sent yesterday - they are polluted by changes on GitHub exiv2/exiv2 and disturbing the peace!

The fix for "pure" static linking (no expat.dll no zlib.dll) is in GitHub for v0.26.1.

I built static and it's good.

contrib\cmake\msvc\> cmakebuild --rebuild --static  --exiv2 ..\..\..

I manually edited cmakeBuild.cmd and changed UNICODE=OFF to UNICODE=ON and reran the build. There is a bug in UNICODE src/actions.cpp which was fixed in GitHub on 2017-08-09. Regrettably, I think release v0.26 UNICODE build is broken. The file src/actions.cpp is used by exiv2.exe and isn't part of the library. The library is successfully build, however it's not copied to the distribution directory when the build fails to build exiv2.exe.

You are exercising build configurations that have not received much of my attention. May I suggest that you give me a couple of weeks to stabilise various matters on Github and then you build and use that. You will be helping hugely to improve the quality of our UNICODE and CMake build (and probably other matters). Can we work together, have some fun, and get this fixed? How's that?

That sounds like a good plan :-)
Your help in this is much appreciated.
Resolving the UTF-8 issue is important to me and it is not as if there was nothing else to do at my end ;-)
So 2 weeks, or whatever it takes, is quite OK with me.
And testing code etc is what I spend most of my time at as it is.

I had been able to compile and link 0.25, but because I ran into issues with some of the exiv2 code that I tried to update to 0.26 and that is where this thread started.

Any replies to this thread show up in my in-box and I'll simply wait for your signal that it is time for me to carry on with this thread.

Right. Can you open another thread to discuss this UTF-8 business, please?

I'll get on with the builds. I've made a truth table. As you can see, I have a lot to do (and that's only MSVC). Similar (but not quite as large) effort needed on Cygwin, MacOS-X, Linux and somebody has requested MinGW msys/2.0.

+--------------------------------------------------------+
| MSVC                2005 2008 2010 2012 2013 2015 2017 |
| 32|64              :    :    :    :    :    :    :     |
| static|shared      :    :    :    :    :    :    :     |
| ascii|unicode      :    :    :    :    :    :    :     |
| Debug|Release      :    :    :    :    :    :    :     |
| CMake|msvc         :    :    :    :    :    :    :     |
| webready           :    :    :    :    :    :    :     |
| samples            :    :    :    :    :    :    :     |
+--------------------------------------------------------+

Looks like you do have a full 'plate' alright
Any time or any way I can help with this, please let me know.

Also, I have started a new thread for the Unicode version.

The machine will do the hard work to populate the build matrix. I've made good progress today on the code. Optimistic that I'll get this submitted this week. Both you and Tobias will be testing. This will be a better and stronger release of the UNICODE support than has been done in the past.

I've done the decoration: '', 'd', 'u','du' and I believe it's working. I only intend to support this with CMake/Visual Studio builds.

Quick update. I've done something useful today. I've cut the grass!

I've been going round in circles for the last 24 hours. I'm totally focused on VS 2015/32-bit static. That cuts the options to: {ascii | unicode} x {debug | release}. The config option {debug | release} is causing great pain. I suspect a bug in CMake!

When I wrote cmakeBuild.cmd (2 years ago), I may have only have tested Release. If it built and passed the test suite, I was happy. And it has been in service (performing nightly builds) for 18 months. The script works.

Anyway, I will try different things until it works, or I discover a way to make it work correctly.

I can relate to 'going in circles' - fortunately you are much more familiar with CMake than I am, so I am optimistic the issues will be resolved.
(Since I have had some major issues when moving up from earlier MSVC IDE, might things work (better) with some versions of MSVC and not with others?)
Meanwhile, because I realized Adobe had updated their XMP SDK, I will give it a try again.
Partly because that is where I started out and partly because even Exiv2 uses it to handle XMP data.

The most important feature arriving in Exiv2 v0.26.1 is support for Adobe XMPsdk 2013|2014|2016 or our existing libxmp.a code (based on some Adobe code from about 10 years ago). When you choose one of the Adobe SDKs, it will be built as a static library and linked into Exiv2. That's what I was working on before you appeared at the weekend.

By now I have been able to make my test app compile & link with the latest Adobe XMP SDK and from the limited testing I have done so far, it looks like I can at least read the UTf-8 strings embedded by XnViewMP :-)
I also realized that I referred to the wrong utility I mostly use to inspect PNG = tweakpng is the one which has a GUI and allow some editing of the data.
I am still interested both in using Exiv2 as a library and in testing the Windows parts of the distribution.
My work today simply means I am not as dependent on Exiv2 as I had thought.

Thanks for the update. I'm glad to be "off the hook" to get the build fixed quickly for you. I think I know what's wrong and it concerns the --config. I want to fix it for Tobias and hope to get it done in the next few days.

I guess you've seen my remarks about your request for unicode support in exiv2: http://dev.exiv2.org/issues/1311#note-1

I think we should only build UNICODE in our msvc builds in v0.27 and later. Would you be interested in mentoring a student next year to undertake the various tasks I have mentioned ?

Yes, I have seen your comments, but have not really digested all of the implications.

Whether to restrict yourself, or rather exiv2, to Unicode under Windows, I am in a very poor position to judge, if only because I have no idea where, how and by how many exiv2 is used under Windows.

The same reasons argue against my mentoring a student as does my inexperience with any such sort of work as well as my rather limited understanding of localization as well as Unicode vs other encodings. Still, I'd be interested in helping - and learning myself - as much as possible.
-----------

One of the comments in my test app code regarding my reasons for abandoning Adobe's XMP SDK concerns the problems with embedded UTF-8 strings I could not resolve, even with the help of the SDK support staff. The was with the old version XMP-Toolkit-SDK-CC201306.

My tests with the current version XMP-Toolkit-SDK-CC201607 show no such problems.

In fact, the XMP Spec in XMPSpecificationPart1.pdf states:
7.1 General
The abstract XMP data model needs a concrete representation when given a physical representation such as a
digital file or a printed document. This document defines a canonical serialization of XMP metadata using a
subset of the RDF metadata syntax. The RDF serialization shall use Unicode text as defined in The Unicode
Standard. The choice of Unicode encoding (UTF-8, UTF-16, or UTF-32) is beyond the scope of this document.
Other file embedding or usage standards may specify the Unicode encoding.
For this serialization, a single XMP packet shall be serialized using a single rdf:RDF XML element.
Serialized XMP shall be well-formed XML and well-formed RDF. An XMP reader shall conform to the rules of
XML and RDF given in their respective specifications.

Depending on which version you use with exiv2, there might not be any problems in this respect for exiv2.

Other standards seem to be handling this, IIRC, using some language specifications - I believe this is how the PNG sample addresses the issue, though it has been some time since I have looked at it closely enough to be sure.
----------------

At the back of my mind is another issue sort of related to this discussion.
As part of my interests in genealogy, I am currently using a Windows package of Gramps.
It is written in Python and one of the issues in porting it to Windows that seems to be lurking in the background is a problem with - or rather the lack of - using/editing image metadata in the Windows package.
As I understand things, it revolves around some difficulties in the use of the Exiv2 library Python interface under Windows.
Unfortunately, I don't know enough about the issue or python to be helpful to anyone in this regard.