could not make the output file

[shankle]

Thanks for any help.
I have other 64-bit programs that work just fine.
They were compiled with Windows 7 Pro 64-bit.
This one is giving the following error at compile time on Windows
8 Pro 64 bit.

   blahblah.obj - unused/unreferenced label(s) found as follows:-
      testmsg
      LPSTR
  Error!
  the system could not make the output file (blahblah.exe)
  output file not made.

I know what testmsg is and that is not the problem.

CommandLine LPSTR  ?   - is defined at the end of the DBs and
before  .code.  As I think this is correct, I am at a loss as to the problem.....

[dedndave]

can't see the source, but.....

usually, the first error reported is the first one to fix   :P
but - if you say testmsg is good, we have to take your word for it

LPSTR should be defined as a 64-bit pointer (QWORD size) - actually a longlong, i guess
windows.inc should take care of that

maybe the problem is with the label name "CommandLine" (maybe it's used elsewhere)
try changing it to "lpComandLine", "pszCommandLine", or something similar

seems to me that LPSTR should be long
and, if you want a machine-size pointer, use PSTR   :P

[shankle]

Tried compiling a program that worked on Windows 7 in Windows 8.
It compiled fine and tested correctly. So my problem has nothing
to do with Windows 8. Command LPSTR  ? is coded the same way in both programs.
Nothing is ever easy.....

[Donkey]

LPSTR is not defined in windef.h, you can use PTR instead. This is mainly due to the fact that I used it in a few programs and it would break my code to define it as a data type. Thinking on it I will include it as a data type in the next release of the headers. For the time being you can include the following in your header, it will assure that when I add it, it will not break your program:

Code: [Select]

#IFNDEF LPSTR
    #IF !X64
        #DEFINE LPSTR DD
    #ELSE
        #DEFINE LPSTR DQ
    #ENDIF
#ENDIF
The fact that LPSTR does not generate an error in 32 bit mode is a bug in GoAsm, it actually creates a 0 sized variable. I think this bug is documented already.

[shankle]

Thank you very much for responding Edgar.
The following code  gives an error.
My knowledge of #define is skimpy.
The compile says that "DS" is not defined.

Data Section
#ifndef LPSTR
  #if !x64
    #define CommandLine LPSTR dd
  #else
    #define CommandLine LPSTR dq
  #endif     
;CommandLine LPSTR  ?     

I have 5 other 64-bit programs that compile clean and seem to work.
This doesn't make any sense.

[dedndave]

take the word "CommandLine" out of those and add the last #endif

Code: [Select]

#ifndef LPSTR
  #if !x64
    #define LPSTR dd
  #else
    #define LPSTR dq
  #endif
#endif
then add this line back in

Code: [Select]

CommandLine LPSTR  ?

[Donkey]

Hi Shankle,

Dave's got it right. The snippet I posted simply defines LPSTR as a data type that can be used in the data section.

[shankle]

Thanks Guys,
The LPSTR problem is solved.

I have 6 or 7 GoAsm 64-bit programs so far and they all compiled and executed
fine without Edgar's code.
So I am puzzled as to how they could work when they didn't have Edgar's code
in them. Guess accept that Edgar's code solved the problem and add it to all
64-bit programs.

[Donkey]

Thanks Guys,
The LPSTR problem is solved.

I have 6 or 7 GoAsm 64-bit programs so far and they all compiled and executed
fine without Edgar's code.
So I am puzzled as to how they could work when they didn't have Edgar's code
in them. Guess accept that Edgar's code solved the problem and add it to all
64-bit programs.

Testing shows that the problem exists in 64 bit code as well, when your 64 bit programs compiled and executed it was actually introducing a rather nasty bug in your software, for example take the following:

Code: [Select]

DATA SECTION
    hInstance DD ?
    MyVar LPSTR 0
    MyOtherVar PTR 0

CODE SECTION
    mov D[MyOtherVar],999
    mov D[MyVar],888
In this case MyOtherVar which was 999 will be overwritten by 888 since both MyOtherVar and MyVar represent the same offset into the DATA section. It would be exceedingly difficult to track down this error in your code as everything seems to assemble properly but writing to MyVar will trash the next entry in the DATA section. The problem becomes even more sinister if there are BSS section labels between them or it is the last entry in a DATA section and there are other DATA sections that will be merged. In that case the data that is overwritten will not be linear in your source code making it nearly impossible to find without a debug trace or a label dump. I would advise you to go through your code and make sure that you have taken care of any of these occurrences with the definition I posted, I will pack up what I have completed so far in the headers with the fix and upload it asap.

[shankle]

Thank you Edgar for taking the time to fix the problem.
To make sure I am understanding you correctly, is the following true:

Your "ifndef/#define" is now in all my 64-bit programs.
So the problem should be solved to my understanding.
I will download a fresh copy of the headers when they are available.
Yes, I was having problems with items being overwritten.
To fix it, I added a dummy record in between them and that seemed
to help.
 

[Donkey]

Hi Shankle,

Yes, you have understood the bug correctly, the definitions I posted that you added to your code will fix the problem for LPSTR, it does not correct the bug in GoAsm. Note that if you have used LPSTR in 32 bit code the same definition should be added there too.