compile error

[shankle]

                             8-10-2014
                     
Code involving "ejdu" which is my txt module has been working
for years in a masm32 whspellm program.
I am trying to convert this program to a 64-bit GoAsm program.
I was able to compile the whspellm64 program in GoAsm. Then it stopped
working and started complaining about "edju" not defined.
FileDat              db   'ejdu.dat',0  ;as defined in the whspellm64 program

((Batch file "whbatch"))      
Set INCLUDE= J:\codejps         
Set PATH=J:\codejps
GoAsm /x64/b/c whspellm64.asm
GoLink /unused whspellm64.obj
      or
GoLink /unused whspellm64.obj ejdu.dat
Neither of these now work.....

Microsoft Windows [Version 6.1.7601]
c: users\jack>j:
j:cd \codejps
j:\codejps>whbatch
j:\codejps>Set INCLUDE= j:\codejps
j:\codejps>Set PATH=j:\codejps
j:\codejps>GoAsm /x64/b/c whspellm64.asm
GoAsm.exe Version 0.58.0.6
Output file: whspellm64.obj
j:\codejps>GoLink /unused whspellm64.obj ejdu.dat
   (this doesn't work either)
j:\codejps>GoLink /unused whspellm64.obj
GoLink.exe Version 1.0.0.0

ERROR!!!!
The following symbol was not defined in the object
file or files:- ejdu
Output file not made
j:\codejps>

Been having some problems with "NotePad++". Was using V6.6.6 and
didn't like the way it worked.
Took it off the puter and now am trying to use V6.6.4
Don't know if this could be some of the problem.
I'm a novice with NotePad++

[wjr]

I would suggest searching for "ejdu" within your whspellm64.asm source to see if you used that elsewhere as a symbol when you should have used FileDat instead. The GoLink command with ejdu.dat looked a bit strange, so if that was supposed to be ejdu.obj, then the batch file will need another line with GoAsm to assemble ejdu.asm.

[shankle]

Thank you for responding WJR.

The "ejdu.dat" file is a data file.
It is not part of the "whspellm64.asm" program.

I'm guessing but this might be the problem.
There are 3 frames in the whspellm64 program.

Filedat  db 'ejdu.dat',0        is defined   before WinMain
    WinMain:  (FRAME 1)
    WndProc: (FRAME 2)
    invoke BuildFile, [hWnd]   ; build file
    BuildFile: (FRAME 3)
This is how I reference the "ejdu.dat" file in the whspellm64 program
in BuildFile. (FRAME 3)
    hfile dq 0
    invoke GetFullPathName,addr FileDat,100,addr buf3,addr buf4
    invoke CreateFile,addr buf3,GENERIC_READ,0,NULL,\
               OPEN_EXISTING,NULL,NULL
    mov Q[hFile],rax
    invoke SetFilePointer, [hFile],NULL,NULL,FILE_BEGIN
.Read1                     ; find 1st rcd
    invoke ReadFile, [hFile],addr LineWork,88,addr BytesRead,NULL
Was only guessing in reference to the GoLink statement.

The term "ejdu.dat" is referenced in the BuildFile frame (FRAME 3).
    lea eax,ejdu+4         
I assumed a defined ejdu above Winmain would suffice to
define it in BuildFile. Obviously I am wrong.
How do I fix it????   

[wjr]

You have not defined a symbol ejdu which ejdu+4 expects, hence the GoLink error. You have defined a symbol FileDat which points to a string "ejdu.dat" used to open and read that file into memory at the address of the symbol LineWork. Assuming you are looking for the address 4 bytes into this "ejdu.dat" file just loaded into memory, the 64-bit fix would seem to be:

lea rax,LineWork+4

[shankle]

                            8-10-2014

Your suggestion helped me get rid of the "EJDU" link error.
I am going in the hospital tomorrow morning and if I get out of
there, it will be at least a week before I can get back to solving this.               
I would like to continue this thread then if I may.

here is what I did:
BuildFile:
    FRAME hWnd
   LOCAL ejdu
   lea eax,ejdu+4         ; letter 1 in finder record
    mov dl,B[eax]
Linework has nothing in it when I execute lea eax,ejdu+4.
The read of the file occurs later. So using linework has not been
filled as yet. Of course the above compiled correctly but the
program no longer works.

[dedndave]

hope all goes well at the hospital, Jack   :t

[shankle]

Thanks Dave,
This is about my 11th time on the cutting board.
I am definitely not looking forward to it. :icon13:

[dedndave]

it's always scary, going in
when you come out - nice to have it over with   

[shankle]

This thread is now closed (8-21-2014).
In fairness to others that might be using NotePad++, it was the culprit
that caused my problem.
In Notepad++ if you move the pointer to a different place and start to
make changes it will alter the instruction that you just left. If you are
like me you can't remember the instruction that you left. Causing an error
that is very difficult to find.