Hi,
I have a C library that I use with assembler. It builds fine, and works fine when included in assembler code, but when I use linker option /debug, it chokes:
LINK 6.14: fatal error LNK1000: unknown error; consult documentation for technical support options
POLINK: fatal error: Unknown kind (0x0) of CodeView symbol in object 'tinf.lib(tmp.obj)'
No such error with /debugtype:coff, but Olly can't handle that option.
Any ideas? Using a more recent link.exe version is not a good option, because I'd like to maintain compatibility with Masm32.
P.S.: It works better with Pelles C, but the resulting code is much slower :(
Hi jj2007,
WinDbg is an excellent FREE debugger :t
Give it a try :biggrin:
Quote from: habran on October 23, 2014, 01:27:23 PM
WinDbg is an excellent FREE debugger :t
Debugging Tools for Windows (http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063%28v=vs.85%29.aspx)
Quoteget the Windows 7 Debugging Tools for Windows package, which is included in the Microsoft Windows Software Development Kit (SDK) ... You might have to uninstall Microsoft Visual C++ 2010 Redistributable components before you install the SDK
Ah... Microsoft :eusa_boohoo:
P.S.: Just tried C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\Mdbg.exe - true hitech :t
8)
If you have Windows 7 you should use Microsoft Visual Studio Express 13 for Desktop
it is FREE for commercial use, it is actually new VC10 :t
I use it as a studio and work with JWasm and C together in the same project
In that case you can run and debug using built in debugger
Quote from: habran on October 23, 2014, 02:16:56 PMIf you have Windows 7 you should use Microsoft Visual Studio Express
I do have XP, too, and I like Olly. So, any ideas how to convince ML 10.0 to output symbols that can be handled by the old Masm32 linker?
Quote
C library that I use with assembler. It builds fine, and works fine when included in assembler code, but when I use linker option /debug, it chokes:
Old binaries of the masm32 package aren't compatible with VS2010 in debug mode.
use only the VS2010 linker and rebuild all your sources code
Quote from: ToutEnMasm on October 24, 2014, 02:05:26 AM
Old binaries of the masm32 package aren't compatible with VS2010 in debug mode.
use only the VS2010 linker and rebuild all your sources code
So, will the rebuilt libraries be compatible with the old Masm32 linker that almost everybody uses here?
The linker of the masm32 package must be replace by the Vc 2010.
You must add it his dll ms*.* and more
The masm32 library must be rebuild.
The crt_library must be rebuild.
After that,no more problem.
Quote from: ToutEnMasm on October 24, 2014, 04:53:31 AM
The linker of the masm32 package must be replace by the Vc 2010.
You must add it his dll ms*.* and more
The masm32 library must be rebuild.
The crt_library must be rebuild.
After that,no more problem.
That's a lot of expenditure. Is it worth the effort? Would the gcc be an alternative?
Gunther
Quote from: ToutEnMasm on October 24, 2014, 04:53:31 AM
The linker of the masm32 package must be replace by the Vc 2010.
You must add it his dll ms*.* and more
The masm32 library must be rebuild.
The crt_library must be rebuild.
After that,no more problem.
Yves, "no more problem"??? You are ignoring my question:
Quote from: jj2007 on October 24, 2014, 04:34:10 AMSo, will the rebuilt libraries be compatible with the old Masm32 linker that almost everybody uses here?
So I'll answer it myself: NO, the rebuilt libraries will NOT be usable by anybody who has NOT replaced his whole installation with the latest M$ crap. But then, you'll probably suggest that everybody must install the "ready-to-use SDK", right? ;)
In the meantime, I've solved the problem. PM me if you are interested.
You are right,using the "ready-to-use SDK",you get the perfect soluce to mix masm and c code(object files).
You have no need of the masm crt_library with the translated headers .
There is about three functions in the crt whose names aren't compatible with masm.The soluce for them is to made a dynamic link,if you need them.