[MLton-user] Linking issues with FFI on Vista

[John Reppy]

Thanks for the information.  With the addition of "public" annotations, I can now get the program to link, but I get some strange warnings:

  Warning: resolving _glutDisplayCB by linking to _glutDisplayCB at 0
  Use --enable-stdcall-fixup to disable these warnings
  Use --disable-stdcall-fixup to disable these fixups
  Warning: resolving _glutReshapeCB by linking to _glutReshapeCB at 8
  Warning: resolving _glutKeyboardCB by linking to _glutKeyboardCB at 12
  Warning: resolving _glutVisibilityCB by linking to _glutVisibilityCB at 4

Unfortunately, the program dies almost immediately.  What debugger does one use to track this issues down?  The MinGW stuff that comes with
MLton has gcc, but not gdb.

Also, I'm guessing that adding "public" attributes will break on 20070826?  Is there any chance for a new release sometime soon?


-          John


From: Wesley W. Terpstra [mailto:wesley at terpstra.ca]
Sent: 08 September 2008 14:00
To: John Reppy
Cc: mlton-user at mlton.org
Subject: Re: [MLton-user] Linking issues with FFI on Vista

On Mon, Sep 8, 2008 at 2:29 PM, John Reppy <t-johrep at microsoft.com<mailto:t-johrep at microsoft.com>> wrote:
I have the following SML code for handling the display callback in GLUT:

   val exportDisplay           = _export "glutDisplayCB" stdcall : (unit -> unit) -> unit;
   val glutDisplayCB           = _address "glutDisplayCB" : Ptr.t;

In newer versions of MLton (like svn/HEAD), that code is in error. The _export has an implied symbol scope of "public", but the _address as you've use it has an implied symbol scope of "external". Because it's external it is trying to import the _address from a DLL. The code it generated is correct for this purpose. What you need to do is this:

_export "glutDisplayCB" private : (unit -> unit) -> unit;
_address "glutDisplayCB" private : Ptr.t;

This makes the symbol scope agree in both cases as being private. You could also use public, if you liked. I don't know if you need 'stdcall' or not. Check the OpenGL docs. If you do, it will probably segfault when it tries to run the callback. ;-)

Unfortunately, symbol scopes are not yet documented. They've only recently been implemented. Except for the case of taking the address of an exported function, though, it shouldn't be necessary to know how it works.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton-user/attachments/20080908/84a4bc08/attachment-0001.html