Windows MSVC 2019 EXV_ICONV_CONST undefined

[tester0077]

Compiling the code form a newly cloned version from Github, (expected/intended to be 0.27-maintenance) under MSVC 2019 for a 32-bit version of Exiv2: In convert.cpp the line EXV_ICONV_CONST char inptr = const_cast<char>(str.c_str());

the line shown, causes the error: _1>convert.cpp 1>D:\pkg\C++\MSVC2019\exiv2Git\exiv2\src\convert.cpp(1527,25): error C2664: 'size_t libiconv(libiconv_t,const char ,size_t *,char *,size_t )': cannot convert argument 2 from 'char ' to 'const char **' 1>D:\pkg\C++\MSVC2019\exiv2Git\exiv2\src\convert.cpp(1528,31): message : Conversion loses qualifiers 1>C:\gnuwin32\include\iconv.h(92,37): message : see declaration of 'libiconv'_

This error causes most of the other sub-projects to also fail. Replacing EXV_ICONV_CONST with a plain 'const' allow this file to compile cleanly as well as all of the rest.

The sln file was created following the instructions for Windows MSVC compile https://github.com/Exiv2/exiv2/blob/master/README-CONAN.md

At this stage I have no idea about the version of libiconv, but the entire setup was presumably vetted by the conan install & update process.

Searching for the string "EXV_ICONV_CONST" does not show any instance except the line giving the error, implying that for the current setup it is not defined

Desktop (please complete the following information):

• OS: Windows 10, 64-bit
• Compiler & Version MSVC 2019
• Compilation mode and/or compiler flags

[clanmills]

I documented my profile and build procedure in #1251. When I ran the command:

C:\Users\rmills\gnu\github\exiv2\0.27-maintenance\arnold>cmake .. -G "Visual Studio 16 2019"
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.18362.
-- The CXX compiler identification is MSVC 19.26.28806.0
-- The C compiler identification is MSVC 19.26.28806.0
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.26.28801/bin/Hostx64/x64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.26.28801/bin/Hostx64/x64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.26.28801/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.26.28801/bin/Hostx64/x64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Conan: Using cmake targets configuration
-- Library zlib found C:/Users/rmills/.conan/data/zlib/1.2.11/conan/stable/package/a79a557254fabcb77849dd623fed97c9c5ab7651/lib/zlib.lib
-- Library gmock_main found C:/Users/rmills/.conan/data/gtest/1.8.1/bincrafters/stable/package/146430f32dcfadc1d6e788655671192747f9b80f/lib/gmock_main.lib
-- Library gmock found C:/Users/rmills/.conan/data/gtest/1.8.1/bincrafters/stable/package/146430f32dcfadc1d6e788655671192747f9b80f/lib/gmock.lib
-- Library gtest found C:/Users/rmills/.conan/data/gtest/1.8.1/bincrafters/stable/package/146430f32dcfadc1d6e788655671192747f9b80f/lib/gtest.lib
-- Library expat found C:/Users/rmills/.conan/data/Expat/2.2.6/pix4d/stable/package/015f2e164166e1813636fed4e71853aa01bc65a2/lib/expat.lib
-- Conan: Adjusting language standard
-- Current conanbuildinfo.cmake directory: C:/Users/rmills/gnu/github/exiv2/0.27-maintenance/arnold
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
-- Found ZLIB: C:/Users/rmills/.conan/data/zlib/1.2.11/conan/stable/package/a79a557254fabcb77849dd623fed97c9c5ab7651/lib/zlib.lib (found version "1.2.11")
-- Found EXPAT: C:/Users/rmills/.conan/data/Expat/2.2.6/pix4d/stable/package/015f2e164166e1813636fed4e71853aa01bc65a2/lib/expat.lib (found version "2.2.6")
-- Could NOT find Iconv (missing: Iconv_LIBRARY)    <---- DID NOT FIND ICONV
-- Looking for gmtime_r
-- Looking for gmtime_r - not found
-- Looking for mmap
-- Looking for mmap - not found
-- Looking for munmap
-- Looking for munmap - not found
-- Looking for strerror_r
-- Looking for strerror_r - not found
-- Performing Test EXV_STRERROR_R_CHAR_P
-- Performing Test EXV_STRERROR_R_CHAR_P - Failed
-- Looking for C++ include memory.h
-- Looking for C++ include memory.h - found
-- Looking for C++ include process.h
-- Looking for C++ include process.h - found
-- Looking for C++ include stdbool.h
-- Looking for C++ include stdbool.h - found
-- Looking for C++ include stdint.h
-- Looking for C++ include stdint.h - found
-- Looking for C++ include strings.h
-- Looking for C++ include strings.h - not found
-- Looking for C++ include sys/stat.h
-- Looking for C++ include sys/stat.h - found
-- Looking for C++ include sys/types.h
-- Looking for C++ include sys/types.h - found
-- Looking for C++ include inttypes.h
-- Looking for C++ include inttypes.h - found
-- Looking for C++ include unistd.h
-- Looking for C++ include unistd.h - not found
-- Looking for C++ include sys/mman.h
-- Looking for C++ include sys/mman.h - not found
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Failed
-- Performing Test COMPILER_HAS_DEPRECATED
-- Performing Test COMPILER_HAS_DEPRECATED - Success
-- Install prefix:    C:/Program Files (x86)/exiv2
-- ------------------------------------------------------------------
-- CMake Generator:   Visual Studio 16 2019
-- CMAKE_BUILD_TYPE:
-- Compiler info: MSVC (C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.26.28801/bin/Hostx64/x64/cl.exe) ; version: 19.26.28806.0
-- CMAKE_CXX_STANDARD:
--  --- Compiler flags ---
-- General:           /DWIN32 /D_WINDOWS /W3 /GR /EHsc
         /MP
         /Zc:__cplusplus
-- Extra:
-- Debug:             /MDd /Zi /Ob0 /Od /RTC1
-- Release:           /MD /O2  /DNDEBUG
-- RelWithDebInfo:    /MD /Zi /O2  /DNDEBUG
-- MinSizeRel:        /MD /O1  /DNDEBUG
--  --- Linker flags ---
-- General:           /machine:x64
-- Debug:             /debug /INCREMENTAL
-- Release:           /INCREMENTAL:NO
-- RelWithDebInfo:    /debug /INCREMENTAL
-- MinSizeRel:        /INCREMENTAL:NO
--
-- Compiler Options
-- Warnings as errors:                 NO
-- Use extra compiler warning flags:   NO
--
-- ------------------------------------------------------------------
-- Building shared library:            YES
-- Building PNG support:               YES
-- XMP metadata support:               YES
-- Native language support:            NO
-- Conversion of Windows XP tags:      YES
-- Nikon lens database:                YES
-- Building video support:             NO
-- Building webready support:          NO
-- Dynamic runtime override:           YES
-- Unicode paths (wstring):            NO
-- Building exiv2 command:             YES
-- Building samples:                   YES
-- Building PO files:                  NO
-- Building unit tests:                NO
-- Building doc:                       NO
-- Building with coverage flags:       NO
-- Using ccache:                       NO
-- ------------------------------------------------------------------
--  WARNING: Deprecated features: EPS, Video, Ssh
-- ------------------------------------------------------------------
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/rmills/gnu/github/exiv2/0.27-maintenance/arnold

C:\Users\rmills\gnu\github\exiv2\0.27-maintenance\arnold>

CMake generate the sln and several vcprojx files. He also generates this file:

C:\Users\rmills\gnu\github\exiv2\0.27-maintenance\arnold>type exv_conf.h
// File generated by cmake from cmake/config.h.cmake.

#ifndef _EXV_CONF_H_
#define _EXV_CONF_H_

// Defined if you want to use libssh for SshIO.
/* #undef EXV_USE_SSH */

// Define to 1 if you want to use libcurl in httpIO.
/* #undef EXV_USE_CURL */

// Define if you require webready support.
/* #undef EXV_ENABLE_WEBREADY */

// Define if you have the <libintl.h> header file.
/* #undef EXV_HAVE_LIBINTL_H */

// Define if you want translation of program messages to the user's native language
/* #undef EXV_ENABLE_NLS */

// Define if you want video support.
/* #undef EXV_ENABLE_VIDEO */

// Define if you have the strerror_r function.
/* #undef EXV_HAVE_STRERROR_R */

// Define if the strerror_r function returns char*.
/* #undef EXV_STRERROR_R_CHAR_P */

// Define to enable the Windows unicode path support.
/* #undef EXV_UNICODE_PATH */

/* Define to `const' or to empty, depending on the second argument of `iconv'. */
/* #undef ICONV_ACCEPTS_CONST_INPUT */
#if defined(ICONV_ACCEPTS_CONST_INPUT) || defined(__NetBSD__)
#define EXV_ICONV_CONST const
#else
#define EXV_ICONV_CONST     <---- CORRECT EXV_ICONV_CONST is nothing!
#endif

// Define if you have the <regex.h> header file.
/* #undef EXV_HAVE_REGEX_H */

// Define if have the <memory.h> header file.
#define EXV_HAVE_MEMORY_H

// Define if stdbool.h conforms to C99.
#define EXV_HAVE_STDBOOL_H

// Define if you have the <stdint.h> header file.
#define EXV_HAVE_STDINT_H

// Define if you have the <strings.h> header file.
/* #undef EXV_HAVE_STRINGS_H */

// Define if you have the mmap function.
/* #undef EXV_HAVE_MMAP */

// Define if you have the munmap function.
/* #undef EXV_HAVE_MUNMAP */

// Define if you have <sys/stat.h> header file.
#define EXV_HAVE_SYS_STAT_H

// Define if you have  the <sys/types.h> header file.
#define EXV_HAVE_SYS_TYPES_H

/* Define if you have the <unistd.h> header file. */
/* #undef EXV_HAVE_UNISTD_H */

// Define if you have the <sys/mman.h> header file.
/* #undef EXV_HAVE_SYS_MMAN_H */

// Define if you have are using the zlib library.
#define EXV_HAVE_LIBZ

// Define if you have the <process.h> header file.
#define EXV_HAVE_PROCESS_H

/* Define if you have (Exiv2/xmpsdk) Adobe XMP Toolkit. */
#define EXV_HAVE_XMP_TOOLKIT

/* Define to the full name of this package. */
#define EXV_PACKAGE_NAME "exiv2"

/* Define to the full name and version of this package. */
#define EXV_PACKAGE_STRING "exiv2 0.27.3.20"

/* Define to the version of this package. */
#define EXV_PACKAGE_VERSION "0.27.3.20"

#define EXIV2_MAJOR_VERSION (0)
#define EXIV2_MINOR_VERSION (27)
#define EXIV2_PATCH_VERSION (3)
#define EXIV2_TWEAK_VERSION (20)

// Definition to enable translation of Nikon lens names.
#define EXV_HAVE_LENSDATA

// Define if you have the iconv function.
/* #undef EXV_HAVE_ICONV */                   <---- CORRECT WE DON'T HAVE ICONV

// Definition to enable conversion of UCS2 encoded Windows tags to UTF-8.
#define EXV_HAVE_PRINTUCS2

#endif /* !_EXV_CONF_H_ */

C:\Users\rmills\gnu\github\exiv2\0.27-maintenance\arnold>

Can you run the cmake command and let me see both the output from CMake and the file exv_conf.h which is generated.

I suspect that you are picking up a "rogue" version of exv_conf.h and not the one generated by CMake. There is a compiler setting in Visual Studio "Show Includes" which echos the path of include files used by the compiler.

I also suspect that you are detecting iconv on your platform and we can confirm that with the output from the cmake .. -G do-dah command.

I don't know anything very much about ICONV. It was added to Exiv2 before I joined the project in 2008 and hasn't caused significant pain. I believe it's purpose is to perform character conversion for comments and used by the UserComment, GPSInfo.GPSProcessingMethod and GPSInfo.GPSAreaInformation I updated the Exiv2 man page in 0.27.3 to explain how to use UNICODE and other character sets in those tags.

[tester0077]

Hi Robbin, thank you for the quick response, but this issue only concerns a macro which seems undefined

Compiling the code form a newly cloned version from Github, (expected/intended to be 0.27-maintenance) under MSVC 2019 for a 32-bit version of Exiv2:
In convert.cpp the line
EXV_ICONV_CONST char* inptr = const_cast<char*>(str.c_str());

though it may well be related to my trying for a 32-bit compile. I'll respond to the other issue related to #976 later today, once I have had a better chance at sorting out the details and I will try add my conan profile and commands at that time

[clanmills]

Only one b in Robin (some would say there are lots of bees in Robin)

I would like to see:

1. output of the command cmake .. -G doo-dah when you create your solution file
2. the generated file exv_conf.h

If they seem to correct (mine are above), then you need to switch on the compilers "Show include files" input file and find out which exv_conf.h is being used.

I don't know how you can get a 32 bit build from Visual Studio 2019 Community Edition. For sure, it doesn't offer it to me.

Robin

[tester0077]

My sincere apologies for misspelling your name, Robin. My only excuse is that it was ~ 4:00 AM when I could not sleep.

buildOutput.txt

exv_conf.zip

As for getting 32-bit compile from MSCVC community edition, I have done so for ages - moving up over the years from MSVC 2005 and have never had any problems with that. In fact, the recent versions - after about 2010, make it possible to use tool chains from earlier compilers, which means I probably could compile using MSVC 2010 libraries for XP Arnold

[clanmills]

Solved. CMake is picking up something suspicious.

-- Found Iconv: C:/gnuwin32/lib/libiconv.lib
-- ICONV_INCLUDE_DIR : C:/gnuwin32/include
-- ICONV_LIBRARIES : C:/gnuwin32/lib/libiconv.lib

The quick fix is to modify the file cmake/FindIconv.cmake to never attempt to find Iconv when building with Visual Studio:

#if ( NOT MSVC )
... all of the existing code....
#endif

There's very little in README.md about libiconv. The final "tweak" in Exiv2 v0.27.3 was to add section 2.18 Static and Shared Libraries which was added in response to a user issue concerning linking libiconv. I wrote the documentation without understanding the issue which was handled by @piponazo

I looked at an article today on CodeProject about building libiConv on Windows. https://www.codeproject.com/Articles/302012/How-to-Build-libiconv-with-Microsoft-Visual-Studio I'm going to read the article in CodeProject and then decide what to do about this.

I see you are building from master. I haven't submitted anything to master for about 2 years. When I do something about this, it'll go into the 0.27-maintenance branch. Will changes get ported to 'master'? I don't know.

[tester0077]

It was my intention to build from 0.27.3-maintenance, but with my current level of git & Github skills I might be off on that, and evidently am.

Which would be the recommended link to work from?

FWIW, the 0.27.2 link on https://github.com/Exiv2/exiv2/projects is dead.

In working with this issue, I had noticed that conan seemed to pick my 32-bit libiconv in c:\gnuwin32\bin. It struck me as odd, but not being familiar with 32/64-bit interoperability I don't know if that is kosher or not. In one or other of my projects I believe I had to build libiconv in the past, and in fact, the very project I am working on right now includes a copy - though I have no idea which version, nor do I recall where it came from, but it keeps the compiler & linker happy.

[clanmills]

Thanks for letting me know about the broken link. I've fixed that and added links to the 0.27.3 release tags.

I think you should work on 0.27-maintenance for now because I'm active in that branch.

Lots of good work has been done in the past on 0.28 on 'master'. Progress this year has been glacial and I wonder if 0.28 will ever be finished. I'm totally focused on my book and say "It'll be finished in 2020". I'm hoping it might get finished by the end of August. I've offered to release 'master' as 0.28 and had no response.

Set up a clone of 0.27-maintenance and work there:

$ mkdir c:\Users\yourusername\gnu\github\exiv2
$ git clone https://github.com/exiv2/exiv2 --branch 0.27-maintenance 0.27-maintenance --depth 1
$ cd 0.27-maintenance
$ git fetch --unshallow
$ mkdir build
$ cd build
$ conan install .. --profile aaaaaaa --build missing
$ cmake .. -G do-dah -DEXIV2_ENABLE_DYNAMIC_RUNTIME=Off -DBUILD_SHARED_LIBS=Off
$ cmake --build . --config Release

In README.md for Exiv2 v0.27.3, I have documented my batch file cmd64.bat which I use to set up my cmd shell for building. It uses a "stripped" down PATH to protect the build environment from finding Cygwin64 or MinGW/msys2 libraries. You may find that batch file also "hides" C:/gnuwin32 from CMake for you.

I read the article on Code Project. I will add the if (NOT MSVC)...endif() to cmake/FindIconv.cmake and say something about libiconv in README.md. like this:

In general libiconv is a GNU library and we do not recommend building Exiv2 on Visual Studio to use libiconv. There is an article here about building libiconv with Visual Studio. If you are successful in building the library, you will have to remove the "guard" in cmake/FindIconv.cmake which ensures that Visual Studio never finds libiconv.

Right. Saturday Night. I seldom watch TV, however there's a program this evening that interests me and Alison: https://www.bbc.co.uk/programmes/m000l3vn

[tester0077]

following your instructions, I cloned a new repository , as follows:

CD D:\pkg\C++\MSVC2019\exiv2Git\
git clone https://github.com/exiv2/exiv2 --branch 0.27-maintenance 0.27-maintenance --depth 1
cd 0.27-maintenance
git fetch --unshallow
mkdir build32deb
mkdir build32rel
cd build32deb
conan install .. --build missing --profile msvc2019Debug32Static
cmake .. -G "Visual Studio 16 2019" -A Win32 -DEXIV2_ENABLE_DYNAMIC_RUNTIME=Off -DBUILD_SHARED_LIBS=Off
cmake --build . --config Debug

When I compare the changes between my old version and the new 0.27-maint code using KDiff3, I find loads of changes from what I had. The curious thing is that when I let CMake compile the works, I get the following output:

 exiv2-xmp.vcxproj -> D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\lib\Debug\exiv2-xmp.lib
  Building Custom Rule D:/pkg/C++/MSVC2019/exiv2Git/0.27-maintenance/src/CMakeLists.txt
  basicio.cpp
  bigtiffimage.cpp
  bmpimage.cpp
  convert.cpp
  cr2image.cpp
  crwimage.cpp
  datasets.cpp
  easyaccess.cpp
D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\src\basicio.cpp(1304,41): warning C4018: '>': signed/unsigned mismatch [D
:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\src\exiv2lib.vcxproj]
**D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\src\convert.cpp(1548,25): error C2664: 'size_t libiconv(libiconv_t,const
char **,size_t *,char **,size_t *)': cannot convert argument 2 from 'char **' to 'const char **' [D:\pkg\C++\MSVC2019\e
xiv2Git\0.27-maintenance\build32deb\src\exiv2lib.vcxproj]
D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\src\convert.cpp(1549,31): message : Conversion loses qualifiers [D:\pkg\C
++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\src\exiv2lib.vcxproj]**
C:\gnuwin32\include\iconv.h(92,37): message : see declaration of 'libiconv' (compiling source file D:\pkg\C++\MSVC2019\
exiv2Git\0.27-maintenance\src\convert.cpp) [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\src\exiv2lib.vcxpr
oj]
  epsimage.cpp

if I replace the line in convert.cpp # 1542 EXV_ICONV_CONST char inptr = const_cast<char>(str.c_str()); with const char inptr = const_cast<char>(str.c_str());

exiv2lib builds without complaint, but I get a whole lot of warning and some other errors, which did not show up before:

D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb>cmake --build . --config Debug
Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

  Checking Build System
  Building Custom Rule D:/pkg/C++/MSVC2019/exiv2Git/0.27-maintenance/src/CMakeLists.txt
  canonmn_int.cpp
  casiomn_int.cpp
  cr2header_int.cpp
  crwimage_int.cpp
  fujimn_int.cpp
  helper_functions.cpp
  image_int.cpp
  makernote_int.cpp
  minoltamn_int.cpp
  nikonmn_int.cpp
  olympusmn_int.cpp
  orfimage_int.cpp
  panasonicmn_int.cpp
  pentaxmn_int.cpp
  rw2image_int.cpp
  samsungmn_int.cpp
  sigmamn_int.cpp
  sonymn_int.cpp
  tags_int.cpp
  tiffcomposite_int.cpp
  tiffimage_int.cpp
  tiffvisitor_int.cpp
  pngchunk_int.cpp
  exiv2lib_int.vcxproj -> D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\src\exiv2lib_int.dir\Debug\exiv2lib_
  int.lib
  Building Custom Rule D:/pkg/C++/MSVC2019/exiv2Git/0.27-maintenance/xmpsdk/CMakeLists.txt
  ExpatAdapter.cpp
  MD5.cpp
  ParseRDF.cpp
  UnicodeConversions.cpp
  WXMPIterator.cpp
  WXMPMeta.cpp
  WXMPUtils.cpp
  XML_Node.cpp
  XMPCore_Impl.cpp
  XMPIterator.cpp
  XMPMeta-GetSet.cpp
  XMPMeta-Parse.cpp
  XMPMeta-Serialize.cpp
  XMPMeta.cpp
  XMPUtils-FileInfo.cpp
  XMPUtils.cpp
  exiv2-xmp.vcxproj -> D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\lib\Debug\exiv2-xmp.lib
  Building Custom Rule D:/pkg/C++/MSVC2019/exiv2Git/0.27-maintenance/src/CMakeLists.txt
  basicio.cpp
  bigtiffimage.cpp
  bmpimage.cpp
  convert.cpp
  cr2image.cpp
  crwimage.cpp
  datasets.cpp
  easyaccess.cpp
D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\src\basicio.cpp(1304,41): warning C4018: '>': signed/unsigned mismatch [D
:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\src\exiv2lib.vcxproj]
  epsimage.cpp
  error.cpp
  exif.cpp
  futils.cpp
  gifimage.cpp
  http.cpp
  image.cpp
  ini.cpp
  iptc.cpp
  jp2image.cpp
  jpgimage.cpp
  metadatum.cpp
  mrwimage.cpp
  orfimage.cpp
  pgfimage.cpp
  preview.cpp
  properties.cpp
  psdimage.cpp
  rafimage.cpp
  rw2image.cpp
  tags.cpp
  tgaimage.cpp
  tiffimage.cpp
  types.cpp
  value.cpp
  version.cpp
  webpimage.cpp
  xmp.cpp
  xmpsidecar.cpp
  pngimage.cpp
  exiv2lib.vcxproj -> D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\lib\Debug\exiv2.lib
  Building Custom Rule D:/pkg/C++/MSVC2019/exiv2Git/0.27-maintenance/samples/CMakeLists.txt
  addmoddel.cpp
zlib.lib(compress.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/SAFESEH' specification [D:\pkg\C++\MSVC2
019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
zlib.lib(compress.obj) : warning LNK4099: PDB 'zlibstatic.pdb' was not found with 'zlib.lib(compress.obj)' or at 'D:\pk
g\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\bin\zlibstatic.pdb'; linking object as if no debug info [D:\pkg\C++
\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
zlib.lib(uncompr.obj) : warning LNK4099: PDB 'zlibstatic.pdb' was not found with 'zlib.lib(uncompr.obj)' or at 'D:\pkg\
C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\bin\zlibstatic.pdb'; linking object as if no debug info [D:\pkg\C++\M
SVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
zlib.lib(crc32.obj) : warning LNK4099: PDB 'zlibstatic.pdb' was not found with 'zlib.lib(crc32.obj)' or at 'D:\pkg\C++\
MSVC2019\exiv2Git\0.27-maintenance\build32deb\bin\zlibstatic.pdb'; linking object as if no debug info [D:\pkg\C++\MSVC2
019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
zlib.lib(deflate.obj) : warning LNK4099: PDB 'zlibstatic.pdb' was not found with 'zlib.lib(deflate.obj)' or at 'D:\pkg\
C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\bin\zlibstatic.pdb'; linking object as if no debug info [D:\pkg\C++\M
SVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
zlib.lib(inflate.obj) : warning LNK4099: PDB 'zlibstatic.pdb' was not found with 'zlib.lib(inflate.obj)' or at 'D:\pkg\
C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\bin\zlibstatic.pdb'; linking object as if no debug info [D:\pkg\C++\M
SVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
zlib.lib(adler32.obj) : warning LNK4099: PDB 'zlibstatic.pdb' was not found with 'zlib.lib(adler32.obj)' or at 'D:\pkg\
C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\bin\zlibstatic.pdb'; linking object as if no debug info [D:\pkg\C++\M
SVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
zlib.lib(zutil.obj) : warning LNK4099: PDB 'zlibstatic.pdb' was not found with 'zlib.lib(zutil.obj)' or at 'D:\pkg\C++\
MSVC2019\exiv2Git\0.27-maintenance\build32deb\bin\zlibstatic.pdb'; linking object as if no debug info [D:\pkg\C++\MSVC2
019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
zlib.lib(trees.obj) : warning LNK4099: PDB 'zlibstatic.pdb' was not found with 'zlib.lib(trees.obj)' or at 'D:\pkg\C++\
MSVC2019\exiv2Git\0.27-maintenance\build32deb\bin\zlibstatic.pdb'; linking object as if no debug info [D:\pkg\C++\MSVC2
019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
zlib.lib(inftrees.obj) : warning LNK4099: PDB 'zlibstatic.pdb' was not found with 'zlib.lib(inftrees.obj)' or at 'D:\pk
g\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\bin\zlibstatic.pdb'; linking object as if no debug info [D:\pkg\C++
\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
zlib.lib(inffast.obj) : warning LNK4099: PDB 'zlibstatic.pdb' was not found with 'zlib.lib(inffast.obj)' or at 'D:\pkg\
C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\bin\zlibstatic.pdb'; linking object as if no debug info [D:\pkg\C++\M
SVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library [D:\pkg\C++\MS
VC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
LINK : warning LNK4217: symbol '_free' defined in 'libucrtd.lib(free.obj)' is imported by 'zlib.lib(zutil.obj)' in func
tion '_zcfree' [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
LINK : warning LNK4286: symbol '_free' defined in 'libucrtd.lib(free.obj)' is imported by 'expat.lib(xmlparse.obj)' [D:
\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
LINK : warning LNK4286: symbol '_free' defined in 'libucrtd.lib(free.obj)' is imported by 'expat.lib(loadlibrary.obj)'
[D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
LINK : warning LNK4217: symbol '_malloc' defined in 'libucrtd.lib(malloc.obj)' is imported by 'zlib.lib(zutil.obj)' in
function '_zcalloc' [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
LINK : warning LNK4286: symbol '_malloc' defined in 'libucrtd.lib(malloc.obj)' is imported by 'expat.lib(xmlparse.obj)'
 [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
LINK : warning LNK4286: symbol '_malloc' defined in 'libucrtd.lib(malloc.obj)' is imported by 'expat.lib(loadlibrary.ob
j)' [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
LINK : warning LNK4217: symbol '__wassert' defined in 'libucrtd.lib(assert.obj)' is imported by 'expat.lib(xmlparse.obj
)' in function '_XML_GetParsingStatus' [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxp
roj]
LINK : warning LNK4217: symbol '___acrt_iob_func' defined in 'libucrtd.lib(_file.obj)' is imported by 'expat.lib(xmlpar
se.obj)' in function '_ENTROPY_DEBUG' [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxpr
oj]
LINK : warning LNK4217: symbol '___stdio_common_vfprintf' defined in 'libucrtd.lib(output.obj)' is imported by 'expat.l
ib(xmlparse.obj)' in function '__vfprintf_l' [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmodde
l.vcxproj]
LINK : warning LNK4217: symbol '_realloc' defined in 'libucrtd.lib(realloc.obj)' is imported by 'expat.lib(xmlparse.obj
)' in function '_parserCreate' [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
LINK : warning LNK4217: symbol '_getenv' defined in 'libucrtd.lib(getenv.obj)' is imported by 'expat.lib(xmlparse.obj)'
 in function '_ENTROPY_DEBUG' [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
expat.lib(loadlibrary.obj) : error LNK2019: unresolved external symbol __imp___mbspbrk referenced in function __tcspbrk
 [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
MSVCRTD.lib(chandler4gs.obj) : error LNK2019: unresolved external symbol __except_handler4_common referenced in functio
n __except_handler4 [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\bin\addmoddel.exe : fatal error LNK1120: 2 unresolved external
s [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
  Building Custom Rule D:/pkg/C++/MSVC2019/exiv2Git/0.27-maintenance/samples/CMakeLists.txt
  conntest.cpp
......

HTH :(

[clanmills]

Please add the code I have suggested to cmake/FindIConv.cmake and build again.

I don't think it's possible to build Exiv2 with libiconv on Visual Studio and that's what I'm going to say in README.md Since we last spoke, I've downloaded the latest version and looked at libiconv-1.16/INSTALL.windows. I wouldn't attempt to build that on Visual Studio. That's not a cross-platform library. It's a Linux thing with some hard to follow instructions to build on Windows. Exiv2, zlib and always every library was in that state in 2008.

You might encounter 32 bit oddities as we have more or less stopped building 32 bit versions now. Cygwin32 and MinGW are obsolete.

'master' and '0.27-maintenance' are diverging and this is planned and intentional. 0.27-maintenance is intended to keep Exiv2 alive while the guys finish 0.28. 0.28 is not backwards compatible.

[clanmills]

About all those linker warning and stuff. It looks to me that there is a fatal collision in zlib/expat and the c-runtime concerning _getenv()

LINK : warning LNK4217: symbol '_getenv' defined in 'libucrtd.lib(getenv.obj)' is imported by 'expat.lib(xmlparse.obj)'
 in function '_ENTROPY_DEBUG' [D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\build32deb\samples\addmoddel.vcxproj]
expat.lib(loadlibrary.obj) 

This didn't happen to me when I build the 64 bit configuration this morning. Can you investigating using my script cmd64.bat to "sanitise" your environment. I'll need to see the output from both the conan install .. command and the cmake .. -G doo-dah to know what libraries you are trying to use.

I personally don't like static linking and much prefer to work with DLLs. I know that static linking works. I encourage you to use dynamic linking. And I don't know why you are building a debug version of the library as applications are expect to link the release version.

[clanmills]

I have submitted PR #1253 to disable Visual Studio from linking libiconv. I have updated README.md to explain why I have done this. I will not provide further support for Visual Studio with libiconv.

[tester0077]

just a brief update. Renaming the libiconv.lib found by conan/Cmake?? avoids the issues related to it and allows Wxiv2 to compile with only a warning about LIBCMTD' Meanwhile I am working to convert my app to 64-bit - it had been on the bottom of my todo-list for some time - but this brought it to the 'surface'. Naturally it means much of the support also needs to ne converted, si it may take some time, but I'll peck away at it and will report back as I find fixes.

[clanmills]

I suspect if you use my script cmd64.bat to set up your path, CMake will not find the library in C:/gnuwin32/lib/libiconv.lib.

I've updated cmake/FindIconv.cmake on 0.27-maintenance, so he can't find it.

> cd <exiv2dir>
> git pull --rebase
> cd build
> cmake --build . --config Release

Good idea to move to 64-bit.

I'm puzzled by the LIBCMTD warning because that doesn't happen to me. I will know what's happening if you send the output of the a clean new build

> rmdir/s/q c:\Users\yourusername\.conan\data    # throw away the conan cache
> cd <exiv2dir>
> mkdir robin_build
> cd robin_build
> conan install .. etc...
> cmake .. -G ....  etc..
> cmake --build . -config Release

[tester0077]

Hi Robin, this is turning into a real mare's nest I have cloned the new repository and built a clean version as you suggested, but no luck as yet. I had thought the issue might be due to my conan profile, but changing compiler.runtime=MTd to compiler.runtime=MD did not help either. I am attaching the log from my tests. RobinBuildLog.txt

After fighting the issues with trying to using the latest Exiv2 64-bit DLL and converting my rather large project to 64-bit, I have run out of steam. It started out with my 32-bit app running well enough, using my current copy of an earlier release of 0.27.99.0 fiddled to replace the (for me) problematic free(). As I was about to expand the image metadata facilities of the app, I innocently thought, why not update my Exiv2 code to the latest version, and from there things have gone downhill at a rapid pace. Converting most of the base code of my app to 64 bit, seemed to be the easy part. Even converting some of my own support libraries, some of the third-party software such as zlib, libiconv & tiny-process-library seemed to go smooth enough, That is until today, when I ran out of ideas on resolving - among others - the problem of defaultlib 'LIBCMTD'. As a possible road to resolution, I figured I probably would also need to update the paths to Exiv2 includes as well as for all of the other new 64-bit support libraries. After all, if I expect the app to link to 64-bit libraries, it might be wise to also make sure I use the corresponding include files and that is where things went sour. I am convinced I will eventually sort it all out, but by now am am worn out. There are just too many potential issues and I will have to go back to my 32-bit version and work my way up to 64-bit in a more controlled fashion, converting some of my smaller apps one at a time and gaining experience to not get overwhelmed by too many cryptic errors all at once. :-(

[tester0077]

Shortly after posting the above, I found this StackOverflow comment, though I have not followed up on in it and probably won't for now; just wanted to record the reference for future consideration or possibly other user's with the same problem. From: https://stackoverflow.com/questions/3007312/resolving-lnk4098-defaultlib-msvcrt-conflicts-with

There are 4 versions of the CRT link libraries present in vc\lib:

    libcmt.lib: static CRT link library for a release build (/MT)
    libcmtd.lib: static CRT link library for a debug build (/MTd)
    msvcrt.lib: import library for the release DLL version of the CRT (/MD)
    msvcrtd.lib: import library for the debug DLL version of the CRT (/MDd)

Look at the linker options, Project + Properties, Linker, Command Line. Note how these libraries are not mentioned here. The linker automatically figures out what /M switch was used by the compiler and which .lib should be linked through a #pragma comment directive. Kinda important, you'd get horrible link errors and hard to diagnose runtime errors if there was a mismatch between the /M option and the .lib you link with.

You'll see the error message you quoted when the linker is told both to link to msvcrt.lib and libcmt.lib. Which will happen if you link code that was compiled with /MT with code that was linked with /MD. There can be only one version of the CRT.

/NODEFAULTLIB tells the linker to ignore the #pragma comment directive that was generated from the /MT compiled code. This might work, although a slew of other linker errors is not uncommon. Things like errno, which is a extern int in the static CRT version but macro-ed to a function in the DLL version. Many others like that.

Well, fix this problem the Right Way, find the .obj or .lib file that you are linking that was compiled with the wrong /M option. If you have no clue then you could find it by grepping the .obj/.lib files for "/MT"

Btw: the Windows executables (like version.dll) have their own CRT version to get their job done. It is located in c:\windows\system32, you cannot reliably use it for your own programs, its CRT headers are not available anywhere. The CRT DLL used by your program has a different name (like msvcrt90.dll).

[clanmills]

Yes. I know about the dreaded /M option. I mentioned earlier about my surprise that it was NOT propagated from the profile to the generated project. That's why I wanted to see the output of a clean build to let me see what you have built and to see it you are linking the stuff built by conan, or, as I suspect, you are linking other stuff that's sitting elsewhere on your disk.

I'll look at the files you sent after breakfast. I'm still in bed at the moment.

It's not easy to sort these muddles. In Silicon Valley, you'd be given 24 hours to fix this or you'd be fired! However, we're not in Silicon Valley , so we'll calmly work through the issue and solve this. I got into exactly this state with a project at Adobe and it turned out to be the UI flag "link library dependencies" was set to yes. I solved it (and saved my job) in the office on a Sunday morning. The scar has not healed.

Linux lovers would of course say that Windows is not suitable for any purpose. Linux is a different bed of nails with its own awfulness.

If I can't fix this with the output you have provided, I'll have to either screen share or get your code on my machine.

[clanmills]

OK. You're getting a couple of warnings:

1 When you link the library:

zlib.lib(compress.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification [D:\pkg\C++\MSVC2
019\exiv2Git\0.27-maintenance\robin_build\src\exiv2lib.vcxproj]
     Creating library D:/pkg/C++/MSVC2019/exiv2Git/0.27-maintenance/robin_build/lib/Release/exiv2.lib and object D:/pkg
  /C++/MSVC2019/exiv2Git/0.27-maintenance/robin_build/lib/Release/exiv2.exp
LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library [D:\pkg\C++\MS
VC2019\exiv2Git\0.27-maintenance\robin_build\src\exiv2lib.vcxproj]

2. When you link geotag.exe which links expat AND exiv2:

  Building Custom Rule D:/pkg/C++/MSVC2019/exiv2Git/0.27-maintenance/samples/CMakeLists.txt
  geotag.cpp
LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library [D:\pkg\C++\MS
VC2019\exiv2Git\0.27-maintenance\robin_build\samples\geotag.vcxproj]
  geotag.vcxproj -> D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\robin_build\bin\geotag.exe

3. Everything else links cleanly. So, it's only when linking expat that we see this warning.

I don't believe either are fatal. Or am I mistaken?

I suspect there's something not quite right in how conan builds expat. I see it's built with something involving pix4d and that's where Luis used to work. So, I think Luis wrote the recipe and maybe it's linking the wrong run-time or something. I will investigate.

-- Build files have been written to: C:/Users/arnold/.conan/data/Expat/2.2.6/pix4d/stable/build/650f3e9348ed8a4a1efa77cbb89e83c52097089a/build
Expat/2.2.6@pix4d/stable: WARN: HAVE_GETRANDOM could not be undefined. It was not defined
Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

  Checking Build System
  Building Custom Rule C:/Users/arnold/.conan/data/Expat/2.2.6/pix4d/stable/build/650f3e9348ed8a4a1efa77cbb89e83c52097089a/libexpat/expat/CMakeLists.txt
  loadlibrary.c
  xmlparse.c
  xmlrole.c
  xmltok.c
  xmltok_impl.c
  xmltok_ns.c
  expat.vcxproj -> C:\Users\arnold\.conan\data\Expat\2.2.6\pix4d\stable\build\650f3e9348ed8a4a1efa77cbb89e83c52097089a\build\lib\expat.lib
  Building Custom Rule C:/Users/arnold/.conan/data/Expat/2.2.6/pix4d/stable/build/650f3e9348ed8a4a1efa77cbb89e83c52097089a/libexpat/expat/CMakeLists.txt
Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

  expat.vcxproj -> C:\Users\arnold\.conan\data\Expat\2.2.6\pix4d\stable\build\650f3e9348ed8a4a1efa77cbb89e83c52097089a\build\lib\expat.lib
  -- Install configuration: "Debug"
  -- Installing: C:/Users/arnold/.conan/data/Expat/2.2.6/pix4d/stable/package/650f3e9348ed8a4a1efa77cbb89e83c52097089a/lib/expat.lib
  -- Installing: C:/Users/arnold/.conan/data/Expat/2.2.6/pix4d/stable/package/650f3e9348ed8a4a1efa77cbb89e83c52097089a/include/expat.h
  -- Installing: C:/Users/arnold/.conan/data/Expat/2.2.6/pix4d/stable/package/650f3e9348ed8a4a1efa77cbb89e83c52097089a/include/expat_external.h
  -- Installing: C:/Users/arnold/.conan/data/Expat/2.2.6/pix4d/stable/package/650f3e9348ed8a4a1efa77cbb89e83c52097089a/lib/pkgconfig/expat.pc
Expat/2.2.6@pix4d/stable: Package '650f3e9348ed8a4a1efa77cbb89e83c52097089a' built
Expat/2.2.6@pix4d/stable: Build folder C:\Users\arnold\.conan\data\Expat\2.2.6\pix4d\stable\build\650f3e9348ed8a4a1efa77cbb89e83c52097089a
Expat/2.2.6@pix4d/stable: Generated conaninfo.txt
Expat/2.2.6@pix4d/stable: Generated conanbuildinfo.txt
Expat/2.2.6@pix4d/stable: Generating the package
Expat/2.2.6@pix4d/stable: Package folder C:\Users\arnold\.conan\data\Expat\2.2.6\pix4d\stable\package\650f3e9348ed8a4a1efa77cbb89e83c52097089a
Expat/2.2.6@pix4d/stable: Calling package()
Expat/2.2.6@pix4d/stable: WARN: This conanfile has no package step
Expat/2.2.6@pix4d/stable package(): Packaged 2 '.h' files: expat.h, expat_external.h
Expat/2.2.6@pix4d/stable package(): Packaged 1 '.lib' file: expat.lib
Expat/2.2.6@pix4d/stable package(): Packaged 1 '.pc' file: expat.pc
Expat/2.2.6@pix4d/stable: Package '650f3e9348ed8a4a1efa77cbb89e83c52097089a' created
Expat/2.2.6@pix4d/stable: Created package revision 1a9586fe957e7ea64d76b38d4e6fd8be

[clanmills]

I don't know what problem we are solving here. I builds cleanly on my machine with not one single warning.

I notice that you have and debug/release mismatch.

D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\robin_build>conan install ..  --build missing --profile msvc2019Debug64Dll
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=Visual Studio
compiler.runtime=MTd
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

And you're building release:

> cmake --build . --config Release

[tester0077]

Hi Robin,

thank you for your feedback. Sometimes a fresh pair of eyes sees things which are hidden in plain sight.

Unfortunately, there is still a lot I have to learn about the build process used with Exiv2.

And, with time, I will have another go at these issues.

Over the past couple of days, I have been able to build one of my skeleton apps for 32 & 64-bits, which means some progress towards the goal.

For this, I ended up installing another package manager which integrates with MSVC - vcpkg - and it allowed me to install one of my required dependencies - libcurl - without any fuss for both 32 & 64-bit versions.

As time permits and the need arises, I will try to replace some of the other dependencies for those of my apps which use Exiv2, and hope to bootstrap the whole process over time.

Looking forward to see your book completed, because it will be a good resource.

Arnold

On 2020-07-21 1:05 AM, Robin Mills wrote:

I don't know what problem we are solving here. I builds cleanly on my machine with not one single warning.

I notice that you have and debug/release mismatch.

|D:\pkg\C++\MSVC2019\exiv2Git\0.27-maintenance\robin_build>conan install .. --build missing --profile msvc2019Debug64Dll Configuration: [settings] arch=x86_64 arch_build=x86_64 build_type=Debug compiler=Visual Studio compiler.runtime=MTd compiler.version=16 os=Windows os_build=Windows [options] [build_requires] [env] |

And you're building release:

|> cmake --build . --config Release |

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Exiv2/exiv2/issues/1250#issuecomment-661703098, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFCLPG22CUVFWWTKWJUWTLR4VD4JANCNFSM4O7BUW6A.

[clanmills]

Ah, yes. vcpkg. A person called Jason offered to investigate and work on that. Never heard from him again.

I think the open source model simply doesn't work. It's almost impossible to recruit and retain volunteers. Exiv2 isn't very big at 100,000 lines of code. However it's big enough to be challenging.

The list of things that can and should be investigated is long and never gets shorter. The only steady contributor is an exhausted old man. If I die before the book is finished, I expect to receive an email of complaint before my funeral to say "how could you be so selfish and unreasonable .... ". Alison has promised that the book will be printed and set in music to Schubert's 8th Symphony.

There's nothing unusual about Exiv2's build machinery. At least I thoroughly investigate every report and respond rapidly. When I joined Adobe, I was required to build the PostScript Interpreter for OEM XXX on a Mac (which I had never used). When I said to the boss "I don't know how to do this.", he replied "You know who XXX is and you know what a PostScript Interpreter is and you know what Friday is. So there's no problem. Get it done!". There was no documentation whatsoever. I couldn't even power up the Mac. I didn't know the power button was on the keyboard. And of course, it was horrible macOS 8.1 with no terminal window, the compiler was Metroworks Code Warrior and everything was done by dragging and dropping.

By comparison. Exiv2 has good/solid build documentation, man page, on-line API documents, sample code and personalised support. And soon a book Image Metadata and Exiv2 Architecture. In fact, the code, documentation and support are better than most commercial software products. Pretty good for free. And to show their appreciation, many users send me abusive emails. Not you, you've always been nice.

And another matter, as I am enjoying having a good old moan, the release process for Exiv2 is thorough and careful. I assure you that any bugs that ship in a release are unknown to me. And guess who has to do the release, write the documentation, fix bugs, add new features and accept the criticism of the community? However I get lots of helpful feedback such as "I don't like the font you used in your book.".

So, smile and be happy - while I'm alive. And I'll do the same! I'm going to close this now. When you "fire up" again, open a new issue and we'll continue the conversation.

[tester0077]

Hi Robin,

On 2020-07-22 10:15 AM, Robin Mills wrote:

Ah, yes. vcpkg. A person called Jason offered to investigate and work on that. Never heard from him again.

Yeah, I know, though I am not proposing to to convert anyone to vcpkg. But it works for me and I expect it will help me resolve some of the 64-bit issues not necessarily related to Exiv2 in my effort to move towards the 64-bit environment.

I think the open source model simply doesn't work. It's almost impossible to recruit and retain volunteers. Exiv2 isn't very big at 100,000 lines of code. However it's big enough to be challenging.

IMO, the progress of the open source model code is predicated on 'need' by people just close enough to be able to help.

I am very much impressed by open source, including Exiv2. I am using a lot of open source software and without it, my hobby/work would be impossible. But there is so much out there and each project uses the original authors favorite tools, environment and assumptions, much of it Linux based, which still is not really second nature to me.

The list of things that can and should be investigated long and never gets shorter. The only steady contributor is an exhausted old man. If I die before the book is finished, I expect to receive an email of complaint about "how could you be so selfish and unreasonable .... ". Alison has promised that the book will be printed and set in music to Schubert's 8th Symphony.

Sounds like both of you are very much musically inclined. :-) Myself, not so much ;-)

There's nothing unusual about Exiv2's build machinery. At least I thoroughly investigate every report and respond rapidly. When I joined Adobe, I was required to build the PostScript Interpreter for OEM XXX on a Mac (which I had never used). When I said to the boss "I don't know how to do this.", he replied "You know who XXX is and you know what a PostScript Interpreter is and you know what Friday is. So there's no problem. Get it done!". I couldn't even power up the Mac. There was no documentation whatsoever. I didn't know the power button was on the keyboard. And of course, it was horrible macOS 8.1 with no terminal window, the compiler was Metroworks Code Warrior and everything was done by dragging and dropping.

I can well understand. My work history parallel yours in many ways. From IBM card punches, to Dupont pneumatic control systems for Nylon precursor production, to maintenance of wire drawing machinery, PDP-8, amateurish hobby work on the 8008 on to a home-brew Apple, then 8080 S100 system, on to DOS & Win 3 and up. Just before 2000, I moved in to a different company, running Solaris for development of a pager system based on Motorola 6800 and using their own home-brew real-time OS, before retiring when the company more or less folded. As for age, I believe I am ahead of you by a good 10 years.

Hence, I would not make a very good candidate for a 'long-term', 'up-to-speed on all of the latest stuff' maintainer ;-)

By comparison. Exiv2 has good/solid build documentation, man page, on-line API documents, sample code and personalised support. And soon a book Image Metadata and Exiv2 Architecture. In fact, the code, documentation and support are better than most commercial software products. Pretty good for free. And to show their appreciation, many users send me abusive emails. Not you, you've always been nice.

I have been on the service end long enough to know your side of the world from first hand experience :-)

And another matter, as I am enjoying having a good old moan, the release process for Exiv2 is thorough and careful. I assure you that any bugs that ship in a release are unknown to me. And guess who has to do the release, write the documentation, fix bugs, add new features and accept the criticism of the community? However I get lots of helpful feedback such as "I don't like the font you used in your book.".

Yeah, after a while some of such 'helpful & constructive' comments can wear on anyone's nerves.

So, smile and be happy - while I'm alive. And I'll do the same! I'm going to close this now. When you "fire up" again, open a new issue and we'll continue the conversation.

Will do and

Keep safe & healthy in the meantime.

Arnold

[tester0077]

Hi Robin,

just a brief - or not so brief - update.

Over the course of the day, I have restarted my Exiv2 exploration after getting some of my test apps to compile and run as 64-bit apps.

After that, I tackled a somewhat smaller app, which also uses Exiv2 but does not have as much legacy code and not nearly as many dependencies.

After restarting with a clean clone of the maintenance branch, and using much of your 'recipe' for x86, checking my profile file, I still ran into the same issues and errors as before.

This time though, rather than running the cmake command directly, I then opened the same project with CMake GUI and had it create  a solution for me - with minimal fiddling - and for specifics of these 'fiddles', I'll have to backtrack a bit later (or next time).    :-) **

In the end, I was able to use that sln file to compile a clean 32-bit debug version. Still, if I try to compile the whole works, I get many of the same errors and complaints I get when I use the cmake command line. But, I am only really interested in exiv2lib and its dependencies.  So, I concentrated on those 3 and got all of them to compile without errors

• within MSVC 2019. Some progress.

Once I fiddled my app's sln and project files to look for the new Exiv2 code, I ended up with issues because the exiv2lib code apparently was compile with /MTd, while my app is compiled with /MDd. Where have we seen that before?? ;-)

After I replaced the /MTd to /MDd for the 3 sub project, may app compiled, linked and ran. Of course, there a couple of other things I had to update - mainly add psapi.lib and fix some UniquePtr stuff. **

With that working, I repeated the process, using the same .sln file as above, but selected  'release' and rebuilt the three items ( after I changed the /MT to /MD ) and I am now happily running my somewhat older 32-bit app  linked to the latest exiv2lib

As it looks right now, I will be sticking with the 32-bit. My experiments with 64-bit conversion were more or less successful, but they also showed all of the extra details that would and will have to considered and fixed or changed and adapted for a complete move to the 64 bit world.

For now, 64-bit is a longer term goal with out much appeal until some roadblock comes up, which will force my hand.

---

** At this point I want to confirm that the conan profile I used, contains : compiler.runtime=MDd

and my 'fiddles' in the CMake GUI did not involve /MT? as afar as I can see at this time.

where CMake gets /MT? from, I have no idea

Time to turn in soon.

Stay well and happy - "it could be worse", they tell me  :-)

Arnold

[tester0077]

Hi Robin,

me again, with a bit of good news, I hope.

Today, I concentrated on sorting out the idea I had been made aware of that the MSVC 2019 was supposed to be able to handle CMake files in a very good way.

After some false starts, I was able to clone and compile the latest 0.27 maintenance code for 64-bit without a hitch ( at least the last time around)

On the first try, I executed the  conan install ..  --build missing --profile msvc2019Debug32,

but MSVC complained about not finding EXPAT.

So, I used vcpkg to install  .\vcpkg install EXPAT:x64-windows

After that MSVC was happy and allowed me to build the default 64-bit debug code. It built all executables as well as exiv2lib

After that, I started over again in new directory, and repeated the procedure, except, this time I skipped the conan step, because I wanted to try and see it id would make any difference.

This time, opening the root CMakelists.txt with MSVC 2019, started the IDE working on this file as soon as it was opened and I was able to build all files without any trouble at all.

Needless to say, I have not yet had much of a chance to explore or test the results or the wherefores and whys for ending up with the 64-bit debug default.

Particularly, because on the second try, I did not execute the conan profile script and thus whatever I got came strictly from the CMake files.

It also, IMO, makes a point about the differences between the errors I kept getting from the CMake command line and the fact that things compile cleanly on your system. IMO, it is likely related to missing libraries, be it related to 32 & 64 bit or ???? - ie the conan recipe might need looking at and that is above my pay grade, at least as long as I have an alternative ;-)

Arnold

[clanmills]

This is really good news.  And much more cheerful than the email I read at breakfast!

I helped somebody today with an XMP question and that took up half the day #1254 I started to look at VS/CMake and it couldn't find zlib and I thought "this is a microsoft mess".  I had a license for CLion and the integration with CMake was pain free. So I read your email again and decided to work on my book.  I also cut the grass today and did some chain-saw work the Alison wanted done.

It's 9:30pm and I've gone to bed early so I can up tomorrow and focus on the part of the book that deals with ISOBMFF.

Thanks for the email.  I like good news.

[clanmills]

You've motivated me to get back out bed and look at vcpkg. I've clone and build it effortless and:

C:\Users\rmills\gnu\github\vcpkg>vcpkg.exe search | grep -i exiv2
exiv2                0.27.3           Image metadata library and tools
exiv2[unicode]                        Compile with unicode support on windows

Somebody's fixed that for us. Incredible. Can you look at that and do your worst! I'm going back to sleep easily tonight. The day has ended very well.

[tester0077]

Hi Robin,

yes I had found it before I started working on the CMake stuff, but at the time it did not seem to help me at all.

It might be my problem or it might be an issue with the package.

Eventually I will/may sort  it all out.

For now, I will carry on and try and sort out the ins and outs of this new toy. Because even at this point, I am faced with way more questions about how to use it  than I have been able to find answers for. So far, my serendipitous guesses have paid of, but I'm afraid my beginner's luck may well run out, sooner, rather than later.

Just like everything else, this 'convenience' comes with a learning curve and I feel at the bottom of a very large hill.

It looks like I may not have to delve into conan, instead vcpkg & CMake support in the IDE is staring me in the face. It 'magically' integrates with the IDE, but at this time, the how and where is still very opaque.

Much reading, experimenting and thinking to be done, no doubt.

Hope you had a well deserved rest.

Will keep you posted

Arnold

On 2020-07-23 2:42 PM, Robin Mills wrote:

You've motivated me to get back out bed and look at vcpkg. I've clone and build it effortless and:

|C:\Users\rmills\gnu\github\vcpkg>vcpkg.exe search | grep -i exiv2 exiv2 0.27.3 Image metadata library and tools exiv2[unicode] Compile with unicode support on windows |

Somebody's fixed that for us. Incredible. Can you look at that and do your worst! I'm going back to sleep easily tonight. The day has ended very well.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Exiv2/exiv2/issues/1250#issuecomment-663246950, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFCLPHVXK7ZSW7WWO5VB63R5CVF3ANCNFSM4O7BUW6A.

[clanmills]

It built packages\exiv2_x64-windows\bin\exiv2.exe while I was asleep. It didn't copy the DLLs to the bin, so I did that in cmd.exe.

Very promising. For sure, I won't be rewriting README.md to say that this is our recommended way to build exiv2 with Visual Studio Windows (or MacOS or Linux). It is an impressive start. I sent a "Thank You" note to the people on https://github.com/Microsoft/vcpkg for their work.

It's odd that I don't see zlib1.dll (or any dll other than exiv2.dll) in the run-time list.

(I could have sent them an abusive complaint that they didn't copy the DLLs, didn't build or execute the test suite.)

C:\Users\rmills\gnu\github\vcpkg\packages\exiv2_x64-windows\bin>exiv2 -vV
exiv2 0.27.3
exiv2=0.27.3
platform=windows
compiler=MSVC
bits=64
dll=1
debug=0
cplusplus=201402
version=13.26 (2019/x64)
date=Jul 24 2020
time=01:19:55
processpath=C:\Users\rmills\gnu\github\vcpkg\packages\exiv2_x64-windows\bin
package_name=exiv2
curl=0
executable=C:\Users\rmills\gnu\github\vcpkg\packages\exiv2_x64-windows\bin\exiv2.exe
library=C:\WINDOWS\SYSTEM32\ntdll.dll
library=C:\WINDOWS\System32\KERNEL32.DLL
library=C:\WINDOWS\System32\KERNELBASE.dll
library=C:\WINDOWS\System32\ucrtbase.dll
library=C:\Users\rmills\gnu\github\vcpkg\packages\exiv2_x64-windows\bin\exiv2.dll
library=C:\WINDOWS\SYSTEM32\MSVCP140.dll
library=C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll
library=C:\WINDOWS\System32\PSAPI.DLL
library=C:\WINDOWS\SYSTEM32\VCRUNTIME140_1.dll
library=C:\WINDOWS\System32\WS2_32.dll
library=C:\WINDOWS\System32\RPCRT4.dll
library=C:\WINDOWS\System32\SHELL32.dll
library=C:\WINDOWS\System32\cfgmgr32.dll
library=C:\WINDOWS\System32\shcore.dll
library=C:\WINDOWS\System32\msvcrt.dll
library=C:\WINDOWS\System32\combase.dll
library=C:\WINDOWS\System32\bcryptPrimitives.dll
library=C:\WINDOWS\System32\windows.storage.dll
library=C:\WINDOWS\System32\msvcp_win.dll
library=C:\WINDOWS\System32\sechost.dll
library=C:\WINDOWS\System32\advapi32.dll
library=C:\WINDOWS\System32\profapi.dll
library=C:\WINDOWS\System32\powrprof.dll
library=C:\WINDOWS\System32\UMPDC.dll
have_strerror_r=0
have_inttypes=0
have_libintl=0
have_lensdata=1
have_iconv=1
have_memory=1
have_lstat=0
have_regex=0
have_regex_h=0
have_stdbool=1
have_stdint=1
have_stdlib=0
have_strlib=0
have_strerror_r=0
have_strings_h=0
have_mmap=0
have_munmap=0
have_sys_stat=1
have_unistd_h=0
have_sys_mman=0
have_libz=1
have_xmptoolkit=1
adobe_xmpsdk=0
have_bool=0
have_strings=0
have_sys_types=1
have_unistd=0
have_unicode_path=0
enable_video=0
enable_webready=0
enable_nls=0
use_curl=0
use_ssh=0
config_path=C:\Users\rmills\exiv2.ini
xmlns=DICOM:http://ns.adobe.com/DICOM/
xmlns=GPano:http://ns.google.com/photos/1.0/panorama/
xmlns=Iptc4xmpCore:http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/
xmlns=Iptc4xmpExt:http://iptc.org/std/Iptc4xmpExt/2008-02-29/
xmlns=MP:http://ns.microsoft.com/photo/1.2/
xmlns=MPRI:http://ns.microsoft.com/photo/1.2/t/RegionInfo#
xmlns=MPReg:http://ns.microsoft.com/photo/1.2/t/Region#
xmlns=MicrosoftPhoto:http://ns.microsoft.com/photo/1.0/
xmlns=acdsee:http://ns.acdsee.com/iptc/1.0/
xmlns=album:http://ns.adobe.com/album/1.0/
xmlns=asf:http://ns.adobe.com/asf/1.0/
xmlns=audio:http://www.audio/
xmlns=aux:http://ns.adobe.com/exif/1.0/aux/
xmlns=bmsp:http://ns.adobe.com/StockPhoto/1.0/
xmlns=creatorAtom:http://ns.adobe.com/creatorAtom/1.0/
xmlns=crs:http://ns.adobe.com/camera-raw-settings/1.0/
xmlns=crss:http://ns.adobe.com/camera-raw-saved-settings/1.0/
xmlns=dc:http://purl.org/dc/elements/1.1/
xmlns=dcterms:http://purl.org/dc/terms/
xmlns=digiKam:http://www.digikam.org/ns/1.0/
xmlns=dwc:http://rs.tdwg.org/dwc/index.htm
xmlns=exif:http://ns.adobe.com/exif/1.0/
xmlns=exifEX:http://cipa.jp/exif/1.0/
xmlns=expressionmedia:http://ns.microsoft.com/expressionmedia/1.0/
xmlns=iX:http://ns.adobe.com/iX/1.0/
xmlns=jp2k:http://ns.adobe.com/jp2k/1.0/
xmlns=jpeg:http://ns.adobe.com/jpeg/1.0/
xmlns=kipi:http://www.digikam.org/ns/kipi/1.0/
xmlns=lr:http://ns.adobe.com/lightroom/1.0/
xmlns=mediapro:http://ns.iview-multimedia.com/mediapro/1.0/
xmlns=mwg-kw:http://www.metadataworkinggroup.com/schemas/keywords/
xmlns=mwg-rs:http://www.metadataworkinggroup.com/schemas/regions/
xmlns=pdf:http://ns.adobe.com/pdf/1.3/
xmlns=pdfaExtension:http://www.aiim.org/pdfa/ns/extension/
xmlns=pdfaField:http://www.aiim.org/pdfa/ns/field#
xmlns=pdfaProperty:http://www.aiim.org/pdfa/ns/property#
xmlns=pdfaSchema:http://www.aiim.org/pdfa/ns/schema#
xmlns=pdfaType:http://www.aiim.org/pdfa/ns/type#
xmlns=pdfaid:http://www.aiim.org/pdfa/ns/id/
xmlns=pdfx:http://ns.adobe.com/pdfx/1.3/
xmlns=pdfxid:http://www.npes.org/pdfx/ns/id/
xmlns=photoshop:http://ns.adobe.com/photoshop/1.0/
xmlns=plus:http://ns.useplus.org/ldf/xmp/1.0/
xmlns=png:http://ns.adobe.com/png/1.0/
xmlns=rdf:http://www.w3.org/1999/02/22-rdf-syntax-ns#
xmlns=stArea:http://ns.adobe.com/xmp/sType/Area#
xmlns=stDim:http://ns.adobe.com/xap/1.0/sType/Dimensions#
xmlns=stEvt:http://ns.adobe.com/xap/1.0/sType/ResourceEvent#
xmlns=stFnt:http://ns.adobe.com/xap/1.0/sType/Font#
xmlns=stJob:http://ns.adobe.com/xap/1.0/sType/Job#
xmlns=stMfs:http://ns.adobe.com/xap/1.0/sType/ManifestItem#
xmlns=stRef:http://ns.adobe.com/xap/1.0/sType/ResourceRef#
xmlns=stVer:http://ns.adobe.com/xap/1.0/sType/Version#
xmlns=tiff:http://ns.adobe.com/tiff/1.0/
xmlns=video:http://www.video/
xmlns=wav:http://ns.adobe.com/xmp/wav/1.0/
xmlns=xml:http://www.w3.org/XML/1998/namespace
xmlns=xmp:http://ns.adobe.com/xap/1.0/
xmlns=xmpBJ:http://ns.adobe.com/xap/1.0/bj/
xmlns=xmpDM:http://ns.adobe.com/xmp/1.0/DynamicMedia/
xmlns=xmpG:http://ns.adobe.com/xap/1.0/g/
xmlns=xmpGImg:http://ns.adobe.com/xap/1.0/g/img/
xmlns=xmpMM:http://ns.adobe.com/xap/1.0/mm/
xmlns=xmpNote:http://ns.adobe.com/xmp/note/
xmlns=xmpRights:http://ns.adobe.com/xap/1.0/rights/
xmlns=xmpT:http://ns.adobe.com/xap/1.0/t/
xmlns=xmpTPg:http://ns.adobe.com/xap/1.0/t/pg/
xmlns=xmpidq:http://ns.adobe.com/xmp/Identifier/qual/1.0/

C:\Users\rmills\gnu\github\vcpkg\packages\exiv2_x64-windows\bin>

[tester0077]

Amazing.

Still for me, that version would still leave me to sort out the free() issue :-(

[clanmills]

Arnold. You've got to dig in (with Mr Grep) and find out what's causing the "free" problem. Nobody else is experiencing that.

[tester0077]

:-)

It is a matter of priorities.

I know where the problem lies. The big question is: which is the best, quickest and/or simplest way to 'fix' it?

Until it gets to be a big enough nuisance, it will simply sit near the bottom of the to-do pile/mountain

[clanmills]

I know Dan and Luis would like to kill (or refactor) class DataBuf in 0.28. So maybe this will disappear when/if 0.28 is released.

[tester0077]

So procrastination is in my favor? ;-)

[clanmills]

Who can say. I used to like procrastination, but now I’m not so sure.

Working hard on the book. Added code to decode IPTC today and information in the book about how it works. https://clanmills.com/exiv2/book/#IPTC

[tester0077]

Any ideas about the differences between the plain and unicode versions?

[tester0077]

On 2020-07-26 8:38 AM, Robin Mills wrote:

Who can say. I used to like procrastination, but now I’m not so sure.

Yes, I understand; it really isn't procrastination, but an issue of which 'problem' to address first ;-)

So many problems, so little time :-(

Working hard on the book. Added code to decode IPTC today and information in the book about how it works. https://clanmills.com/exiv2/book/#IPTC

I have been checking back every so often and am looking forward to see the final result.

Even as it is now, I have learned a fair bit every time I look at one or the other sections already finished.

[clanmills]

The UNICODE and "normal" package in vcpkg? That triggers EXIV2_ENABLE_WIN_UNICODE which compiles the path API to use windows wchar_t. I have a placeholder in the book to deal with that. In 13.10 Platform Support there are a couple of sub-sections:

#### UNICODE path support

To be written.

#### Character Set Encoding

To be written.

In IPTC there is a Tag: Iptc.Envelope.CharacterSet which I have to investigate. Again, I've left a placeholder in the book:

### IPTC Character Set Encoding

To be written.

On the subject of UNICODE, what brought me back out of retirement to work on Exiv2 v0.27.3 was an interesting conversation with Phil Harvey (of ExifTool) concerning GPSAreaInformation (and GPSProcessingMethod). He explained that they should be encoded like a UserComment which can be UNICODE or Jis encoded. I documented this in the Exiv2 man page for v0.27.3. I suspect our UNICODE support in UserComment was broken and is now fixed.

I don't understand those encoding matters. For sure, I'd like somebody to test it. I may have recruited a Chinese Engineer. This morning he sent me some python scripts to review. I'm hoping his code is good as we have about 25 scripts to port from bash. If he gets that done, I'll ask him if he would like to test our character-set code.

I should investigate the vcpkg + libiconv support. The change I submitted in cmake/FindIconv.cmake will prevent them from building that. It will build successfully and simply ignore their request for Incov support. If they really have Iconv working well, I remove my "fix" that says "I never build Iconv support from Visual Studio".

I should investigate building Exiv2 on macOS and Linux (and cygwin64 and MinGW/msys2) with vcpkg. And maybe Solaris, FreeBSD and NetBSD.

It's a full-time job to manage an open-source project with 100,000 lines of C++.

[clanmills]

I've added an issue #1255 "Investigate vcpkg support for Exiv2".

[clanmills]

Great News. The code from the Chinese guy is beautiful. Very pleased. He'll convert the 25 bash scripts to python in a few days. Delighted.

Then I'll ask him to work on the UNICODE character-set magic.

[tester0077]

On 2020-07-26 9:31 AM, Robin Mills wrote:

The UNICODE and "normal" package in vcpkg? That triggers |EXIV2_ENABLE_WIN_UNICODE| which compiles the path API to use windows |wchar_t|. I have a placeholder in the book to deal with that. In 13.10 Platform Support there are a couple of sub-sections:

|#### UNICODE path support To be written. #### Character Set Encoding To be written. |

In IPTC there is a Tag: Iptc.Envelope.CharacterSet which I have to investigate. Again, I've left a placeholder in the book:

|### IPTC Character Set Encoding To be written.|

|Yes, I had wondered/worried about that some.|

Right now, I don't recall the exact context, but I am sure I will run into it again.

||

On the subject of UNICODE, what brought me back out of retirement to work on Exiv2 v0.27.3 was an interesting conversation with Phil Harvey (of /ExifTool/) concerning GPSAreaInformation (and GPSProcessingMethod). He explained that they should be encoded like a UserComment which can be UNICODE or Jis encoded. I documented this in the Exiv2 man page for v0.27.3. I suspect our UNICODE support in UserComment was broken and is now fixed.

I don't understand those encoding matters. For sure, I'd like somebody to test it. I may have recruited a Chinese Engineer. This morning he sent me some python scripts to review. I'm hoping his code is good as we have about 25 scripts to port from bash. If he gets that done, I'll ask him if he would like to test our character-set code.

IIRC, the character set issue arose for me because some of the images I have include German Umlauts etc. but that was some time ago.

Checking back a bit .....

Would that have anything to do with the Esc%G string for IptcEnvelope.CharacterSet?

In one of my apps, I think I got that sort of sorted out, at least for my Umlauts etc

I should investigate the vcpkg + libiconv support. The change I submitted in cmake/FindIconv.cmake will prevent them from building that. It will build successfully and simply ignore their request for Incov support. If they really have Iconv working well, I remove my "fix" that says "I never build Iconv support from Visual Studio".

Libiconv was built for me as one of the dependencies when I installed exiv2 on my spare; also built were: expat, gettext & zlib

I should investigate building Exiv2 on macOS and Linux (and cygwin64 and MinGW/msys2) with vcpkg. And maybe Solaris, FreeBSD and NetBSD.

It's a full-time job to manage an open-source project with 100,000 lines of C++.

I can well imagine.

[clanmills]

The %Gbinary has to be investigated because the only thing I know about it is that it exists!

I'm in a 1000% happy mood. We usually have steak on Friday. However we had a BBQ at our son's home on Friday. Cow for dinner this evening (and red-wine). So happy with the Chinese Engineer. Life is good.

[tester0077]

On 2020-07-26 10:45 AM, Robin Mills wrote:

The |%Gbinary| has to be investigated because the only thing I know about it is that it exists!

this is the code I have used

Exiv2::IptcData &iptcdata = image->iptcData();

......

    // IPTC data needs its own Exiv2::IptcData &iptcdata     bool bUnknown = false;     s = iptcdata.detectCharset();     if( !s.empty() )     {       if( s.IsSameAs( _T("\x1b%G") ) || s.IsSameAs( T("UTF-8") ) )       {         s = ("UTF-8");       }       else if( s.IsSameAs( T("ASCII") ) )       {         s = ("ASCII");       }       else if( s.IsSameAs( T("\x1b.A") ) ) //ESC . A       {         s = ("ISO 8859-1");       }       else       {         s = _("unknown IPTC Char set");         bUnknown = true;       }

I'm in a 1000% happy mood. We usually have steak on Friday. However we had a BBQ at our son's home on Friday. Cow for dinner this evening (and red-wine). So happy with the Chinese Engineer. Life is good.

Good to hear :-)

[clanmills]

Thanks for your code. I will investigate the specification of this.

The %Gbinary output has caused trouble in the past by creating binary files which upset diff in the test suite. In years gone by, I've turned a blind eye to that. It needs (and will get) investigation. And, with the Chinese Engineer working on the test suite, we're finally moving away from using diff and other platform utilities in the test suite.

Steak dinner (and wine) was fantastic. No more work tonight!