I really hate MS Visual C++ 2010. I have had so many problems since I installed it a couple of weeks ago that it is driving me crazy.
I have an MQ API Exit built for Windows 64-bit (via a script) with /Release /x64.
setlocal CALL "D:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /Release /x64 nmake -f makefile.vc64.nt %1 endlocal
And in the makefile I use the parameter /LD for the cl command to build the DLL:
$(cc) $(cflags) $(cvarsdll) /LD $(scall) -Fo$@ $(MYSRC)$(@B).c
This has worked fine for many years and different Microsoft compilers but not with Visual C++ 2010.
A customer was running a 64-bit application on their server but MQ would not load the 64-bit version of the mqa.dll. Here is what was in the MQ trace file:
FullPathLibName(C:\Program Files (x86)\IBM\WebSphere MQ\exits64\mqa.dll) RC(24948) WindowsErrorNumber(126) WindowsErrorString(The specified module could not be found.)
The customer verified many times that the 64-bit version of mqa.dll was indeed in the correct location. Hence, a PMR was opened with IBM.
IBM had the customer run the Process Monitor program against it and output the data to a file. In the file, there were many occurrences of “MSVCR100D.dll NAME NOT FOUND”. MSVCR100D.dll is the debug version of MSVCR100.dll (note the extra “D” in the file name of the debug version).
I reviewed my makefile to make sure that I was not using either “_DEBUG” or “/LDd” (or /Debug /x64 for the environment) that would cause the “cl” command to build the DLL for a debug environment but everything was correct.
I even checked Microsoft’s MSDN regarding /LD parameter:
http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.100).aspx
I rebuild the DLL several times and when I checked the DLL, it pointed to MSVCR100D.dll and not MSVCR100.dll.
After a bunch of Google searches and finding other people with the same problem using Visual C++ or Visual Studio 2010, I changed /LD to /MD and rebuild the DLL. When I checked the DLL, it now points to msvcr100.dll – which is correct.
I do not understand it. Microsoft’s documentation says that parameter /LD creates a dll and parameter /LDd creates a dll for debugging. There must be some sort of bug in MS Visual C++. 🙁 All I can do is shake my head in frustration.
I REALLY wish IBM would officially support GCC on Windows, so that I could get away from Microsoft’s Visual C++ 2010. I don’t have these stupid headaches on Linux!! I do have GCC 32-bit and 64-bit for Windows on my PC and do successfully build MQ applications and DLLs with it – I just don’t give them to customers (I don’t want GCC to get blamed when an issue shows up).
Regards,
Roger Lacroix
Capitalware Inc.
