Function Bcrypt.Base.gensalt_nif/3 is undefined (module Bcrypt.Base is not available)

Are you able to share your Dockerfile and your mix.exs (the deps part at least)?

Here is the dockerfile for my phoenix app
# base image elixer to start with
FROM elixir:1.6

# install hex package manager
RUN mix local.hex --force
RUN mix local.rebar --force

# install the latest phoenix 
RUN mix archive.install https://github.com/phoenixframework/archives/raw/master/phx_new.ez --force

# create app folder
RUN mkdir /app
COPY ./my_app /app
WORKDIR /app

# install dependencies
RUN mix deps.get && (cd deps/bcrypt_elixir && make clean && make) && mix deps.compile
WORKDIR /app

# run phoenix in *dev* mode on port 4000
CMD mix ecto.create && mix ecto.migrate && mix run priv/repo/seeds.exs && mix phx.server

Why do you cd into deps/bcrypt_elixir and run make clean && make there? That feels wrong…

My assumption is, that you do this, because the deps folder from your host is put into your docker container during COPY ./my_app /app and therefore you have build artifacts which do not match the system in the container and you try to “repair” this by force rebuilding in docker? This probably doesn’t work, as there might still old artifacts for the wrong architecture remain in the also copyed _build folder.

Instead you should properly .dockerignore the deps and _build folders to really be sure, that nothing wrong slips in.

this is the reason why i did it:
https://github.com/riverrun/comeonin/issues/64

if I ignore my_app/deps, does that mean that i can’t run mix deps.get in my dockerfile anymore? What do i do then?

No, it actually means that you have to do it. Without ignoring it, the deps and _build folder from your host will be copied over into the container, wasting space in the layer is one of the downsides, the other is, that they might contain artifacts that are incompatible with the containerized erlang and elixir.

Also the linked issue does not affect a docker container, at least not if it is build correctly. As a correctly built docker container should never see old artifacts in deps and _build as they never should exist on the container prior to mix deps.get and mix deps.compile/mix compile.

The ticket above really only affects those that compiled a NIF on OTP N, update erlang and get back to that project, but now have OTP N+1. Then the NIF wouldn’t be recognized, and in that issue a nasty workaround was shown. The proper way to handle this is actually mix do deps.clean bcrypt_elixir, deps.build.

But to be honest, my general advise is to simply rm -rf deps _build; mix do deps.get, deps.compile after updating Erlang or Elxir. Just to make sure that all libraries used use the latest enhencements of the language.

I don’t understand, I removed both deps and _build folders. Does the command RUN mix deps.get && mix deps.compile get included in the dockerfile or not. When I run docker-compose build then docker-compose up, Because I put deps and _build in the dockerignore file I get this error:

phoenix_1  | Unchecked dependencies for environment dev:
phoenix_1  | * bcrypt_elixir (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * faker (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * ueberauth_google (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * redix_pubsub (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * gettext (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * absinthe (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * ueberauth (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * poolboy (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * ueberauth_facebook (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * poison (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * comeonin (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * guardian (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * cowboy (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * httpoison (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * absinthe_ecto (https://github.com/absinthe-graphql/absinthe_ecto.git)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * ecto (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * phoenix_pubsub (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * absinthe_plug (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * phoenix (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * postgrex (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | * phoenix_ecto (Hex package)
phoenix_1  |   the dependency is not available, run "mix deps.get"
phoenix_1  | ** (Mix) Can't continue due to errors on dependencies

Or do I run mix deps.get and mix deps.compile in the terminal first before running docker-compose build and then subsequently docker-compose up?

Either way, I still get the same error and it doesn’t work

Here is my repository you can check it out and see what I’m doing wrong, I have two dockerfiles since I want to run a golang microservice along with my web server:
https://github.com/sc4224/genesys

Of course it does, it is needed to fetch and compile the dependencies.

ok so i still get the error saying that the dependency is not available

Which dependency is not available? When do you get that error message? Do you get any errors or messages during building container?

The errors are the errors mentioned above. This happens when I run docker-compose build. Take a look at my repository above, is it the fact that I am putting too many services in one container, possibly giving rise to errors when I reference folder paths?