I'm trying to build postfix-exporter code from the github link.
It has a dependency on the go-systemd package as mentioned in go.mod file github.com/coreos/go-systemd/v22 v22.0.0.
I see in the go.mod file , the mentioned version for the package is v22.0.0.
But when I run go get -u for this path, it starts downloading the latest version ( v22.2.0) of go-systemd which has an issue in the latest commit and causing failure to compile .
The error coming in that is
github.com/coreos/go-systemd/v22#v22.2.0/sdjournal/journal.go:313:60: error: '_SD_ARRAY_STATIC' undeclared here (not in a function) // my_sd_id128_to_string(void *f, sd_id128_t boot_id, char s[_SD_ARRAY_STATIC SD_ID128_STRING_MAX]) ^ In file included from /usr/include/systemd/sd-journal.h:31:0, from pkg/mod/github.com/coreos/go-systemd/v22#v22.2.0/sdjournal/journal.go:27: pkg/mod/github.com/coreos/go-systemd/v22#v22.2.0/sdjournal/journal.go:313:77: error: expected ']' before numeric constant // my_sd_id128_to_string(void *f, sd_id128_t boot_id, char s[_SD_ARRAY_STATIC SD_ID128_STRING_MAX])
I want to know , how to compile for a specific version of any dependency module if this is not the way or I'm missing some option required to honor the version of dependency packages mentioned in go.mod
Thanks very much in advance and please pardon my golang knowledge.
Don't use -u. The purpose of -u is to allow Go to try to upgrade you to the latest minor or patch version:
The -u flag instructs get to update modules providing dependencies
of packages named on the command line to use newer minor or patch
releases when available.
If you're just trying to install dependencies, use go get.
I was trying to build podman for Centos7 and found this error, noticed that _SD_ARRAY_STATIC was not defined, so I just did a search in google and found this header file: https://code.woboq.org/qt5/include/systemd/_sd-common.h.html.
Also, by doing a search of this file in my docker I found this very old one: /usr/include/systemd/_sd-common.h, so I just decided to modify it and add that definition:
/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
#ifndef foosdcommonhfoo
#define foosdcommonhfoo
/***
This file is part of systemd.
Copyright 2013 Lennart Poettering
...
...
#ifndef _SD_END_DECLARATIONS
# ifdef __cplusplus
# define _SD_END_DECLARATIONS \
} \
struct __useless_struct_to_allow_trailing_semicolon__
# else
# define _SD_END_DECLARATIONS \
struct __useless_struct_to_allow_trailing_semicolon__
# endif
#endif
#ifndef _SD_ARRAY_STATIC
# if __STDC_VERSION__ >= 199901L
# define _SD_ARRAY_STATIC static
# else
# define _SD_ARRAY_STATIC
# endif
#endif
#endif
And voila, got it working.
TL;DR, probably you have to update systemd package or at least the systemd C library.
Related
I am working in a project using some proto sources that are already compiled using a specific version, I also need to compile some custom protos that are cohabiting in the same project, so the protoc needs to match the one that was used to generate the other ones.
I can see in the pre-generated ones:
#if PROTOBUF_VERSION < 3009000
#if 3009002 < PROTOBUF_MIN_PROTOC_VERSION
In mines:
#if PROTOBUF_VERSION < 3017000
#if 3017000 < PROTOBUF_MIN_PROTOC_VERSION
I don't quite understand which protoc is being used, the one installed on my system is 3.19.4.
Also this is my WORKSPACE:
http_archive(
name = "rules_proto",
sha256 = "66bfdf8782796239d3875d37e7de19b1d94301e8972b3cbd2446b332429b4df1",
strip_prefix = "rules_proto-4.0.0",
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/rules_proto/archive/refs/tags/4.0.0.tar.gz",
"https://github.com/bazelbuild/rules_proto/archive/refs/tags/4.0.0.tar.gz",
],
)
load("#rules_proto//proto:repositories.bzl", "rules_proto_dependencies", "rules_proto_toolchains")
rules_proto_dependencies()
rules_proto_toolchains()
http_archive(
name = "com_github_grpc_grpc",
urls = [
"https://github.com/grpc/grpc/archive/refs/tags/v1.44.0.tar.gz",
],
sha256 = "8c05641b9f91cbc92f51cc4a5b3a226788d7a63f20af4ca7aaca50d92cc94a0d",
strip_prefix = "grpc-1.44.0",
)
load("#com_github_grpc_grpc//bazel:grpc_deps.bzl", "grpc_deps")
grpc_deps()
load("#com_github_grpc_grpc//bazel:grpc_extra_deps.bzl", "grpc_extra_deps")
grpc_extra_deps()
The error I am currently getting is:
In file included from cc/tensorflow/plugin_primeclient/grappler/grappler.cc:7:
bazel-out/aarch64-fastbuild/bin/cc/tensorflow/plugin/protos/graph.pb.h:12:2: error: #error This file was generated by a newer version of protoc which is
12 | #error This file was generated by a newer version of protoc which is
| ^~~~~
bazel-out/aarch64-fastbuild/bin/cc/tensorflow/plugin/protos/graph.pb.h:13:2: error: #error incompatible with your Protocol Buffer headers. Please update
13 | #error incompatible with your Protocol Buffer headers. Please update
| ^~~~~
bazel-out/aarch64-fastbuild/bin/cc/tensorflow/plugin/protos/graph.pb.h:14:2: error: #error your headers.
14 | #error your headers.
| ^~~~~
I'll try and describe the general process I take when tracking dependency problems down in Bazel, as it seems to be a regular problem that you'll probably run into again.
Before Bazel does anything to do with the build it's going to look in your WORKSPACE file to see if it needs to fetch any dependencies. It might not seem like an important detail, but Bazel handles WORKSPACE dependencies from top to bottom. We can use this behaviour to override the protobuf version used. Checkout the maybe macro if your interested in how this works.
So in your WORKSPACE file, the first dependency that you have is 'rules_proto' # version 4.0.0 with the http_archive. Then you are loading two macros from 'rules_proto' here;
load("#rules_proto//proto:repositories.bzl", "rules_proto_dependencies", "rules_proto_toolchains")
rules_proto_dependencies()
rules_proto_toolchains()
So first things first let's head over to the rules_proto releases page and find your specific release. Then click on the little hash on that page (circled in red).
Then click "browse files" in the top right;
This will allow you to browse the state of that repository at that specific version. Now as you loaded "repositories.bzl" you'll want to open that up and inspect it (ctrl-F search for protobuf). You'll find that it calls another private macro i.e.
protobuf_workspace(name = "com_google_protobuf")
If we look for where that macro was loaded you'll see that you'll need to follow that through to the 'proto/private/dependencies.bzl';
load("//proto/private:dependencies.bzl", "dependencies", "maven_dependencies", "protobuf_workspace")
After opening that up and searching again for protobuf you'll find the line that specifies the protobuf version;
"com_github_protocolbuffers_protobuf": {
#...
},
So by the looks of it you are using an older version of protobuf with Bazel than what is installed on your system. So in order to override the protobuf version in Bazel you need to simply add it as a dependency in your WORKSPACE before the rules_proto repository. e.g.
# file: //:WORKSPACE
http_archive(
name = "com_github_protocolbuffers_protobuf",
# TODO: Leave this empty and Bazel will tell you what to put here when you build.
sha256 = "",
# Note: Same version as your system deps.
strip_prefix = "protobuf-3.19.4",
urls = [
# Note: Same version as your system deps.
"https://github.com/protocolbuffers/protobuf/releases/download/v3.19.4/protobuf-all-3.19.4.tar.gz"
],
)
http_archive(
name = "rules_proto",
# The rest of the WORKSPACE...
I am a newbie in go and go-swagger. I am following steps in Simple Server tutorial in goswagger.io.
I am using Ubuntu 18.04, swagger v0.25.0 and go 1.15.6.
Following the same steps, there are a few differences of the files generated. For instance, goswagger.io's has find_todos_okbody.go and get_okbody.go in models but mine does not. Why is that so?
Link to screenshot of my generated files vs
Link to screenshot of generated files by swagger.io
Starting the server as written in the tutorial go install ./cmd/todo-list-server/ gives me the following error. Can anyone please help with this?
# my_folder/swagger-todo-list/restapi
restapi/configure_todo_list.go:41:8: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
restapi/configure_todo_list.go:42:6: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
The first step in goswagger.io todo-list is swagger init spec .... Which directory should I run this command in? I ran it in a newly created folder in my home directory. However, from the page, it shows the path to be ~/go/src/github.com/go-swagger/go-swagger/examples/tutorials/todo-list. I am not sure whether I should use go get ..., git clone ... or create those folders. Can someone advise me?
Thanks.
This is likely the documentation lagging behind the version of the code that you are running. As long as it compiles, the specific files the tool generates isn't so crucial.
This is a compilation error. When you do go install foo it will try to build the foo package as an executable and then move that to your GOPATH/bin directory. It seems that the generated code in restapi/configure_todo_list.go isn't correct for the operations code generated.
All you need to run this tutorial yourself is an empty directory and the swagger tool (not its source code). You run the commands from the root of this empty project. In order not to run into GOPATH problems I would initialise a module with go mod init todo-list-example before doing anything else.
Note that while the todo-list example code exists inside the go-swagger source, it's there just for documenting example usage and output.
What I would advice for #2 is to make sure you're using a properly released version of go-swagger, rather than installing from the latest commit (which happens when you just do a go get), as I have found that to be occasionally unstable.
Next, re-generate the entire server, but make sure you also regenerate restapi/configure_todo_list.go by passing --regenerate-configureapi to your swagger generate call. This file isn't always refreshed because you're meant to modify it to configure your app, and if you changed versions of the tool it may be different and incompatible.
If after that you still get the compilation error, it may be worth submitting a bug report at https://github.com/go-swagger/go-swagger/issues.
Thanks #EzequielMuns. The errors in #2 went away after I ran go get - u -f ./... as stated in
...
For this generation to compile you need to have some packages in your GOPATH:
* github.com/go-openapi/runtime
* github.com/jessevdk/go-flags
You can get these now with: go get -u -f ./...
I think it's an error of swagger code generation. You can do as folloing to fix this:
delete file configure_todo_list.go;
regenerate code.
# swagger generate server -A todo-list -f ./swagger.yml
Then, you can run command go install ./cmd/todo-list-server/, it will succeed.
I'm running into an issue with a library I made that I want to include in multiple projects
# github.com/pcs-services/message-queue-operator/pkg/controller/messagequeue
pkg/controller/messagequeue/messagequeue_controller.go:167:129: cannot use instance.ObjectMeta.GetUID() (type "github.com/pcs-services/message-queue-operator/vendor/k8s.io/apimachinery/pkg/types".UID) as type "github.com/pcs-services/grafana/vendor/k8s.io/apimachinery/pkg/types".UID in argument to grafana.DeployGrafana
The files are the same in the main project to the
$ md5 k8s.io/apimachinery/pkg/types/uid.go
MD5 (k8s.io/apimachinery/pkg/types/uid.go) = cc286eae550982db7f93c079e0df1f52
$ md5 k8s.io/apimachinery/pkg/types/uid.go
MD5 (k8s.io/apimachinery/pkg/types/uid.go) = cc286eae550982db7f93c079e0df1f52
k8s.io/apimachinery is vendored in the main app but not the library.
The error says:
pkg/controller/messagequeue/messagequeue_controller.go:167:129:
cannot use instance.ObjectMeta.GetUID() (type
"github.com/pcs-services/message-queue-operator/vendor/k8s.io/apimachinery/pkg/types".UID)
as type
"github.com/pcs-services/grafana/vendor/k8s.io/apimachinery/pkg/types".UID
in argument to grafana.DeployGrafana
So, you're using github.com/pcs-services/grafana/vendor/k8s.io/apimachinery/pkg/types.UID but imported github.com/pcs-services/message-queue-operator/vendor/k8s.io/apimachinery/pkg/types.UID. Check your imports and possibly run dep ensure (if you're using dep) to copy the correct dependencies to your vendor folder.
I have just started playing with google proto. When I try to compile proto file present in proto-java example, it does not generate any grpc file.
proto file,
https://github.com/grpc/grpc-java/blob/master/examples/src/main/proto/hello_world.proto
terminal output,
rsonkhla#raman-OptiPlex-9020:~/sandbox/grpc-java/examples$ protoc
--version libprotoc 3.0.0 rsonkhla#raman-OptiPlex-9020:~/sandbox/grpc-java/examples$ protoc
--java_out=test/ -I../../grpc-java/examples ../../grpc-java/examples/src/main/proto/hello_world.proto
rsonkhla#raman-OptiPlex-9020:~/sandbox/grpc-java/examples$ ls -R test/
test/: io
test/io: grpc
test/io/grpc: examples
test/io/grpc/examples: helloworld
test/io/grpc/examples/helloworld: HelloRequest.java
HelloResponse.java HelloWorldProto.java
HelloRequestOrBuilder.java HelloResponseOrBuilder.java
Has anybody else faced this issue?
The command line you are showing does not enable the grpc plugin. You need to specify an _out argument for the grpc plugin, which enables the plugin and specifies where it should output files. Since the plugin is likely not in your PATH, you also need to tell protoc how to find the plugin with --plugin.
So you need to add two arguments:
--plugin=protoc-gen-grpc-java=path/to/protoc-gen-grpc-java --grpc-java_out=path/to/output/dir
For more info, see the gRPC compiler documentation.
You can add these option to your .proto (base on your language) to generate abstract services:
option cc_generic_services = true;
option java_generic_services = true;
option py_generic_services = true;
You can also add --plugin=EXECUTABLE option in your protoc cmd to use custom code generator plugin to generate code more specific to each system, rather than rely on the "abstract" services. Just like Eric's suggestion.
I am trying to compile a third party code which uses apt-pkg. The error is
/usr/include/apt-pkg/depcache.h:188: error: ‘regex_t’ was not declared in this scope
I've verified that regex.h exists at /usr/include/regex.h
I am using ubuntu 10.4 64 bit to compile code.
what could be wrong?
You need to include regex.h in depcache.h before you use regex_t, or include it in whatever code includes depcache.h, before you include depcache.h.
Or perhaps there is an #ifdef that is set incorrectly for your environment and that is blocking the include of regex.h.