Switch from alink to ld

[menemenetekel]

Hi,

I would like to switch from my current linker "alink" to MinGW's linker "ld".

But: When I try to submit ld (--dll) an object file generated by nasm compiler (-fobj) as I successfully do with alink (-oPE -dll -subsys con) ld will not recognize the .obj:
> ld --dll test.obj
test.obj: file not recognized: File format not recognized

The same object works fine with alink. (I'm on a win32/Vista machine)

Any Idea?

Thanks, Mene

[Frank Kotler]

Well, switch to "-f win32"... but "import" is known only to "-f obj", so Nasm'll complain if you've used that. Without it, you may need to tell ld where to find "libraries". (got me) You may need to "%define ExitProcess _Exitprocess@4", etc. or use the "true names" throughout. You may need to lose the square brackets around "call [ExitProcess]", if you've got 'em. I think I got it to work once using the libraries from MASM32 (Cygwin ld, but should be similar?).

Hopefully, someone more knowledgeable in Windows can help you!

Best,
Frank

[menemenetekel]

Oh-no! Not this!
I'm doing almost everything on base of this import mechanism...

OK, I did some first "investigations" on this topic. Frank, you are completey right, I've to take the -fwin32 option on nasm.exe to have an object file being accepted as such by ld. Trying to link, say the well known HelloWord program using this "tricky" printf function from crtdll.dll, by something like this

ld --format="pe-i386" --entry="HelloWorld" --strip-all --output="HelloWorld.exe" --library-path="<where they are>" --library=crtdll.lib HelloWorld.obj

my favourite problem arises:

HelloWorld.obj:HelloWorld.asm:(.text+0x7): undefined reference to `printf'

But: in crtdll.lib as well as in the crtdll.dll there *is* defined the symbol 'printf' - no "_printf" or even a "@4" or whatever decoration - simply 'printf' (and for sure also the __imp__printf). And with my -fobj + alink solution it works both ways

1. by symbol: extern printf and calling as [printf]
2. by table  : import printf and calling as  printf

I preferred the 2nd because this way I've no dependency on an annoying "crtdll.lib" or any other lib, which from my experience often are incomplete and generate problems, only - as you can see above ;-)

I struggled around here with "_" and decorations, various syntax variations of the ld command above etc. I tried with kernel32.dll functions instead of crtdll.dll and so forth... no success yet :-(

For the moment, I've to focus on some other projects and will follow up this thread later, again.

So, many thanks for now,
Mene

[Rob Neff]

I know this may be stating the obvious, but did you

extern _printf

in your source?

[menemenetekel]

Yes, I did...
I remember I had this kind of trouble with that stuff already some years ago when I decided to go the easy way using fobj & import.
Those days I downloaded LIBs form the internet as well as I generated them by myself using alib.exe and, I guess, some other tools, also.
I am and I was quite sure I'm missing some most likely "trivial" thing here, but right now I can't see it...
Meanwhile, I also tried Microsoft link.exe - same result as with MinGW's ld.exe. I could not link nasm -fwin32 generated objects.
OK, could be an indicator that there is something wrong with the -fwin32 objects, but on the other hand it's also possible I did the same mistake in both cases, don't know... I'll investigate that later this year again and come back to this place ;-)
Thanks, Mene