英文:
Depending on godror from Bazel builds with rules_go and CGO to access Oracle from your app or service
问题
这是一个我找到答案的问题。我将其添加到SO上,因为它可能对其他人有用。如果有更好的回答,我会很乐意接受!
我正在构建一些需要与Oracle通信的Go服务,使用Bazel作为构建系统,与官方的rules_go
一起使用。这个问题似乎是由于在依赖于godror时构建失败导致的:
external/com_github_godror_godror/conn.go:10:10: fatal error: 'dpiImpl.h' file not found
#include "dpiImpl.h"
这似乎是因为当通过go build
调用时,gazelle
无法复制CGO默认情况下的所有魔法/隐式操作,我想知道是否有办法使用Bazel正确构建该库。
由于似乎没有适用于Oracle的独立Go客户端,唯一的解决方法是让它与CGO一起工作。
英文:
<sub>This is a question for which I found the answer. I'm adding it to SO as it might be useful for others. If there is a better reply I'll be glad to accept it!</sub>
I'm building some Go services that need to talk to Oracle, using Bazel as the build system in conjunction with the official rules_go
. The best library for this seems to be godror, but when attempting to depend on it, the build fails with:
external/com_github_godror_godror/conn.go:10:10: fatal error: 'dpiImpl.h' file not found
#include "dpiImpl.h"
This seems to be due to the fact that gazelle
does not replicate all the magic/implicit things CGO does out of the box when invoked via go build
, and I'm left to wonder if/how there is a way to properly build that library with Bazel.
As there does not seem to be a proper standalone Go client for Oracle, the only way forward is to get this to work with CGO.
答案1
得分: 0
在对生成的 BUILD.bazel
文件进行一些试验后,我找到了一个表面上似乎有效的解决方法[1][2]。它涉及从子目录添加 C 源文件和头文件,以及修补一个 C 文件。
详细信息请参见此 gist。
请注意,如果不修补 C 文件(并在 go_library
定义中包含相关的 dpi.c
文件),构建过程将失败,并显示以下错误信息:
duplicate symbol 'dpiVar_getReturnedData' in:
/var/folders/8y/pztgykk94_q4j7fnmjhnbnw0001t4q/T/rules_go_work-940074786/_x3.o
/var/folders/8y/pztgykk94_q4j7fnmjhnbnw0001t4q/T/rules_go_work-940074786/_x43.o
ld: 1164 duplicate symbols for architecture x86_64
我猜这里需要用适当的标志替换 go build
通过 CGO 实现的一些魔法,但至少通过替代方法可以正常工作。
值得一提的是,这个探索主要在 OS X 上进行,而使用在 Linux 系统上构建的二进制文件进行测试。
对于对 godror 具体情况感兴趣的人,这是 相关问题。
[2]: 奇怪的是,这个解决方法使得无法对源代码进行 go install
。如果有 C/CGO 专家知道原因,我很想了解为什么 - 哦,顺便说一下,我是一个完全的 C/CGO 新手,所以如果问题很明显,请原谅。
英文:
After a bit of playing around with the generated BUILD.bazel
file, I found a workaround that seems to be working at least superficially[1][2]. It involves adding C sources and headers from a subdirectory, as well as patching a C file.
See this gist for details.
Note that not patching the C file (and including the relevant dpi.c
file in the go_library
definition) will cause the build to fail with things along:
duplicate symbol '_dpiVar_getReturnedData' in:
/var/folders/8y/pztgykk94_q4j7fnmjhnbnw0001t4q/T/rules_go_work-940074786/_x3.o
/var/folders/8y/pztgykk94_q4j7fnmjhnbnw0001t4q/T/rules_go_work-940074786/_x43.o
ld: 1164 duplicate symbols for architecture x86_64
Here I guess some of the CGO magic that happens via go build
needs to be replaced by the proper flags, but at least things work with the substitution.
For the record, the exploration was mostly done on OS X while things were tested using binaries built on a Linux box.
For anyone interested in the godror specifics here is the relevant issue.
1: As in works for basic queries and not yet Tried out every functionality in a production setting, so YMMV.
[2]: Oddly enough, the workaround makes it impossible to go install
the sources. If a C/CGO expert has a clue I'd be curious to understand why – oh, by the way, I'm a total C/CGO newbie, so sorry if the problem is obvious.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论