Hi everyone-
I am trying to use _TextOutA@20 in a little windows program. I am assembling using nasm. Specific command is nasm -f win32 mydemo2.asm.
The program assembles without complaint. However, when I try do the link using the command gcc mydemo2.obj -o mydemo2.exe the linker complains that _TextOutA@20 is an undefined reference. Does anyone understand what's going wrong.
Added information: When I disassmeble the obj file to nasm code, the call to _TextOutA@20 is clearly present. So, it appears there's nothing (obviously) wrong with the mydemo2.obj file. All the other calls to Win API's in the program work just fine. No problems resolving them. Just _TextOutA@20.
Ideas and concepts and suggestions are welcome!
Mark Allyn
I am trying to use _TextOutA@20 in a little windows program. I am assembling using nasm. Specific command is nasm -f win32 mydemo2.asm.
The program assembles without complaint. However, when I try do the link using the command gcc mydemo2.obj -o mydemo2.exe the linker complains that _TextOutA@20 is an undefined reference. Does anyone understand what's going wrong.
Added information: When I disassmeble the obj file to nasm code, the call to _TextOutA@20 is clearly present. So, it appears there's nothing (obviously) wrong with the mydemo2.obj file. All the other calls to Win API's in the program work just fine. No problems resolving them. Just _TextOutA@20.
Ideas and concepts and suggestions are welcome!
Mark Allyn
You need to link to the gdi32.lib / dll
Hi Ultrano -
Thanks for responding. Yes, I know that I need to link to GDI32.lib. Sorry, but I forgot to put that in the command line I showed where I execute GCC. It turns out that if I do throw in the lib reference like this:
gcc -Lc:\pellesc\lib\win\gdi32.lib mydemo2.obj -o mydemo2.exe
...I still get the message from the linker regarding undefined reference. BTW, I am using minGW with GCC in the bin directory, so I need to put in the longer pathname to mingwq its to go to the pelles directory where the library is.
Thanks again,
Mark Allyn
Thanks for responding. Yes, I know that I need to link to GDI32.lib. Sorry, but I forgot to put that in the command line I showed where I execute GCC. It turns out that if I do throw in the lib reference like this:
gcc -Lc:\pellesc\lib\win\gdi32.lib mydemo2.obj -o mydemo2.exe
...I still get the message from the linker regarding undefined reference. BTW, I am using minGW with GCC in the bin directory, so I need to put in the longer pathname to mingwq its to go to the pelles directory where the library is.
Thanks again,
Mark Allyn
TextOut is of STDCALL type with no name mangling. Try undecorating it.
TextOut is of STDCALL type with no name mangling. Try undecorating it.
That may be the case depending on how --enable-stdcall-fixup or --disable-stdcall-fixup is being used.
In general, however, STDCALL types have and require specific decoration, in the format of _FunctionName@X; leading underscore, export name, and @ symbol followed by the total byte size of parameters to be passed.
Utilizing GCC in particular to link GUI apps, you want to pass the -mwindows argument to GCC so it can reference and resolve symbols in libraries such as GDI32.dll.
MinGW by default builds in console mode (however building graphical applications still works for some reason), _TextOutA@20 and other GDI functions require you be in "windows-mode". Try using the below command.
gcc -Lc:\pellesc\lib\win\gdi32.lib -mwindows mydemo2.obj -o mydemo2.exe
Also, I'll be highly surprised if that works at all. I haven't read up on mingw's compatibility (although I know using MinGW and NASM is fine, I've done it many times in the past) but using the Pelles C lib files might not work. Try using the .a files located in your \mingw\lib directory instead. There should be one named something like libgdi32.a or something similar. Object files are always touchy like that, however it might work.. I don't even own a Windows computer anymore so it's not like I can do any compatibility tests. I can tell you, however, if you decide to use NASMX stay as far away from DJGPP as you can, they aren't compatible at all.
Regards,
Bryant Keller
gcc -Lc:\pellesc\lib\win\gdi32.lib -mwindows mydemo2.obj -o mydemo2.exe
Also, I'll be highly surprised if that works at all. I haven't read up on mingw's compatibility (although I know using MinGW and NASM is fine, I've done it many times in the past) but using the Pelles C lib files might not work. Try using the .a files located in your \mingw\lib directory instead. There should be one named something like libgdi32.a or something similar. Object files are always touchy like that, however it might work.. I don't even own a Windows computer anymore so it's not like I can do any compatibility tests. I can tell you, however, if you decide to use NASMX stay as far away from DJGPP as you can, they aren't compatible at all.
Regards,
Bryant Keller
Hi Folks,
My thanks to Bryant Keller and to Spook. I tried the command that Bryant suggested:
gcc -Lc:\pellesc\lib\win\gdi32 -mwindows mydemo2.obj -o mydemo2.exe
AND IT WORKED. -mwindows really matters.
Holy Cow...!
Ciao,
Mark Allyn
My thanks to Bryant Keller and to Spook. I tried the command that Bryant suggested:
gcc -Lc:\pellesc\lib\win\gdi32 -mwindows mydemo2.obj -o mydemo2.exe
AND IT WORKED. -mwindows really matters.
Holy Cow...!
Ciao,
Mark Allyn
I can tell you, however, if you decide to use NASMX stay as far away from DJGPP as you can, they aren't compatible at all.
How come? DJGPP is just GCC, after all?I can tell you, however, if you decide to use NASMX stay as far away from DJGPP as you can, they aren't compatible at all.
How come? DJGPP is just GCC, after all?It's kinda funny you asking that, as you're the one who directed me to the reasoning in an older post. XD
It's because the object formats are not compatible. NASMX uses the MS-COFF format whereas DJGPP has their own DJGPP-COFF format which has slight differences. If you look back to the original thread of that discussion, DJGPP would build an executable file but the relocations were messed up. Or to quote you...
It has to do with the particular flavor of COFF objects generated - basically there's ms-coff and djgpp-coff. One toolchain stores 0 for reloc items and lets the linker do full fixup, the other stores a base value and has the linker do delta adding.
This of course means that any relocatable items produced with one toolchain compiler and linked with a linker from the other will be *seriously* screwed up.
This of course means that any relocatable items produced with one toolchain compiler and linked with a linker from the other will be *seriously* screwed up.
;)
*grin*
I had forgotten about that thread, but re-suspected (:)) that it would be the relocation issue :)
I had forgotten about that thread, but re-suspected (:)) that it would be the relocation issue :)
Yea, it was a real pain in the *** when I first came upon the issue. I generally try and figure problems out on my own (that's the way I've always done things. I just like the whole R&D type stuff) so unless I've spent days trying to solve an issue I generally don't post requests for any help. That was one of the few that nearly drove me insane. :lol: