Argon2_elixir on Windows 10: running out of ideas

Questions / Help
1

Having used argon2_elixir on Windows 10 (now v1903) for over a year, with Visual Studio 2017, I am currently running out of ideas as to what has gone wrong and it will no longer compile. I have Elixir 1.9.2 with OTP 22.1 installed (downgrading to versions 1.8 and 21 respectively did not work). A PATH to nmake (x64/x64) is already in place (tested with “where nmake”), I have tried VC++ initialization with both “VsDevCmd.bat -arch=x64” and “vcvarsall.bat amd64”, to no avail. Downgrading the most recent version of argon2_elixir to 2.0.1 changed nothing, nor did upgrading to Visual Studio 2019.

argon2_elixir%201
argon2_elixir%201992×418 15.5 KB

argon2_elixir%202
argon2_elixir%202992×193 8.03 KB

The first screenshot shows the output when argon2_elixir is initially downloaded, before Makefile.auto.win is created (under deps\argon2_elixir), the second screenshot what happens subsequently. The Crashdump Viewer displays this:

argon2_elixir%203

The solution is probably much simpler than the things already attempted. Until I discover it, however, I can no longer work on my project. Replacing Argon2 with another algorithm is not an option I wish to consider. Please help – all ideas are welcome as my brain seems to have stopped generating any…

2

In Makefile.auto.win there will be the full exit reason.

When you exit Erlang/Elixir the full slogan is printed to stdout and then a truncated slogan is printed to stderr. Since argon seems to do a redirect to Makefile.auto.win of the output of stdout the error reason will be put in that file. Then when you the next time try to run that Makefile, you actually try to run the error which will not work.

So check what text is in the Makefile and fix whatever that problem is :slight_smile:

1 Like
3

Thank you for the swift and informed response. Makefile.auto.win contains the text below. As an Erlang newbie, I am unable to extract any pointers from this info. Could you please provide any further help?

{“init terminating in do_boot”,{badarg,[{io,format,[<0.61.0>,"~s~n",[[69,82,84,83,95,73,78,67,76,85,68,69,95,80,65,84,72,61,99,58,47,80,114,111,103,114,97,109,32,70,105,108,101,115,47,8226,32,80,114,111,103,114,97,109,109,105,110,103,47,69,114,108,97,110,103,47,101,114,116,115,45,49,48,46,53,47,105,110,99,108,117,100,101]]],[]},{erl_eval,do_apply,6,[{file,“erl_eval.erl”},{line,680}]},{init,start_it,1,[{file,“init.erl”},{line,1123}]},{init,start_em,1,[{file,“init.erl”},{line,1109}]},{init,do_boot,3,[{file,“init.erl”},{line,817}]}]}}

4

If you do this:

:io.format('~ts',[[69,82,84,83,95,73,78,67,76,85,68,69,95,80,65,84,72,61,99,58,47,80,114,111,103,114,97,109,32,70,105,108,101,115,47,8226,32,80,114,111,103,114,97,109,109,105,110,103,47,69,114,108,97,110,103,47,101,114,116,115,45,49,48,46,53,47,105,110,99,108,117,100,101]])

It will print

ERTS_INCLUDE_PATH=c:/Program Files/• Programming/Erlang/erts-10.5/include

which shows that your Erlang is installed in a path with both a space and a unicode character. argon does not seem to like this at all.

4 Likes
5

This is not a problem of argon, its a problem of properly escaping pathes.

It would probably work if the content were properly quoted:

ERTS_INCLUDE_PATH="C:/Program Files/• Programming/Erlang/erts-10.5/include"

Though I have no clue where things needed to be changed to properly quote… The easier way is in fact to move to a place where there are no spaces and no non-ascii characters in the location.

1 Like
6

Thanks Lukas and Norbert, the Elixir community displays its brilliance again! The sequence of events indicates that the unicode character must indeed be the root cause of this problem (the spaces had been there before I made a set of changes). It seems to me that this is an issue the argon2_elixir developer should be informed about (once I actually confirm what we all suspect), don’t you think?

1 Like
7

This is not a problem of argon, its a problem of properly escaping pathes.

I meant argon2_elixir, not argon.

It seems to me that this is an issue the argon2_elixir developer should be informed about (once I actually confirm what we all suspect), don’t you think?

Yes. They need to use ~ts instead of ~s when printing strings in a unicode environment.

2 Likes