This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Trouble with DLL and file (com port) IO


On 06 December 2006 17:01, R. Steve McKown wrote:

> FWIW, I'm using dlopen()/dlsym() to link to the DLL.  'nm' on the
> provided .lib file shows decorations on the function names, even though they
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> are C.  Perhaps the vendor didn't use "extern C {"?  

  Nope.  MS does decorations even in plain old C.

> When linking with
> the .lib I get symbol not found errors.  Dynamically loading the DLL solves
> this problem.

  According to what you write next, it doesn't really do so ('solve' the
problem) after all ...

> Th extension accepts a file descriptor to an open serial port, uses the
> cygwin get_osfhandle() function to get the corresponding HANDLE, calls the
> DLL function, then returns. ?When run, python core dumps somewhere between
                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the return statement in the extension function and the next python program
  ^^^^^^^^^^^^^^^^^^^^
> statement 

  Go research what those decorations actually signify.  Here's some terms to
help get you started at Google:  cdecl, stdcall, fastcall.  Actually,
nevermind google, you may as well go straight to MSDN.

> realities.  I'm hoping someone can see an obvious mistake

  Over- or under- popping the stack, in this case.

  The only other obvious mistake was spamming everyone on the list with a
couple of hundred kb of completely useless crud that means absolutely nothing
to anyone who doesn't have the custom hardware that you have!  It's not
Posting A Simple Testcase if nobody can make any use of it.

  BTW, mixing MSVC-based code with cygwin-based is inherently unreliable and
liable to fail unpredictably.  I guess the vendor isn't likely to want to
share their dll source with you so you could recompile it with gcc, but it
might not be /too/ complicated to just take a look at the USB transactions
that get sent across the bus when you try to manipulate the gpios using their
dll, then throw together your own custom library to send the same transactions
using libusb or similar.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]