rdpratti

I am relatively new to VS 2005, but not to C++. I'm recompiling code that was used as a Stored Procedure in another DBMS.

I am using the following options:

cl -Zi -Od -c -W2 -DWIN32 -MD %1.cxx

link -debug -out:%1.dll -dll %1.obj dbms_vendor_api.lib -def:%1.def

I am finding that the dbms is having trouble identifying the dll, whereas prior to this it was fine.

I have two questions:

1. Is it correct to say that given the options specified, VS C++ will produce fully compiled code versus IL code

2. Does my compile and link options require changes based on VS 2005 changes

I have been pouring through a number of things from google searches and haven't been able to track this down. However, I am leaning in the direction of item 1 above, or the possibility that an additional library needs to be added to the link that is new to 2005.

Thanks in advance for any feedback you can provide,

- rd



Re: Visual C++ General VS C++ Compile/Link Consequences

Ramkrishna Pawar

Have you checked the DLL dependancies It might have got linked to CRT DLLs which are present on target comp.

Dependency Walker (depends.exe) Home Page




Re: Visual C++ General VS C++ Compile/Link Consequences

rdpratti

Thank You! This helped solve my problem.

It turns out it was a combination of problems:

1. D. Walker showed me that the C-runtime had been changed with VS 2005 to msvcr80.dll and my machine didnot have that in the system32 folder. This new dll was being referenced by default as part of my /MD option in my compile.

2. When I moved this dll to my system32 directory, I found out that my DBMS was not compatible with this new dll.

3. By changing the compile to use static references, option /MT, it turns out that the original C-runtime library, LIBCMT and associated dlls are linked in, resulting in a good compile, link, and execution.

So thanks again. It stopped my wheel spinning and pointed me in the right direction.

- rd