how does one find linker errors?

[jimg]

I have a rather large program that I have been happily using jwasm on without problem.  Then, I had some weirdness happen I couldn't explain, so I thought I'd drop back to masm.   After spending an hour putting in superfluous syntax that masm needs and jwasm doesn't I finally got it to assemble, but now I am getting linker error "LNK1190: invalid fixup found, type 0x0001"

How does one find what is causing this type of error?

[jj2007]

Jim,

Linker option /verbose could help to chase it down.

[jimg]

A good thought, but it made no difference.  Link didn't get far enough to put out any messages at all other than the one above.

here is the total output-

Code Select Expand


F:\WinAsm\Progs\Sol>F:\masm32\BIN\Link /SUBSYSTEM:WINDOWS /RELEASE /VERBOSE /MAP
/MAPINFO:FIXUPS "/LIBPATH:F:\masm32\LIB" "Sol.obj" "Sol.res" "/OUT:Sol.exe"
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.


Start Pass1
Sol.obj : fatal error LNK1190: invalid fixup found, type 0x0001

F:\WinAsm\Progs\Sol>pause
Press any key to continue . . .

[dedndave]

do you have any 16-bit references in a 32-bit section ?
32-bit references in a 16-bit segment ?
and so on

another possibility is an incompatible OBJ file - try a different linker version maybe ?
or see if the assembler and linker are from the same era, at least   :P

[jimg]

I certainly didn't intend to do any 16bit references, but masm could have mistook something for one.   Even if another linker worked, it wouldn't find the problem.  I'm sure it's something I took advantage of that jwasm can do much better than masm, and now I'm paying the price.  I'll start putting overides on everything until I find it.  And I'm not at all sure that it will solve my original problem,  I thought switching to masm would be a quickie test.  Guess not.

[jj2007]

or see if the assembler and linker are from the same era, at least   :P

That's probably the issue here - incompatibility between ML and LINK.

Try link /incremental:no ...

As to JWasm: I love it, it's good and much faster than Masm, but when I build my libraries, I do it first with JWasm to see if it works, then with ML 6.15 for the release version.

[wjr]

If you use PEview to look into the OBJ file, and Type 0x0001 is referring to IMAGE_REL_I386_DIR16 (usually should be 0x0006 IMAGE_REL_I386_DIR32), then you should be able to see at least one of these in the IMAGE_RELOCATION records. The symbol name and RVA are also displayed which should help narrow things down.

[sinsi]

Does link v5.12 use COFF? I thought it was the 16-bit linker.

[jimg]

Finally found it.

I use the $ notation a lot to get addresses, e.g.

Code Select Expand

.data
xtest = $
    db "This is a test",0


and then just use xtest wherever I need an actual address, rather than typing "dword ptr" or "offset" all over the place.  Jwasm always knows this is a four byte address.   Masm, not so much,  some of the time it screws up, and the above error is the result.

[jj2007]

Little surprises ;-)
Especially ML 6.15 is a pig. But try this, works with 6.14 ... 10 and JWasm:

include \masm32\include\masm32rt.inc

.data
  curadd=$
  db "This is a test",0

.code
  xtest CATSTR <dword ptr offset >, <curadd>
  % echo xtest

start:   print xtest
   exit

end start

[jimg]

It also worked for 90% of the instances in masm, it was just a few where it got confused.  Everything good now.  Just had to test for opattr 25h in some macros and handle appropriately :)

[dedndave]

i believe the $ bug is documented
i try to avoid $   :P