-
Notifications
You must be signed in to change notification settings - Fork 91
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
Master fails to build with undefined: grpc.ClientConnInterface #172
Comments
Probably an issue with the generated file
|
In my opinion generated files shouldn't be committed to the repo. But I'm not a Go developer, I don't know what are common practice in the Go community. But clearly it would avoid this kind of issue. There are different versions of the tool to generate the code, and if I'm not mistaken, 1.3 and 1.5 are not compatible.
I believe I generated the code with the old 1.3, but I'm not 100% sure. |
The rebuild didn't work here and leads to more errors, likely because I have an incompatible version. Also not a go-developer, but given that the generation tools have to match the library versions suggests to me that committing the generated files is preferred. |
How I build the package for a Debian bookworm system can be seen under https://salsa.debian.org/debian/mirrorbits/-/tree/debian/latest/debian?ref_type=heads. Two things that really matter are:
This line is rather convoluted, but it was used as such to fix build failures with libprotobuf-dev 3.21.9 (details at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026674). Can you try to rebuild the |
Your command generates the same file as is currently in git here. |
Alternatively, if you find yourself trying to build with
As you can see, I'm not really good at Go either... |
Just do clarify, current master builds for you on bookworm? |
Let me try, but I expect it does, bookworm is stable |
Builds in Debian bookworm at first try. In Debian unstable, error:
After adding |
Hm, I'm doing something wrong then, this is what I get in a clean bookworm container: FROM debian:bookworm
RUN apt-get update -y && \
DEBIAN_FRONTEND=noninteractive apt-get install -y golang make pkg-config zlib1g-dev git && \
apt-get clean
RUN git clone https://github.com/etix/mirrorbits
RUN cd mirrorbits;make
|
|
Maybe it's this one: golang/protobuf#1596. Or maybe not. |
I think the lines that matter in your logs are:
Despite the line In contrast, to build the Debian package, I build offline with |
Yeah, the makefile explicitely updates protoc-gen-go to the latest version which pulls this in. If I fix it I still get the same build error though. |
ah, looking at the Debian build again I see it is building against different version to the ones specific in the go.mod file... that explains it I guess. I'll create a PR |
Starting with db6fec7 mirrorbits fails to build with: rpc/rpc.pb.go:1411:12: undefined: grpc.ClientConnInterface rpc/rpc.pb.go:1415:16: undefined: grpc.SupportPackageIsVersion6 rpc/rpc.pb.go:1442:10: undefined: grpc.ClientConnInterface rpc/rpc.pb.go:1445:27: undefined: grpc.ClientConnInterface This is due to the generated rpc/rpc.pb.go depending on a newer version of google.golang.org/grpc. This bumps the version to the next version that fixes the build, to keep the diff small. Fixes etix#172
Starting with db6fec7 mirrorbits fails to build with: rpc/rpc.pb.go:1411:12: undefined: grpc.ClientConnInterface rpc/rpc.pb.go:1415:16: undefined: grpc.SupportPackageIsVersion6 rpc/rpc.pb.go:1442:10: undefined: grpc.ClientConnInterface rpc/rpc.pb.go:1445:27: undefined: grpc.ClientConnInterface This is due to the generated rpc/rpc.pb.go depending on a newer version of google.golang.org/grpc. This bumps the version to the next minor version that fixes the build, to keep the diff small. Fixes etix#172
Thanks for looking into it |
There are multiple issues with the current automatic way: * By default it protoc-gen-go is updated when make it called which changes the dependencies to potentially incompatible versions * From what I understand "got get" in older versions also installed the binaries, but that is no longer the case, so it doesn't do anything anymore and PROTOC_GEN_GO is never created. Instead if will always fall back to the host protoc-gen-go * There are multiple protoc-gen-go versions that are incompatible, Debian for example ships 1.3 and 1.5 (default), while the .proto file is currently only compatible with 1.3 * If "got install" would be used, the makefile would never update it again if it existed in $(GOPATH)/bin already Since there are so many potential pitfalls with the current approach: * Never call protoc automatically during the build, create a phony rege-proto target in the makefile. * Use "go install" to install protoc-gen-go into $(GOPATH)/bin and pin the version to a compatible range. See etix#172
I've also created #175 to improve some things which confused me along the way. |
There are multiple issues with the current automatic way: * By default it protoc-gen-go is updated when make it called which changes the dependencies to potentially incompatible versions * From what I understand "go get" in older versions also installed the binaries, but that is no longer the case, so it doesn't do anything anymore and PROTOC_GEN_GO is never created. Instead if will always fall back to the host protoc-gen-go * There are multiple protoc-gen-go versions that are incompatible, Debian for example ships 1.3 and 1.5 (default), while the .proto file is currently only compatible with 1.3 * If "go install" would be used, the makefile would never update it again if it existed in $(GOPATH)/bin already Since there are so many potential pitfalls with the current approach: * Never call protoc automatically during the build, create a phony rege-proto target in the makefile. * Use "go install" to install protoc-gen-go into $(GOPATH)/bin and pin the version to a compatible range. See etix#172
There are multiple issues with the current automatic way: * By default it protoc-gen-go is updated when make is called which changes the dependencies to potentially incompatible versions * From what I understand "go get" in older versions also installed the binaries, but that is no longer the case, so it doesn't do anything anymore and PROTOC_GEN_GO is never created. Instead if will always fall back to the host protoc-gen-go * There are multiple protoc-gen-go versions that are incompatible, Debian for example ships 1.3 and 1.5 (default), while the .proto file is currently only compatible with 1.3 * If "go install" would be used, the makefile would never update it again if it existed in $(GOPATH)/bin already Since there are so many potential pitfalls with the current approach: * Never call protoc automatically during the build, create a phony regen-proto target in the makefile. * Use "go install" to install protoc-gen-go into $(GOPATH)/bin and pin the version to a compatible range. See etix#172
Starting with db6fec7 mirrorbits fails to build with: rpc/rpc.pb.go:1411:12: undefined: grpc.ClientConnInterface rpc/rpc.pb.go:1415:16: undefined: grpc.SupportPackageIsVersion6 rpc/rpc.pb.go:1442:10: undefined: grpc.ClientConnInterface rpc/rpc.pb.go:1445:27: undefined: grpc.ClientConnInterface This is due to the generated rpc/rpc.pb.go depending on a newer version of google.golang.org/grpc. This bumps the version to the next minor version that fixes the build, to keep the diff small. Fixes #172
There are multiple issues with the current automatic way: * By default it protoc-gen-go is updated when make is called which changes the dependencies to potentially incompatible versions * From what I understand "go get" in older versions also installed the binaries, but that is no longer the case, so it doesn't do anything anymore and PROTOC_GEN_GO is never created. Instead if will always fall back to the host protoc-gen-go * There are multiple protoc-gen-go versions that are incompatible, Debian for example ships 1.3 and 1.5 (default), while the .proto file is currently only compatible with 1.3 * If "go install" would be used, the makefile would never update it again if it existed in $(GOPATH)/bin already Since there are so many potential pitfalls with the current approach: * Never call protoc automatically during the build, create a phony regen-proto target in the makefile. * Use "go install" to install protoc-gen-go into $(GOPATH)/bin and pin the version to a compatible range. See #172
On Ubuntu 22.04 and 24.04:
db6fec7
@elboulangero do you have any ideas?
The text was updated successfully, but these errors were encountered: