Bug #905
Exiv2 does not run on Windows Vista
100%
Description
Hi,
we got reports that our application did not work on Windows Vista, getting an error message like
The procedure entry point K32EnumProcessModules could not be located in the dynamic link library KERNEL32.dll
and we tracked down the problem to the exiv2 library. The problem just turns up, if the compilation is done with newer versions of the Windows SDK. We actually did the compilation on Win8 with VS2012. Documentations on the problem:
- Visual C++ Team Blog
- EnumProcessModules function (look at the Requirements/library section)
- Define PSAPI_VERSION=1 during compilation of exiv2 (maybe optional)
- Define _WIN32_WINNT=0x501 (not that recommended)
- Remove the usage of EnumProcessModules from the version.cpp file
I suggest the first solution by adding the definition to CMake.
Best,
Daniel
Files
History
Updated by Robin Mills over 8 years ago
- Category set to build
- Status changed from New to Assigned
- Assignee set to Robin Mills
- Estimated time set to 4.00 h
Daniel
Thanks for reporting this. An interesting issue. This is a run-time error, so compiler switches are of limited value. Sure, if you build and run on the same machine, this will work fine. However if the build has been performed on W7, Vista will be unable to find the desired entry point and exiv2.exe will refuse to load and execute.
I've thought of three ways to solve this:
1) delay-load PSAPI and avoid EnumProcessModules when the host-os is Vista
2) remove references to PSAPI in version.cpp and the build environments
3) get version.cpp to call LoadLibrary/GetProcAddress explicitly (and forgive failure)
The reason version.cpp uses PSAPI was introduced by the command exiv2 --verbose --version. This is used by test/build-test.py to determine libraries loaded at run time. Other build information is also reported.
I think the best/simplest solution is 3) LoadLibrary/GetProcAddress. The consequence is that Vista will not enumerate loaded libraries. I'll also modify/build-test.py to say "Vista doesn't know what's in his brain!". I'm on sabbatical until mid-July, so I'm unable to test and submit this fix at present.
As you are building with Visual Studio, you could do the following in version.cpp
1) Comment off the linking psapi (around line 110)
// tell MSVC to link psapi.
#ifdef _MSC_VER
//#pragma comment( lib, "psapi" )
#endif
2) Dummy out dumpLibraryInfo (around line 140):
EXIV2API void dumpLibraryInfo(std::ostream& os)
{
return;
}
This change will have no affect on the run-time performance/functionality of exiv2 executables and libraries (other than to throttle the output from exiv2 -v -V).
Robin
Updated by Daniel Kaneider over 8 years ago
Well, the runtime error is caused by compiling with specific flags. If you look at the psapi.h header file you can see that Microsoft allows to downlevel the psapi version. It should suffice by adding
ADD_DEFINITIONS(-DPSAPI_VERSION=1)
to the exiv2 main CMakeList file at around line 75. This means that the library compiled on Win8 should definitely work on WinVista. I did so, and could see using Depends that the K32 symbol didn't get used anymore. Instead, the same symbols from the psapi.dll were used.
Best,
Daniel
Updated by Robin Mills over 8 years ago
- Thanks, Daniel. I'm very pleased that you've got this working. You said in the report:
'I suggest the first solution by adding the definition to CMake.'
Did you put something into one of the CMake*.txt files, or an argument on the Cmake command?
Updated by Robin Mills over 8 years ago
Thank you, Daniel.
I'm unable to submit the patch at the moment. I don't know if this is because there's something wrong with the SVN server on dev.exiv2.org, or the internet connection from my vacation hotel in Utah. I'll try to submit this at my next stop in Colorado.
This fix is fine for the CMake build and I'll update the msvc/msvc64 build environments once I am home in July.
Updated by Robin Mills over 8 years ago
- Target version changed from 0.24 to 0.25
The MSVC build implications of this issue are being deferred for 0.25.
Updated by Robin Mills about 7 years ago
- Status changed from Assigned to Resolved
I'm going to mark this as "Resolved". I think Daniel's patch is perfect for CMake builds and I thought I would have to make similar/parallel changes for msvc/msvc2005/msvc2012 build environments. I've been using Vista/64 on a VM on my Mac Book Pro for 1 year and it builds and runs the test suite without trouble using the CMake and/or Visual Studio environments. So, unless Daniel knows otherwise, I think this is resolved.