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

Reply via email to