問題タブ [cgo]

Go でガベージ コレクターを処理し、C コードを介して割り当てられたメモリを解放することは可能ですか? 申し訳ありませんが、私は以前に C と cgo を使用したことがないため、私の例には説明が必要な場合があります。

使用したい C ライブラリがあり、このライブラリが手動で解放する必要のあるメモリを割り当てているとします。私がやりたいことは次のようなものです：

Go ランタイムで *Stuff への参照がない場合、ガベージ コレクターが Stuff.Free() を呼び出す方法はありますか?

私はここで理にかなっていますか？

おそらく、より直接的な質問は次のとおりです。そのオブジェクトへの参照がゼロの場合にランタイムが呼び出す関数を作成することにより、ランタイムが C に割り当てられたメモリのクリーンアップを自動的に処理するようにすることは可能ですか?

Windows API を使用したいのですが、開始方法がわかりません。チュートリアルはありますか？

とにかく私は簡単なコードを持っています。これを正しく理解するのを手伝ってもらえますか?

編集: char* を扱うことはできますが、wchar_t* のことはまだわかりません。

これがイディオムでない場合はお知らせください。

私の最終的な目標は、Goパッケージから多数のDLL（opengl32.dll glfw.dllおよびglu32.dll）に正常にリンクすることですが、go-glfwパッケージにリンクしようとすると、「未定義」エラーが発生しました。

そこで、％GOROOT％\ misc \ cgo \ lifeの単純な変更されていない例から、非常に単純なcgo動的/共有ライブラリリンクを機能させることにしました。しかし、コマンドgo build -o life main.goを呼び出すだけで、本質的に同じリンカーエラーで失敗します。

「定義されていません」...上記のようにglfwをリンクしようとしたときに発生したのとまったく同じエラー。

これは改ざんされていない新しいものです。今朝新しくダウンロードされたGo1.0.1のインストールは、かなり最近のWin764ビットインストールです。何がうまくいかない可能性がありますか？私は知っています...ウィンドウズ。アイデアを聞きたいです...CGOとのDLLリンクは、私がネットで読んだことから簡単に実行できるようです。しかし、最も単純な例でさえ私には失敗します。

(非常に詳細な問題レポート -- tl;dr は一番下にあります!)

私は Glut よりも GLFW を本当に好み、そのGolang バインディングを Windows 64 ビットで Go 1.0.1 64 ビットで動作させたいと考えています。Linux では、バインディングは問題なく動作します。これは原則として Windows で実行可能です -- GitHub ユーザー chscはなんとか実行できましたが、彼は Win32 を使用しており、彼のヒントはまだ私の問題を解決していません。ただし、tdm64-gcc-4.6.1 に基づいて、完全でクリーンな Mingw64 をセットアップしています。

ここで奇妙なことに、freeglut バインディングを 64 ビット Windows で動作させると、64 ビット Go 1.0.1が動作します。glfw バインディングが失敗します。基本的に両方とも同じcgo機能とテクニックを使用しているため、理由を理解したいと思います。

注: 現在、自作の中途半端ではあるが基本的に動作する代替パッケージを用意しています。これは、LoadLibrary/GetProcAddress 呼び出しを使用して Go で glfw.dll を公開します。これは機能しますが、無数の Syscall()、Syscall6()、Syscall9()、Syscall12() などの Go func 呼び出しよりも、ハードリンクされたコンパイル済みの CGO バインディングの方が望ましいと思います。Win32 と Linux の gopher がこれを使用できるのであれば、なぜ私たち Win64 の人々はそうしないのでしょうか?

これまでの私のセットアップは次のとおりです。

1. cgoを適用してlibリンクを機能させるための3つのパッチを備えたGolangビルドがあります
2. MinGW64 を使用して、最新の freeglut および GLFW ライブラリを 64 ビット DLL としてコンパイルすることに成功しました。
3. ヘッダー ファイル glut.h、freeglut*.h、および glfw.h は、\MinGW64\x86_64-w64-mingw32\include\GL に配置されます (gl.h、glaux.h、glu.h の隣)。
4. lib ファイル libfreeglut.a および libglfwdll.a は、\MinGW64\x86_64-w64-mingw32\lib に配置されます (libglu32.a、libopengl32.a の隣)。
5. 64 ビット DLL glfw.dll および freeglut64.dll は、\windows および \windows\system32 (opengl32.dll、glu32.dll の隣) に配置されます。
6. freeglut64.dll と glfw.dllはどちらも動作すると思います。少なくとも、サンプル プログラムのほとんどは、DLL をインストールした後に動作します。

すべてが整っているはずですよね？まず、バインドの成功 (これは必要ありません) である freeglut -- -x github.com/zombiezen/Go-GLUT/glut を取得すると、すべてが正常にビルドされ、glut ウィンドウを正常に作成できます。 .go ソース ファイルからコンパイルされた Windows test.exe で三角形を表示します。-x のおかげで、go get が何をビルドするかを表示します:

この点に到達するには、次のように glut.go をわずかに変更する必要がありました。

要約すると、これは問題なくビルドでき、Go からインポートしてリンクし、コードで使用できます。

さてGLFWです。GO ファイルは、glut.go と非常によく似ています。

#define GLFW_DLL は、静的リンクが発生しないようにするためのものです。ただし、 go get -x github.com/jteeuwen/glfwの出力は次のとおりです。

はい、それは一口です-しかし、基本的に常に同じエラーであり、ビルド手順のかなり遅い段階です。#define GLFW_DLL が定義されていない場合、__imp_ プレフィックスがないことを除いて、本質的に同じ出力が得られることに注意してください。また、静的リンクは Go では奨励されておらず、この特定のユースケースでは望ましいものでもありません。

さて、gccが「未定義の参照」について不平を言うとき、私がグーグルで調べたところ、さまざまな理由が考えられます...

• DLL を見つけるのに失敗することはありません。DLL は適切な場所にあり、freeglut64.dll では機能します。
• .a ライブラリを見つけるのに失敗することはありません-それらは適切な場所にあり、libfreeglut.a は機能します.-lglfwdll を -lblafoobar に変更すると、gcc ははるかに早く失敗し、正しく「blafoobar が見つかりません」と不平を言います-そのため、libglfwdll.aが見つかります。
• lib依存関係の順序? -lglfwdll を最初の lib (-lglu32 -lopengl32 の前) として、最後 (これら 2 つの後) として試しましたが、違いはありませんでした。
• Golang glfw バインディングに問題がありますか? そうは思わないでください、chsc用のWindows（32ビットですが）を含む他の人でも機能します

TL;DR -- Windows 64 ビット、Go 1.0.1 64 ビットに完全にパッチが適用されている場合、CGOはfreeglut と glfwの両方で GCC にフィードするものを正常に生成します。次に、GCC は喜んでそれらを食べて freeglut バインディングを構築しますが、glfw バインディングを構築するためにそれを拒否し、すべての C.funcs() に対して「未定義の参照」を使用します。libfreeglut と libglfwdll の両方が正しくビルドされ、64 ビット DLL としてインストールされ、.h/.a ライブラリが正しく配置されます。原因は何ですか？

かなり単純なローカル CGO プロジェクトの構築に問題があります。たった 3 つのファイル (glut.go、support.c、および support.h ファイル) からなるこの非常に小さな CGO パッケージについて考えてみましょう。

次に、いくつかの秘密の魔法が発生し、go getは次の出力ファイルをビルドします。

ただし、3 つのソース ファイルを \mytmp にコピーし、\mytmp に cd してbuild -o glut.a glut.goを実行すると、次のような 40-60 エラー メッセージが表示されます。

-xコマンドライン引数を指定してgo getを実行すると、ビルド プロセス中にsupport.cが取得され、gcc に渡されることがわかります。

ただし、go build -xでは、これは当てはまりません。support.c はスキップされます。なんで？go get とまったく同じようにgo buildを呼び出すにはどうすればよいですか?

Goで書かれたこの非常にシンプルな小さなテストケースOpenGLプログラムを見てください。

これは、Go1.0.164ビットを使用するWindows764ビットで正常にビルドされます。

また、 gl.Clear （gl.COLOR_BUFFER_BIT）行を削除（またはコメントアウト）すると、正常に機能します（OpenGLは、ウィンドウが閉じるまで単一の虹色の2D三角形を描画します） 。

ただし、gl.Clearが呼び出されると（どの引数が渡されても）、クラッシュし、Windowsから「glfw-win.exeが動作を停止しました...」と通知され、Windowsイベントビューアに次のエラーログが表示されます。 ：

さて、注目すべき点がいくつかあります...

1. glfwパッケージは、github.com / jteeuwen / glfwとまったく同じAPIを公開する単なるカスタムパッケージですが、コンパイル時のCGO / GCC/LDリンクではなくglfw.dllを使用するためにLoadLibrary/GetProcAddressを内部的に使用します。悲しいことに、64ビットWindowsで動作するように作られていますが、mingw64、gcc、cgoのいずれが原因かはわかりません。LoadLibrary / GetProcAddressを呼び出すと、glfw.dllのカスタム64ビットビルドが非常にうまく機能します。明らかに、ここでの問題は、glfwではなくglパッケージの呼び出しにあります。

2. glパッケージは、実際にはこれだけで、変更されていません。-m64 -lmingw32 -Wl、/ windows / opengl32.dllなどのいくつかのLDFLAGSの変更を試しましたが、違いはありません。gl.Clear（）が呼び出されない限り、元の変更は変更されたものと同じように機能します。そのため、元に戻しました。もちろん、後でOpenGL4.2に移ります。

3. Process Explorerを使用すると、プロセスが64ビットであり、ロードされたすべてのDLLも64ビットイメージ（opengl32.dllおよびglfw.dllを含む）であることがわかります。

4. 「gl21パッケージがopengl32.dllによってエクスポートされたglClear（）関数の有効なアドレスを取得できなかった可能性がありますか？」-ありそうもない：2926行目によると、この場合、gl.Init（）の呼び出しは失敗します。

5. GPUドライバーの問題？さらにありそうもない。最新の公式nVidiaQuadro5010Mドライバー296.35がインストールされています。「パフォーマンスドライバー」も試してみましたが、とにかくまったく同じドライバーのようです。nVidiaコントロールパネルによるOpenGL4.2の完全サポート（opengl32.dllの日付は2009年ですが、とにかく、現在ターゲットにしている2.1には十分です）。さらに、「Geeks3D GPU CapsViewer」および「ShaderToyMark」のOpenGLシェーダーは、GLFWサンプルプログラムparticles.exeと同様に実行されます。これらはすべて、glClear（）も使用します。

6. gl21の代わりにgl42を使用した場合もまったく同じ問題が発生するため、それも原因ではありません。

この例では、他のすべてのgl.SomeExportedFunc（）呼び出しがクラッシュしないことに注意してください...

何をすべきか、どのように進めるか？

これがgl.Clear（）でのみ発生し、他の機能がこれまでにない場合、これで生きることができます-とにかくカスタムコンテンツでフルスクリーンクワッドをレンダリングするだけです-しかし、ここでWin64をテストするのはかなり早いです（多くのgl42コードはLinux64で問題なく動作し、Win64に「移植」されようとしています）。後でさらに呼び出しを行うと同じ問題が発生するのではないかと心配しているので、今報告します。これによって影響を受ける他の呼び出しはすぐにわかります。

CGoforENetを使用してGoラッパーを作成しようとしています。

Macでラッパーをコンパイルしようとすると、ライブラリが古くなり、インターフェイスが少し異なります。コードの99％は同じですが、いくつかのC呼び出しを変更する必要があります。

Goでこのような問題に対処するためのベストプラクティスは何ですか？
条件付きコンパイルまたは条件付きインポートを行う方法はありますか？

Go を使用して Android ゲームを作成することはできますか? 私は、件名で言及されているテクノロジーに執着していません。Go でいくつかの Android プログラムを作成した人がいることは知っていますが、それらはヘッドレスだった可能性があります。

cgo を使用しようとすると、エラーが発生します

exec gcc: exec: "gcc": %PATH% に実行可能ファイルが見つかりません

Mingwをインストールしました。gcc の場所を Goclipse に伝えるにはどうすればよいですか? 設定またはプロパティでこれを設定する方法が見つかりませんでした。

cgoでいくつかのC++コードを混在させることは可能ですか？

私はこれを試しました：

しかし、私はこれらのエラーを受け取ります：

go1.0.2とMinGW-w644.7.1を使用しています