Mail Archives: cygwin/2007/06/28/13:18:56
km4hr wrote:
> I got exactly the same errors as I did with the ".lib" files included.
> Apparently gcc has no idea what the ".lib" files are.
No, it would have said "unable to find library1.lib" if that was the
case.
> Since I have no comprehesion of "decorations", "toolchains", and "calling
> conventions", or how to find out what that means, I wonder if there's
> another explanation. I've got a sinking feeling about this. As if I'm going
> where no man has gone before.
No, believe me, this is extremely common when trying to use third party
vendor .lib files. When using the stdcall calling convention there is
unfortunately a lot of variance in what the various toolchains do; I
think this is because most of them trace their roots back to the days of
16 bit DOS days where there were really few standards. See
<http://wyw.dcweb.cn/stdcall.htm> for some more information.
> Thanks for trying, Brian. I can tell you know what you're talking about.
> Unfortunately I'm still completely in the dark.
Really, it's not that complicated. "decorations" in this context
commonly means a leading underscore and/or a trailing "@nn". It's a
simple case of looking at the symbols in the library, and then looking
at the gcc assembler output (-save-temps) and making the two match. If
they differ, then you create an import library that provides the
necessary aliases to make things match up. That is, after you've
confirmed that your header declares each function prototype with the
correct calling convention -- that should be step one, because there is
*nothing* you can do with linker silliness or def files or whatever to
change the calling convention that the compiler used, and so using .def
file tricks to force a cdecl caller to link to a stdcall function is
just going to cause a horrible crash.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -