From: Carl H. <ct...@ca...> - 2001-11-12 12:31:25
|
On Sat, 10 Nov 2001, [iso-8859-1] Danny Smith wrote: > --- Carl Hetherington <ct...@ca...> wrote: > Hi, > > > > I'm trying to make use of Intel's Signal Processing Library (SPL) from > > GCC/mingw. I have created a GCC import library using the > > pexports/dlltool > > combo. > > > > The SPL requires the use of the stdcall convention. What I'd really like > > to do is define the SPL's functions using things like > > > > extern void __stdcall nspdConv(double* x, int xLen, double* h, int hLen, > > double* y); > > > > This doesn't work, however, because the SPL DLL exports its names > > un-mangled. Declaring functions as above results in link errors about > > not > > being able to find the symbol `nspdConv@20'. [snip] > dlltool --killat --output-lib libspl.a --def spl.def > > How do you get the decorated names? You can get those from the headers > manually or using pexports (read the pexports readme.) Or if you have the > Intel import lib, use pedump or nm or some other tool to extract the > exports from the the import lib. You will probably have to strip off the > leading underscore from the names. Thanks a lot Danny, this seems to have fixed it :-) I have now changed the Intel library headers to declare all functions with __stdcall. The .def file uses decorated names like nspdConv@20 and building the import library using --kill-at makes everything work perfectly. I'm a little puzzled as to why Intel's original headers do /not/ use __stdcall with GCC. It might be something to do with the Linux support that they seem to have. My original experiments with the library (using cdecl) caused exactly the kind of odd stack-related crashes that I'd expect from using the wrong calling convention. Still: the problem that has been bugging me for weeks is now solved. Thanks again :-)) Carl |