問題タブ [cgo]

これを行うためのさまざまな方法を見てきましたが、多くのラッパーとコールバックを使用する必要があるという点で理想的な方法はありません。これを行う簡単な方法はありますか？

たとえば、次のようになります。

これは最小限に抑えられており、この時点でできることはSayFive、C でその関数を呼び出すことだけです。

ただし、このファイルの先頭にはありません。それができるのは非常にシンプルで便利ですが、私は次のような方法を探しています:

上記のような例を見てきましたが、#include "_cgo_export.h"それは完全に理にかなっていますが、それを実行してコンパイルしようとすると失敗します。

これを可能にするプロセス全体を説明できる人はいますか?

編集：この質問は意味がありません。コミットの日付を読み間違えました。これは既存のバージョンの Go ツールに含まれています。ありがとう、ジェームズ！

Go (1.3) の今後のリリースでは、Go以外のスレッドが CGO コールバックを呼び出すことができるようになるようです。

これまで、この制限を回避するために人々は通常何をしてきたのだろうかと思います。

つまり、スレッドを独自に作成するサードパーティのライブラリがあり、それらのスレッドから Go コードに情報を取得したいと考えています。

コードの「C」側のCスレッドからGoスレッドへのある種のハンドオフメカニズム? Goを呼び出さずにメッセージをキューに入れる方法はありますか? 他のアイデア？

cgo を使用して C から sqlite3 を使用しようとしています (go には sqlite3 ラッパーがあることは知っていますが、この方法を試してみたいと思います)。このプログラムはエラーメッセージを表示します

、理由がわかりません - 新しいデータベースストリームを開く方法を理解するのを手伝ってもらえますか?

}

引数で何かを行うGo関数が渡されたとします。たとえば、C部分に割り当てられたバッファを埋め、それを変更し、たとえば、読み取りデータのサイズである整数引数を変更できます。 . 整数ではうまく機能しますが、「データ部分」では機能しません。コードを見てください。

その結果、次のようになりました。

ご覧のとおり、整数ポインターではうまく機能しますが、uint8_t では機能しません。

Go 1.3 を使用して darwin/amd64 MBP で cgo コードを linux/arm にクロスコンパイルしようとしましたが、うまくいきませんでした :(

私の環境：

go version go1.3 darwin/amd64

私の目標：

Linux/arm を対象とする cgo コードのクロス コンパイル。

ステップ1：

ct-ng を使用して gcc/g++ クロス コンパイラをビルドします。arm-unknown-linux-gnueabi-g++とを構築するのは長い道のりでしたが、arm-unknown-linux-gnueabi-gccようやく実現しました。簡単な C/C++ プログラムでテストしたところ、出力は私の linux/arm R-Pi ボックスで問題なく動作しました。

ステップ2：

cd /path/to/go/src

sudo CGO_ENABLED=1 CC_FOR_TARGET=/path/to/arm-unknown-linux-gnueabi-gcc CXX_FOR_TARGET=/path/to/arm-unknown-linux-gnueabi-g++ GOOS=linux GOARCH=arm ./make.bash

すべてが正常に構築されました。

ステップ 3:

次の単純な cgo コードをコンパイルします。

私のホスト マシンの場合:

go install package/of/test

で失敗しました

arm-unknown-linux-gnueabi-gcc: error: unrecognized command line option '-m64'

Linux/アームの場合:

GOOS=linux GOARCH=arm go install package/of/test

で失敗しました

runtime.main: 外部関数の呼び出し main.main runtime.main:

未定義: main.main

何か案が？ありがとう。

C++ OpenImageIOライブラリ ( OpenImageiGO ) のバインディングを提供する Go ライブラリがあります。libOpenImageIO への標準の動的リンクを介してバインディングを喜んで構築してきましたが、現在は静的にリンクしようとしています。どのフラグの組み合わせを試しても、外部リンカが大量の「未定義参照」エラーで失敗するという問題が発生しています。リンカがシンボルを参照する順序に関して問題があったと言って、過去にこの問題が提起されたことを思い出したようです。しかし、私はこの情報を再び見つけることができないようです。

これは私の最新のビルド試行の簡単な例で、boost、OpenColorIO、および OpenImageIO の静的ビルドとリンクするように試みています。

そして、これは非常に長い出力だったので、厳選されたエラーの一部を以下に示します。

OpenImageIO は OpenColorIO の参照を見つけられないようです。そして、OpenImageIO はブーストの参照を見つけることができないようです。リンク中に物事が起こっている順序では、OpenColorIO またはブースト シンボルを OpenImageIO で使用できないように見えるため、多数のシンボル エラーが発生します。

ビルドプロセスで修正できる単純で愚かなことをしていることを願っています。しかし、外部ライブラリとの cgo の静的リンクは、デフォルトの動的リンクのアプローチよりも少し複雑に見えます。

更新 #1

@james-henstridge の答えは正しかったので、最後のしゃっくりを除いて、私はほぼ完全に構築されています。正しい順序を持っているように見えますがyaml-cpp、 が必要とするの参照に失敗しています。OpenColorIO

これが私の最新の環境です。ここでは、追加する必要のあるすべての明示的な静的ライブラリを処理しました。

アップデート #2

アップデート #1 は気にしないでください。OpenColorIOそれは一般的な問題ではなく、特に関連していました。

そのため、xxhash をcgoの使用から Go のネイティブ 9p C に移植していますが、かなり奇妙な問題が発生しています。

ハッシュ関数は、cgo 関数として呼び出された場合は問題なく動作しますが、「ネイティブ」バージョンを使用しようとすると、間違ったハッシュが返されます。

私はそれを機能させるのに十分な C を知っていますが、問題を報告する前に、私が何か間違ったことをしていないことを確認したいと思います。

要旨

xxhash.go:

xxhash_9p.c:

走る：

TL;DR:

AC 関数は、Go の 6c を介して使用すると間違った値を返し、CGO を介して呼び出すと、同じ正確な C 関数が正しい値を返します。

//編集

この問題について回答がありましたが、修正されることはなく、最終的に 9p ツールチェーンはなくなります。

mi...@golang.orgから:

Cコンパイラは最終的になくなります。そのための計画を立てるので、それに頼らないでください。

Plan 9 C コンパイラは ANSI に完全に準拠していないことに注意してください。バグを修正する予定はありません (コンパイラとその入力の両方を制御しているため、バグを回避するだけです)。