Windows MSVC 2019 EXV_ICONV_CONST undefined #1250
Comments
|
I documented my profile and build procedure in #1251. When I ran the command: CMake generate the sln and several vcprojx files. He also generates this file: 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 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.
|
|
Hi Robbin, though it may well be related to my trying for a 32-bit compile. |
|
Only one b in Robin (some would say there are lots of bees in Robin) I would like to see:
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 |
|
My sincere apologies for misspelling your name, Robin. 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 |
|
Solved. CMake is picking up something suspicious. The quick fix is to modify the file cmake/FindIconv.cmake to never attempt to find Iconv when building with Visual Studio: 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. |
|
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. |
|
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: 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 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 |
|
following your instructions, I cloned a new repository , as follows: 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. if I replace the line in convert.cpp # 1542 exiv2lib builds without complaint, but I get a whole lot of warning and some other errors, which did not show up before: HTH :( |
|
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. |
|
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 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 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. |
|
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. |
|
just a brief update. |
|
I suspect if you use my script cmd64.bat to set up your path, CMake will not find the library in I've updated cmake/FindIconv.cmake on 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 |
|
Hi Robin, 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. |
|
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. There are 4 versions of the CRT link libraries present in vc\lib: 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). |
|
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. |
|
OK. You're getting a couple of warnings: 1 When you link the library:
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. |
|
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. And you're building release: |
|
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
<#1250 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACFCLPG22CUVFWWTKWJUWTLR4VD4JANCNFSM4O7BUW6A>.
|
|
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. |
|
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
|
|
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
|
|
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
|
|
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. |
|
You've motivated me to get back out bed and look at vcpkg. I've clone and build it effortless and: 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. |
|
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
<#1250 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACFCLPHVXK7ZSW7WWO5VB63R5CVF3ANCNFSM4O7BUW6A>.
|
|
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.) |
|
Amazing.
Still for me, that version would still leave me to sort out the free()
issue :-(
|
|
Arnold. You've got to dig in (with Mr Grep) and find out what's causing the "free" problem. Nobody else is experiencing that. |
|
:-)
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
|
|
I know Dan and Luis would like to kill (or refactor) |
|
So procrastination is in my favor? ;-)
|
|
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 |
|
Any ideas about the differences between the plain and unicode versions?
|
|
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.
|
|
The UNICODE and "normal" package in vcpkg? That triggers In IPTC there is a Tag: Iptc.Envelope.CharacterSet which I have to investigate. Again, I've left a placeholder in the book: 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++. |
|
I've added an issue #1255 "Investigate vcpkg support for Exiv2". |
|
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. |
|
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.
|
|
The 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. |
|
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 :-)
|
|
Thanks for your code. I will investigate the specification of this. The Steak dinner (and wine) was fantastic. No more work tonight! |
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):
The text was updated successfully, but these errors were encountered: