2

I'm new to CGO and am trying to use the library https://github.com/goccy/go-graphviz. I am trying to compile using Gazelle and Bazel, however, when I run Bazel build I get a huge number of build errors that make me wonder how the project is able to build for anyone else. I previously was running into some errors due to Gazelle not being able to find the config.h file in the "internal" folder. I solved that with a Gazelle patch that copied the config.h file to the "internal/ccall" folder and added some other header files as a src in the BUILD.bazel file, and now am facing these errors. They may be related, but I don't think they are since these errors look legitimate to me.

See a sample of the errors below. There are 20 of these errors:

I checked the files both in my local cache and in Github and the errors look legitimate. The agnxtedge function does have 3 input parameters and the Agnode_s struct doesn't have any member named 'in' or 'out'.

Am I crazy here or is there something weird happening? I haven't used C in 10 years or so, but I don't remember there being optional function parameters or anything.

I'm confused about how this library works for anyone given these (seeming) errors in the code, but I can't imagine the developer would release a version so obviously broken, so I have to think there's something weird going on here.

NumberOneRobot
  • 1,691
  • 6
  • 17
  • 23
  • I have not used Bazel, but the first thing I would do is try and build the project using the default toolchain and rule out if it's a build system problem or not. – JimB Jun 29 '23 at 18:09
  • I am able to run go build successfully to build the go-graphviz package. How would a build system enable what looks like legitimate issues be built successfully? For instance, how would a build system let a function call with only two parameters work for a function defined with three parameters if C doesn't allow optional parameters? – NumberOneRobot Jun 29 '23 at 18:53
  • If you can build your entire project with `go build`, then it's definitely a Bazel issue. I know that Bazel departs significantly from the normal `go` toolchain, so I'm not sure where to start. CGO is quite complicated because it relies on a lot of built-in conventions, and the generation of code and external compiler and linker commands on the fly, which leaves a lot of room for a 3rd party build tool to diverge in behavior. The only way I know to start debugging that would be to look at the detailed Bazel output and compare it with the `-x` output from the `go` tools. – JimB Jun 29 '23 at 19:08

0 Answers0