Hi @chrischabot
I am having an issue while running make install from docker file
Below is the description of my Dockerfile:
docker file for zapp: a golang app:
FROM golang:alpine
MAINTAINER ‘xyz’
ENV PACKAGES curl make git libc-dev bash gcc linux-headers eudev-dev python
ADD ./zapp.tar . {This is tar of my app build in go}
WORKDIR ./zapp
RUN apk add --no-cache $PACKAGES &&
make install --> giving error
CMD [“zd”] --> by default should run binary
What did i expect to see?
– after make install command binaries should get built of my app (ie : zcli and zd)
What did i see instead?
– after make install command i am getting error as: _go: updates to go.mod needed, disabled by -mod=readonly
make: *** [Makefile:18: install] Error 1
Without knowing more about your Makefile, it will be hard for us to debug exactly what’s going on. If at all possible, can you provide your Makefile (or at least the install target)? Are you building this container locally or rather on a balenaCloud remote builder? This error seems like a go version mismatch, but without more information we cannot help debug further.
This appears to be an issue localized to the Makefile for this go project. Your go install line specifies -mod=readonly while one of your go packages requires an updated version of some dependency which your go.mod file has pegged to an earlier version. You could simply -mod=readonly to resolve this the easy way. The go install error message here is not very descriptive, and there’s an open issue on golang’s cmd/go repo for this.
All that said, this isn’t really an issue with balena, so we can only provide best-effort support in this case. I hope this helps!
@dt-rush
Thanx for your support
just a quick question actually we have customised cosmos-sdk and want make install to download from our customised-sdk but its downloading from online so how to set the path in dockerfile so that “make install” download from our customised sdk.
hey @mayank16, we’d recommend checking out the golang documentation and discussion for that.
Doing a quick search, it seems like you might be able to solve this by explicitly cloning your forked version of that code to the upstream code’s path in the relevant go folders, as outlined in the answers in this stackoverflow question:
Not sure if there’s a newer way of doing that, but this might give you some idea where to look.