[erlang-questions] open_port returns enoent even when driver init function executes correctly.
Thu Jan 3 09:30:48 CET 2013
I don't have those sources in front of me, but is there any chance that the
C code depends on another DLL? And that other one isn't on the path when
the driver is started from Erlang? I've found Windows to be super obscure
when dependencies in DLLs don't resolve properly.
On Jan 3, 2013 3:26 AM, "Jeffrey Rennie" <surferjeff@REDACTED> wrote:
> I'm working through the example here:
> And I'm trying to get it to run on Windows. I reordered the code in the C
> source so that it compiles, and added a module.def file so that erlang
> actually finds and executes the driver init function.
> I attached a debugger. Walking back up the stack, I observe that:
> The driver init function returns correctly.
> erts_sys_ddll_call_init() returns correctly.
> do_load_driver_entry() returns ERL_DE_NO_ERROR.
> load_driver_entry() returns ERL_DE_NO_ERROR.
> erl_ddll_try_load_3 returns t = TUPLE2(hp, am_ok, ok_term); on line 417 of
> But the next higher call on the stack is _process_main(), which was
> with gcc and has no debug symbols so I can't step through and figure out
> the end result is:
> =ERROR REPORT==== 2-Jan-2013::19:14:22 ===
> Error in process <0.31.0> with exit value:
> Has anyone seen this before?
> If not, how do I recompile erl.exe purely with cl.exe (no gcc) so that it
> generates debug symbols? And while I'm recompiling, how do I turn off all
> optimizations? I can read basic make files, but I get lost in the
> scripts and .in and .mk files. Please take pity on a Windows programmer
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions