【问题标题】:CGO ignores the LDFLAGS -L option on MacOSCGO 忽略 MacOS 上的 LDFLAGS -L 选项
【发布时间】:2018-12-19 08:30:28
【问题描述】:

我正在尝试在 MacOS 机器上编译以下代码

// #cgo darwin LDFLAGS: -L${SRCDIR}/build/darwin -lprocessing_lib
// #cgo linux LDFLAGS: -L${SRCDIR}/build/linux -lprocessing_lib
// #include "Processing-bridge.h"
// #include <stdlib.h>
import "C"
import "unsafe"

type ProcessorWrapper struct {
    ptr unsafe.Pointer
}

func init() {
    pr.ptr = C.NewProcessor()
}

func GetDefault() (id int, name string) {
    var default = C.GetDefault(pr.ptr)
    id = int(default.materialId)
    name = C.GoString(default.name)
    return
}

我在 LDFLAGS 中定义的正确位置有 libprocessing_lib.so 文件。但是编译器仍然会抛出一个错误说

dyld: Library not loaded: build/lib_processing_lib.so
  Referenced from: /Users/ag/workspace/src/github.com/apremalal/pq-processor/./pq-processor
  Reason: image not found

一旦我将 build/lib_processing_lib.so 复制到项目的根目录,它就可以工作了。

LDFLAGS 提供的库目录似乎被某种方式覆盖了。

我注意到在编译之前设置 DYLD_LIBRARY_PATH 变量也会覆盖这个值。(我在没有设置这个参数的情况下运行了上面的场景)

有趣的是,通过选择正确的路径,相同的代码可以在 Linux 环境中运行。

我需要在 MacOS 中做些什么才能获得理想的 LDFLAGS 行为吗?

【问题讨论】:

  • 尝试使用-x 标志运行go build,看看对C 编译器的调用是否确实使用了您期望的值。
  • 另外,您可能刚刚发现了一个错误。 This search 没有带来任何匹配的内容,因此您可以尝试提交问题。

标签: go gcc cgo


【解决方案1】:

设置动态库加载路径。mac设置DYLD_LIBRARY_PATH for linuxLD_LIBRARY_PATH

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2022-01-19
    • 1970-01-01
    • 2022-08-22
    • 2019-11-16
    • 1970-01-01
    • 2013-04-24
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多