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 Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel