I use the visual studio 2010 c + + program of the console, calling a third-party dynamic link library GMSH, provided the h issuer, lib and DLL files, only one version, does not distinguish between the debug/release (later checked with depend software DLL, should be release version),

With the method of static imports, a call the library in the debug mode operation is normal, but compiled into the release after the operation error, DLL under the corresponding exe path,
Error: unable to locate ordinal number 1271 in the dynamic link library... Xx. Exe

Use depend to check the release version exe files as follows, did find call within the Ordinal Numbers and DLL function can't corresponding

In addition, in MFC100. DLL here also appeared the ordinal number 1272



Reoccupy depend to see the debug version exe files as follows, doesn't seem to have the above problems


Can you tell me the problem how to solve? thank you

CodePudding user response:

Add:
Call about the library, at the beginning of a compilation is pass, according to a large number of LNK2005 redefine error, searched, found that the reason is quite likely the main program of the CRT versions do not match the version of the CRT and third-party library cause, the solution is to add linker on the command line "/FORCE: MULTIPLE" instruction, so a lot of error to the warning, compile, debug version of the program can be run correctly, but the current release version appeared the problem described above,

Don't know whether the two problems are linked

CodePudding user response:

Is the best way to ensure exe and DLL runtime libraries are consistent, the debug and release are corresponding well

CodePudding user response:

refer to the second floor oyljerry response:

is the best way to ensure exe and DLL runtime libraries are consistent, debug, and release corresponding good

Third-party libraries did not provide the debug and release versions, there is only one version, depend view from 3rd party DLL call MSVCRT DLL, found no "D" in the filename suffix, speculation is the release version,

CodePudding user response:

Preliminary solved the problem, but the mechanism is unknown, also please understand that the bosses give directions

I search a on call ffmpeg similar problems in the library of
https://blog.csdn.net/machh/article/details/51443361
The solution is:
Vs2010
Release in the project properties -- -- -- -- -- "connectors," optimal option of choice:
keep not reference dataWould -- -- -- -- -- optimization - the reference - No (/OPT: NOREF)

This modified release compiled through, appeared the following type error
LNK1179: invalid or damaged file: repeat COMDAT?" @ XXX XXXX "
Further search in post
https://www.cnblogs.com/QQ278737076/p/5458592.html
The solution is:
Solution: project right click [properties] - [C/C + +] - [optimization] - [the whole program optimization into] "or"

Release compile, run normally, but I don't understand what is the problem of mechanism, and so I modified after the solution, what disadvantages?

CodePudding user response:

Should be a DLL rely on library version and development environment of inconsistencies, VS2010 patches installed?

CodePudding user response:

Do not line up this is typical of the library, the library's name, but the library and the content of the library version do not line up with the header file, or the library itself there is an error, will cause such a thing,

CodePudding user response:

reference 5 floor zgl7903 reply:

should be a DLL rely on library version is inconsistent, and the development environment VS2010 patches installed?

No, what need to install the patch?

CodePudding user response:

Quote is obviously can't find the function in the exe, what do you go to see the DLL export tables?

Have the error description function's statement is wrong, should use __declspec (dllimport) place with the __declspec (export) (this also causes LNK2005 error), as for the wrong which function the add you take away any of those crusty compile parameters, compile it again and then go to the compiler to what's wrong, generally DLL header file has # ifdef, include the header file in exe should let ifdef interpreted as __declspec (dllimport) (how did better file how # ifdef), in the DLL to compile their own time to use __declspec (export),

The compiler found a bug, add/Force to the compiler sound into a runtime bugs...