Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug]: can't build on debian #8872

Open
paboum opened this issue Jun 26, 2024 · 9 comments
Open

[bug]: can't build on debian #8872

paboum opened this issue Jun 26, 2024 · 9 comments
Labels
bug Unintended code behaviour needs triage

Comments

@paboum
Copy link

paboum commented Jun 26, 2024

Background

go.mod seems to have a non-supported three-number version dependency

Your environment

  • version of lnd v0.18.1-beta
  • which operating system (uname -a on *Nix) debian
  • version of btcd, bitcoind, or other backend n/a
  • any other relevant environment details installed latest go with go install golang.org/dl/go1.22.4@latest ; go1.22.4 download

Steps to reproduce

git clone; make install

Expected behaviour

It should build

Actual behaviour

$ make install
go: errors parsing go.mod:
lnd/go.mod:208: invalid go version '1.21.4': must match format 1.23
 Installing lnd and lncli.
go install -v -tags="" -ldflags=" -s -w -buildid= -X github.com/lightningnetwork/lnd/build.Commit=v0.18.1-beta" github.com/lightningnetwork/lnd/cmd/lnd
go: errors parsing go.mod:
/home/btc/lnd/go.mod:208: invalid go version '1.21.4': must match format 1.23
make: *** [Makefile:131: install-binaries] Błąd 1

Removing .4 from the file mentioned seems to fix the issue. It uses the system-wide go1.19.8 to build however. I am curious to edit the Makefile to hardcode using go1.22.4 in the build, but it works wine with 1.19.8. This should be checked prior to starting the build since 1.21 is supposedly the minimum supported version.

@paboum paboum added bug Unintended code behaviour needs triage labels Jun 26, 2024
@guggero
Copy link
Collaborator

guggero commented Jun 26, 2024

Are you sure you installed go 1.22 correctly? If you run go version do you get 1.22.4?
Older versions (I think before 1.20) will not understand the new 3-part go version in go.mod. And since you're mentioning go 1.19.8 I assume your old installation of that version is still being used.

@paboum
Copy link
Author

paboum commented Jun 26, 2024

$ go version
go version go1.19.8 linux/arm64
$ go1.22.4 version
go version go1.22.4 linux/arm64

As mentioned in #6489, I was using hardcoded go version in Makefile until early this year. Since all the Makefile was recently reinvented, today I'm using the original one from the repo.

Since changing

go 1.21.4

in go.mod to:

go 1.21

helps building the project and it's even running, I refuse to accept that anything is wrong with my debian (raspbian, to be specific). It rather seems the go version dependency is too strict and the issue #6489 is still not resolved.

Official "Managing Go installations" docu says (https://go.dev/doc/manage-install):

To run go commands with the newly-downloaded version, append the version number to the go command, as follows:

$ go1.10.7 version
go version go1.10.7 linux/amd64

To be super-precise here, I checked lnd docu on how to install Go:

lnd is written in Go, with a minimum version of 1.19. To install, run one of the following commands for your OS:

If it matches, then proceed to install Go:

sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.22.4.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin

Not only it seems not up-to-date (mentions 1.19) but also breaks user-wide compatibility of previous go binary with whatever other projects might be requiring go binary, possibly affects other users and is drastically different from the official Go project's recommendation whilst not providing any significant reason for why go should be installed like this. I can only guess it's "easier for the devs" but apparently the list of issues is growing.

@ellemouton
Copy link
Collaborator

ellemouton commented Jun 26, 2024

and is drastically different from the official Go project's recommendation whilst not providing any significant reason for why go should be installed like this

If you go to the "Linux" tap on the official Go project's page, these are exactly the steps it uses to install go... https://go.dev/doc/install

@guggero
Copy link
Collaborator

guggero commented Jun 26, 2024

Okay, I see. Your go 1.22.4 installation/binary is accessible as go1.22.4 instead of just go. That's why the make command doesn't work, since it uses the old version.

The installation instructions were recently updated: #8856

So I guess this is a duplicate of #6489 then? Since the root cause is the same.

@guggero
Copy link
Collaborator

guggero commented Jun 26, 2024

Not only it seems not up-to-date (mentions 1.19) but also breaks user-wide compatibility of previous go binary with whatever other projects might be requiring go binary, possibly affects other users and is drastically different from the official Go project's recommendation whilst not providing any significant reason for why go should be installed like this. I can only guess it's "easier for the devs" but apparently the list of issues is growing.

Go has a hard promise on backward compatibility. And there's no downside of using a newer version than a project requires. Therefore I don't think one project requiring a newer version (which is then installed system wide) should have any effect on other projects.

paboum added a commit to paboum/lnd that referenced this issue Jun 27, 2024
@paboum
Copy link
Author

paboum commented Jun 27, 2024

So I guess this is a duplicate of #6489 then? Since the root cause is the same.

Not exactly. #6489 would perhaps fix this one, but still there is a 1.21.4 dependency in go.mod while requiring 1.21 works fine too and fixes the current issue. Edit: I guess it doesn't really matter as far as I'm providing 1.22.4 - then perhaps lnd should require 1.22 as the most recent major version that includes 1.21.4 features?

Go has a hard promise on backward compatibility.

Perhaps the language definition is never introducing breaking changes, yes. But the toolchain is frequently preventing old projects from building, e.g. requiring go.mod files since 1.16 IIRC. As you can see, I built the project with 1.19 as system-default go with 1.22.4 only available via ~/go/bin and it manages to find it, but requires go.mod to use two-number version limit (which I guess makes sense because minor updates don't change language definition, right?). Thus it wouldn't hurt to update (patch from me: master...paboum:lnd:patch-1 ).

PS. I've found upstream issue thread too: golang/go#61888 - seems that there is a "new version format"?

@guggero
Copy link
Collaborator

guggero commented Jul 8, 2024

I can compile the current master branch just fine with go 1.21.0, so the .4 in the go.mod is not the issue. It's that make explicitly uses the go binary in your path (which is still the system wide version go 1.19.8). And since the three part version number is only understood by go 1.21.x, you get the error.

Can you try if this PR fixes the issue for you? #8900

@paboum
Copy link
Author

paboum commented Jul 15, 2024

No it doesn't.

btc@rasp-btc:~/lnd $ LANG=C git status
HEAD detached at v0.18.2-beta
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   Makefile

no changes added to commit (use "git add" and/or "git commit -a")
btc@rasp-btc:~/lnd $ git diff
diff --git a/Makefile b/Makefile
index 5ea087892..921027846 100644
--- a/Makefile
+++ b/Makefile
@@ -3,6 +3,7 @@ ESCPKG := github.com\/lightningnetwork\/lnd
 MOBILE_PKG := $(PKG)/mobile
 TOOLS_DIR := tools
 
+GOCC ?= go
 PREFIX ?= /usr/local
 
 BTCD_PKG := github.com/btcsuite/btcd
@@ -31,9 +32,9 @@ ifeq ($(shell expr $(GO_VERSION_MINOR) \>= 21), 1)
        LOOPVARFIX := GOEXPERIMENT=loopvar
 endif
 
-GOBUILD := $(LOOPVARFIX) go build -v
-GOINSTALL := $(LOOPVARFIX) go install -v
-GOTEST := $(LOOPVARFIX) go test
+GOBUILD := $(LOOPVARFIX) $(GOCC) build -v
+GOINSTALL := $(LOOPVARFIX) $(GOCC) install -v
+GOTEST := $(LOOPVARFIX) $(GOCC) test
 
 GOFILES_NOVENDOR = $(shell find . -type f -name '*.go' -not -path "./vendor/*" -not -name "*pb.go" -not -name "*pb.gw.go" -not -name "*.pb.json.go")
 
btc@rasp-btc:~/lnd $ make install
go: errors parsing go.mod:
/home/btc/lnd/go.mod:208: invalid go version '1.21.4': must match format 1.23
 Installing lnd and lncli.
go install -v -tags="" -ldflags=" -s -w -buildid= -X github.com/lightningnetwork/lnd/build.Commit=v0.18.2-beta-dirty" github.com/lightningnetwork/lnd/cmd/lnd
go: errors parsing go.mod:
/home/btc/lnd/go.mod:208: invalid go version '1.21.4': must match format 1.23
make: *** [Makefile:132: install-binaries] Błąd 1

However, setting GOCC in Makefile or via env variable to go1.22.4 does help me. Might be a good idea to document this as well. Still yields a warning though:

btc@rasp-btc:~/lnd $ GOCC=go1.22.4 make install
go: errors parsing go.mod:
/home/btc/lnd/go.mod:208: invalid go version '1.21.4': must match format 1.23
 Installing lnd and lncli.
go1.22.4 install -v -tags="" -ldflags=" -s -w -buildid= -X github.com/lightningnetwork/lnd/build.Commit=v0.18.2-beta-dirty" github.com/lightningnetwork/lnd/cmd/lnd
vendor/golang.org/x/net/http2/hpack
vendor/golang.org/x/net/http/httpguts
vendor/golang.org/x/net/http/httpproxy
github.com/btcsuite/btcd/txscript
...
go1.22.4 install -v -tags="" -ldflags=" -s -w -buildid= -X github.com/lightningnetwork/lnd/build.Commit=v0.18.2-beta-dirty" github.com/lightningnetwork/lnd/cmd/lncli
github.com/rivo/uniseg
github.com/shurcooL/sanitized_anchor_name
github.com/mattn/go-runewidth
github.com/jedib0t/go-pretty/v6/text
github.com/andybalholm/brotli
github.com/jedib0t/go-pretty/v6/table
github.com/lightningnetwork/lnd/lnrpc/lnclipb
github.com/russross/blackfriday/v2
github.com/cpuguy83/go-md2man/v2/md2man
github.com/urfave/cli
github.com/lightningnetwork/lnd/cmd/lncli
btc@rasp-btc:~/lnd $ 

@guggero
Copy link
Collaborator

guggero commented Jul 15, 2024

Of course you'd need to specify the GOCC parameter when using make that way, that's the whole point of the PR.
But it seems to be working. The warnings are from a couple of instances I missed to replace, they should be gone on the latest version of the PR.

I'll document things once we confirm this fully works for your use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Unintended code behaviour needs triage
Projects
None yet
Development

No branches or pull requests

3 participants