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
Posted on 2009-09-12 14:35:47 by allynm
You need to link to the gdi32.lib / dll
Posted on 2009-09-12 14:48:28 by Ultrano
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

Posted on 2009-09-12 15:52:48 by allynm
TextOut is of STDCALL type with no name mangling. Try undecorating it.
Posted on 2009-09-12 16:27:10 by ti_mo_n

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.
Posted on 2009-09-12 18:17:02 by SpooK
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
Posted on 2009-09-13 00:42:22 by Synfire
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
Posted on 2009-09-13 06:39:52 by allynm
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?
Posted on 2009-09-13 06:40:40 by f0dder

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.


;)
Posted on 2009-09-13 10:40:09 by Synfire
*grin*

I had forgotten about that thread, but re-suspected (:)) that it would be the relocation issue :)
Posted on 2009-09-13 10:44:43 by f0dder
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:
Posted on 2009-09-13 10:57:00 by Synfire