On Mon, 08 Oct 2007 21:00:15 +0100, "Pedro Alves" said:
> Vitus Jensen wrote:
> > On Sat, 06 Oct 2007 16:46:09 +0200, "Danny Backx" said:
> >> On Fri, 2007-10-05 at 22:26 +0200, Vitus Jensen wrote:
> >>>
> >>> I'm trying to port a small testprogramm from embedded Visual C 4 to
> >>> mingw32ce (cegcc-mingw32ce-0.50-1.i586.rpm). It's text mode, 2 threads,
> >>> some printf, some files, nothing fancy but ... it has to use 2 object
> >>> libraries (3rd party) and a DLL (my own).
> >>>
>
> When you object libraries, you mean, non-dlls, static libs?
Well, I thought "object libraries" was the commonly used name for such
libs? Yes, I mean libs containing actual code.
> Try playing
> with the order of libs in the link command. You could also try to
> convert those libs into a dll, to be sure that no wrong function is
> being picked up by the linker.
It's not an issue of linking or not picking the right functions. The
actual function names are quite distinctive.
> >>> I'm able to compile and link this programm but when I call the 3rd party
> >>> library an important call fails. It's the only call with several
> >>> parameters so I suspect different calling conventions.
> >>>
> >>> Goes like this:
> >>>
> >>> extern int libconfig(int hd, int subfct, void * parameter);
> >>>
> >>> test()
> >>> {
> >>> hd = libopen();
> >>> res = libconfig(hd, 1, (void *)0815);
> >>> res = libconfig(hd, 2, (void *)15);
> >>> ...
> >>> libclose(hd);
> >>> }
> >>>
> >>> Result code indicates "invalid subfunction" :-(
> >>>
>
> What does "invalid subfunction" mean?
I have no idea. I just assumed it would mean that the second parameter
named "subfct" is not a supported value.
> Are you sure the libopen call succeded?
Yes. It's the same value as when I use the lib from eVC and libclose()
doesn't complain.
> What about other functions in the lib with several parameters? Can you test
> any?
There are no other functions with more that a single parameter.
> Does the lib have a function to list the "valid subfunctions"?
No. Just a PDF. And the used subfunction numbers are valid as the
source works without change in eVC.
> Since you have eVC access, could you do a stub lib that replaces that
> third party lib, that exports the same function, but just prints the
> parameters? That way, you can be sure that the lib is seing
> the correct parameters, and invalidates/validates the calling
> conventions argument.
Good idea! As I didn't like the interface anyway I created stub code
and placed stub code and lib in a DLL, which I build using eVC. Like
this:
DWORD __stdcall
MyLibConfig(int hd, int subfct, void * parameter)
{
int res = libconfig(hd, subfct, parameter);
if( res == 0 )
return liblasterror();
else
return 0;
}
It's possible to use this "stub DLL" from mingw32ce, without any
"invalid subfunction" problems. This solves my current problem.
However it shows that calling conventions are somewhat different when
omitting __stdcall. It's not unexpected but it would be nice to use
third party libs directly. Especially if someone doesn't have access to
eVC.
Bye,
Vitus
* Photokopieren ist Raubmord! Oder so... *
--
Vitus Jensen, Hannover, Earth, Milky Way
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Cegcc-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
