How do I compile and use argon2 in Phoenix app

Phoenix Forum Questions / Help
,
1

Hi,

I’m really stuck for long hours just to install argon2 in my Phoenix app and can’t figure out what should I do to make it work.

Here’s what I tried to far.

Since I installed build tools from Visual Studio 2019 Preview installer I run this command.
cmd /K "C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Auxiliary\Build\vcvarsall.bat" amd64

Then the result is

**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.5.0-pre.1.0
** Copyright (c) 2019 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

C:\Windows\System32>cd \Users\Utsuro\Desktop\demoauth

C:\Users\Utsuro\Desktop\demoauth>mix compile
==> argon2_elixir

Microsoft (R) Program Maintenance Utility Version 14.24.28314.0
Copyright (C) Microsoft Corporation.  All rights reserved.

'where' is not recognized as an internal or external command,
operable program or batch file.
        del /Q /F priv
Could Not Find c:\Users\Utsuro\Desktop\demoauth\deps\argon2_elixir\priv
        nmake /                   /F Makefile.win priv\argon2_nif.dll
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.24.28314\bin\HostX64\x64\nmake.EXE"' : return code '0x2'

Since its not working I try the suggestion in Comeonin and install VisualCppBuildTools. but running choco install VisualCppBuildTools then executing a cmd command
cmd /K "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 but the result is still the same


C:\Users\Utsuro\Desktop\demoauth>mix compile
==> argon2_elixir

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

where' is not recognized as an internal or external command,
operable program or batch file.
        del /Q /F priv
Could Not Find c:\Users\Utsuro\Desktop\demoauth\deps\argon2_elixir\priv
        nmake /                   /F Makefile.win priv\argon2_nif.dll

I’m really stuck and I really need to work this out.
I’m using Windows 10 Home SL Version 1903

2

I remember having this issue when I was using a Windows machine. My “solution” at the time involved using Pbkdf2 instead of Argon2: https://github.com/riverrun/comeonin#windows-users

1 Like
3

Another possible “solution” in the same vein would be to build using WSL. I know I’ve often resorted to such “solutions” when library authors didn’t have windows machines on hand for testing :slight_smile:

1 Like
4

So I will compile it in WLS? After it compiles then I use it just normal in my windows machine?

5

No, if you compile in WSL, you have to stay in WSL land.

6

Use a virtual machine (vm) for Linux. The recommended one is virtualbox with Kubuntu. That is what I am using and have no problems.

Get virtualbox from here https://www.virtualbox.org/wiki/Downloads

Also i ma considering in the near future to go all Linux

Also check this thread out to see how the dev feels before diving in Kubuntu against my old Bodhi Linux

7

Yes… you’d need to install ubuntu for example under WSL, and then follow the instructions in the elixir website to install erlang and elixir under WSL. Then you can compile (and run) your code from inside WSL. Or you can compile inside WSL and run from a regular cmd prompt (most of the times).

PS. an issue that we commonly faced running code from WSL was that there was no graphics under WSL and thus no observer UI (you need more hacking to get it to run). There are a couple other quick workarounds (like wobserver, cli_observer or using erlang distribution to connect from another node in windows and then start observer from that node)… you get the point. It can be a rabbithole. Yay for elegance.

8

So I will developing in WSL then?

9

Very possible. Windows is not well-supported by many library authors where a native (C/C++) code has to be compiled in-place, inside the user’s OS. Windows is notoriously bad for this; it does not have the proper development files installed (and accessible in standard locations) for development workflows. So blame Microsoft. If tomorrow Windows gets standard header and object files (as Macs and Linux machines have) then supporting native compilation out of the box will be easy. But this is still not done and at this point it seems too late even if Microsoft gets it done.

Developing on Windows is a doomed adventure. Either use a Linux VM to develop in (VirtualBox is quite good; a main Win10 machine + Linux VM has been my setup for years before I moved to Macs) or just install Linux directly. Or buy a Mac.

Again, this is not the fault of the library authors. The needed machinery inside Windows is simply missing. You can install it but it’s a very error-prone process and success is not guaranteed. I’ve done it successfully in the past but it costed a lot of time and nerves to get it right. Nowadays I’d charge $500 an hour for such a service. :003:

Notable exception is Rust; if your Elixir libraries depend on Rust native libraries (one such library is meeseeks) then there’s no problem even on Windows – at least with the several I tried. But you can’t expect thousands of old and well-established libraries (like, say, ImageMagick) to migrate to Rust just so programmers can develop on Windows. Windows is simply not viewed as worth supporting as a development environment by almost everyone.

10

I use Argon2 on Windows for my Phoenix apps. I run the following command in ConEmu:

cmd /k “C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\Tools\vsdevcmd” -arch=x64

11

Sorry but this does not work for me. I decided to go full WSL now. Its going smooth.

12

No it isn’t. I’ve been developing Elixir on Windows for more than three years, and aside from this particular inconvenience (easily solved by installing VSCPP build tools), it has been quite smooth sailing. Overall, there hasn’t been anything that has made me wish I was on a Mac (or Linux — yuck).