Go: cmd / link：msvcオブジェクトファイルをサポート

/ cc @alexbrainman

@xoviatあなたが抱えている問題は何ですか？ ここで再現できる必要があります。 したがって、これを再現するために従う必要のあるすべての手順を提供してください。

ありがとうございました

アレックス

PS：私は7月末までコンピューターを持っていません。 それではこれを見ていきます。

あなたが抱えている問題は何ですか？

まだ試していませんが、msvcオブジェクトファイルのc関数を.sysoとしてgoリンカーでリンクすることにより、具体的に呼び出したいと思います。 私が読んだすべてのことは、これが不可能であることを示していますが、発生した特定のエラーを再現するための手順を作成します。

具体的には、msvcオブジェクトファイルのc関数を.sysoとしてgoリンカーでリンクして呼び出します。

これらをDLLに組み込んで、DLL内から使用してみましたか？

発生した特定のエラーを再現する手順を作成します。

してください。 ありがとうございました。

アレックス

これらをDLLに組み込んで、DLL内から使用してみましたか？

それが私の当初の計画でした。 私はswigを使用しているので、生成されたcコードを個別にコンパイルしてから、DLLエクスポートとして関数を書き直すのはあまり便利ではありません。 難しいことではありませんが、gccを使用したワークフローがgo generate; go buildだけの場合は面倒です。

了解しました。手順があります。 これらのファイルから始めます。

hello.go：

package main

/*
    extern void hello();
*/
import "C"

func main() {
    C.hello()
}

こんにちはC：

#include <stdio.h>

extern void hello()
{
    printf("Hello World from C");
}

次に、次のコマンドを実行します（パスにmsvcを使用）。

cl /c hello.c
mv hello.obj hello.syso
mv hello.c hello.c.bak
go build

結果：
Warning: corrupt .drectve at end of def file

生成されたファイルを実行する場合：

Exception 0xc0000005 0x8 0x13 0x13
PC=0x13
signal arrived during external code execution

main._Cfunc_hello()
        _//_obj/_cgo_gotypes.go:41 +
main.main()
        C://hello.go:9 +0x27

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        C:/Program Files/Go/src/runtime/asm_amd64.s:2197 +0x1
rax     0x4a5960
rbx     0xc042045f78
rcx     0x4a9a20
rdi     0xc042045f78
rsi     0x4adc60
rbp     0xc042045f38
rsp     0x6dfd68
r8      0xc042016340
r9      0x0
r10     0xc04204faa0
r11     0x4783c2
r12     0x0
r13     0x6
r14     0x0
r15     0xf1
rip     0x13
rflags  0x10216
cs      0x33
fs      0x53
gs      0x2b

PCにclコマンドがインストールされていません。 msvcをインストールするにはどうすればよいですか？

ありがとうございました。

アレックス

ここに「ビルドツール2017」が必要

c ++だけが問題でなければ、私はこれについて心配する必要はありません。 しかし、そうなので、痛みは続きます...

ここに「ビルドツール2017」が必要です。

とった。 ありがとうございました。

問題が多すぎる場合は、必要に応じてオブジェクトファイルを提供できます。

はい、hello.objをどこかに投稿してください。

これについてもう少し考えてみてください。 実際には、gccを使用して、msvcコンパイラでコンパイルされたオブジェクトファイルをリンクしています。 演習を試してみることができますが、「gobuild」ステップをgccに置き換えてhello.objをCプログラムにリンクしますか？ おそらくそれは以前に行われたことがあります。 その方法を知っていれば、Goでも同様のことができるのではないかと思います。

アレックス

AFAIK lld https://github.com/llvm-mirror/lldは、msvcオブジェクトファイルをサポートします。

オブジェクトファイルはここにあります： https ：

lldhttps ：//github.com/llvm-mirror/lldはmsvcオブジェクトファイルをサポートします

Goは、Windowsではgccリンカー（lldではない）を使用します。

オブジェクトファイルはここにあります： https ：

8月に帰宅したらやってみます。 ありがとうございました。

アレックス

Goは、Windowsではgccリンカー（lldではない）を使用します。

知っている。 しかし、lldはmsvcオブジェクト形式の最高のオープンソースドキュメントです。

私は実際にldから同じエラーを受け取るので、エラーは間違いなくldから来ています。

私は実際にldから同じエラーを受け取るので、エラーは間違いなくldから来ています。

はい。 msvcでパーツをコンパイルし、gccでリンクして、Cプログラムをビルドする方法を理解する必要があります。

アレックス

私の無知を許してください、しかし正確に何がgccリンクしていますか？ goリンカの出力をリンクしていますか？

elfに変換するオブジェクトファイルでobjconvを実行します。

objconv -felf hello.obj hello.syso

現在、次のエラーが発生しています。

hello.syso: In function `__local_stdio_printf_options':
(.text$mn+0x3): undefined reference to `?_OptionsStorage@?1??__local_stdio_printf_options@@9<strong i="9">@9</strong>'
hello.syso: In function `_vfprintf_l':
(.text$mn+0x3a): undefined reference to `__stdio_common_vfprintf'
hello.syso: In function `printf':
(.text$mn+0x28): undefined reference to `__acrt_iob_func'
collect2.exe: error: ld returned 1 exit status

おそらくstdioは立ち入り禁止ですか？

私の無知を許してください、しかし正確に何がgccリンクしていますか？ goリンカの出力をリンクしていますか？

Goプログラムを作成するには、次の2つのプログラムを使用します。

• コンパイラは、.goファイル（一度に1つのパッケージ）を％GOPATH％/ pkgディレクトリに保存されているオブジェクトファイルに変換します。
• ％GOPATH％/ pkgの下のオブジェクトファイルから最終的な.exeファイルを構築するリンカー。

時々（パッケージの1つがCgoを使用する場合）、Goリンカーは外部リンカーを呼び出してCに実装されているすべてのビットを検索します。Cコードからprintfを呼び出すと想像してください。 C printfでコンパイルされたコードはGo実行可能ファイルの一部である必要がありますが、Goリンカーはそれをどこで取得するかを知りません。 したがって、Goリンカーは外部リンカーを呼び出してそのコードを含めます。

Current Goは、gccコンパイラ/リンカーを使用してCコードをコンパイルおよびリンクします（mingw gccを使用します）。 別のコンパイラ（Microsoft製）でCコードをコンパイルする場合は、対応するリンカ（Microsoft製）を使用して、コンパイラが作成したすべての外部Cコードを見つける必要があります。

だから、私はgccリンカーを使用することを提案することについて間違っていたと思います。 一般的なシナリオでは、Microsoftコンパイラとリンカの両方を使用する必要があります。 Microsoftリンカーが入力として何を必要とするかを理解し、それに一致させる必要があります。

Cコードに外部コードがない場合は、MCリンカーがなくても問題が解決する可能性があります。 本当に単純なCプログラム（2つの整数などを追加するプログラムなど）を試してみてください。 これは、上記で説明したように機能する可能性があります。

アレックス

おそらくstdioは立ち入り禁止ですか？

そのコードを見つけるには、Microsoftリンカーを呼び出す必要があると思います。

アレックス

よくわかりませんが

objconv -felf hello.obj hello.syso

たぶん、あなたはエルフの代わりにcoffやomfをやってみるべきですか？

たぶん、あなたはエルフの代わりにcoffやomfをやってみるべきですか？

@xoviatはい、.objファイルをelfに変換しないでください。Windowsバージョンのgccは、他のWindowsコンパイラと同じようにpe / coffファイルを生成します。

アレックス

Goリンカは、外部リンカを呼び出して、Cで実装されているすべてのビットを検索します。

使用される特定のコマンドは何ですか？ mingwコマンドを知っている場合は、ファイル比較パスをたどって、mingwが出力しているものとmsvcを一致させようとすることができます。

go build -ldflags=-v実行すると、正確なコメントを確認できます。

さて、私が言えることから：

ld (link -> go.obj) + (gcc -> obj files) ==> a.out.exe

Goは、これらのファイルを使用して一時ディレクトリを作成しているように見えます。 一時ディレクトリを保存して、その内容を検査できるようにする方法はありますか？

go build -work試しください

WORK=C:\Users\mattn\AppData\Local\Temp\go-build566171254

オブジェクトファイルはこのディレクトリに残っています。

-workオプションは、実際にはリンカーが作成する一時ファイルを保持しません。 現時点では、ディレクトリを削除しないようにリンカソースを編集する必要があります。 おそらく、何らかの方法でそのためのオプションを追加する必要があります。

現時点では、ディレクトリを削除しないようにリンカソースを編集する必要があります。

よろしければ、これがHEADに実装されるまで待って、繰り返し作業する必要がないようにします。

一時ディレクトリを保存して、その内容を検査できるようにする方法はありますか？

cmd / linkプログラムにはそのための-tmpdirフラグがあります。 あなたはそれをこのように使うことができます：

c:\Users\Alex\dev\src\a>dir
 Volume in drive C has no label.
 Volume Serial Number is 9012-A870

 Directory of c:\Users\Alex\dev\src\a

06/08/2017  02:02 PM    <DIR>          .
06/08/2017  02:02 PM    <DIR>          ..
06/08/2017  02:02 PM                77 main.go
               1 File(s)             77 bytes
               2 Dir(s)  430,809,088,000 bytes free

c:\Users\Alex\dev\src\a>type main.go
package main

import "fmt"
import "C"

func main() {
        fmt.Println("Hello")
}

c:\Users\Alex\dev\src\a>go build -o a.exe -ldflags="-tmpdir=c:\Users\Alex\dev\src\a" main.go

c:\Users\Alex\dev\src\a>dir
 Volume in drive C has no label.
 Volume Serial Number is 9012-A870

 Directory of c:\Users\Alex\dev\src\a

06/08/2017  02:02 PM    <DIR>          .
06/08/2017  02:02 PM    <DIR>          ..
06/08/2017  02:02 PM             2,055 000000.o
06/08/2017  02:02 PM            22,376 000001.o
06/08/2017  02:02 PM         2,017,382 a.exe
06/08/2017  02:02 PM               135 fix_debug_gdb_scripts.ld
06/08/2017  02:02 PM         2,402,226 go.o
06/08/2017  02:02 PM                77 main.go
06/08/2017  02:02 PM                24 trivial.c
               7 File(s)      4,444,275 bytes
               2 Dir(s)  430,804,631,552 bytes free

c:\Users\Alex\dev\src\a>

アレックス

これは私自身の参照用ですが、これはmsvcに移植する必要があります。

_cgo_sys_thread_start(ThreadStart *ts)
{
    uintptr_t thandle;

    thandle = _beginthread(threadentry, 0, ts);
    if(thandle == -1) {
        fprintf(stderr, "runtime: failed to create new OS thread (%d)\n", errno);
        abort();
    }
}

static void
threadentry(void *v)
{
    ThreadStart ts;

    ts = *(ThreadStart*)v;
    free(v);

    ts.g->stackhi = (uintptr)&ts;
    ts.g->stacklo = (uintptr)&ts - STACKSIZE + 8*1024;

    /*
     * Set specific keys in thread local storage.
     */
    __asm {
          "movq %0, %%gs:0x28\n"    // MOVL tls0, 0x28(GS)
          "movq %%gs:0x28, %%rax\n" // MOVQ 0x28(GS), tmp
          "movq %1, 0(%%rax)\n" // MOVQ g, 0(GS)
          :: "r"(ts.tls), "r"(ts.g) : "%rax"
    }

    crosscall_amd64(ts.fn);
}

私は組み立てにまったく慣れていないので、このタスクを完了するのにかかる時間を過小評価することはありません。

• [x]アセンブリの機能を理解する
• [x] MSVCアセンブリへのポート
• [x] _beginthreadとCreateThreadを理解する
• [x] CreateThreadに切り替えます

また、未定義のシンボル：

• [x] timeBeginPeriod-> winmm.lib
• [x] timeBeginPeriod
• [x] WSAGetOverlappedResult-> Ws2_32.lib
• [x] WSAGetOverlappedResult
• [x] _cgo_18b6f6fc815b_Cfunc_hello
• [x] x_cgo_init-> msvc_windows_amd64.c
• [x] x_cgo_thread_start-> msvc_windows_amd64.c
• [x] x_cgo_sys_thread_create-> msvc_windows_amd64.c
• [x] x_cgo_notify_runtime_init_done-> gcc_libinit_windows.c
• [x] x_cgo_set_context_function-> gcc_libinit_windows.c

さて、予想よりも早くここに沿って移動します！

すべて： asm_amd64.sはgoのアセンブラー（奇数のアセンブリーを使用）またはgccのアセンブラーによってアセンブルされていますか？

gccはそれをアセンブルしないようです。つまり、おそらくアセンブルになります。 そして、問題は次のようになります。goアセンブラを使用してオブジェクトにアセンブルする方法。

目的は、runtime / cgo / asm_amd64.sがGoオブジェクトにアセンブルされ、cmd / linkが他のすべてのGoオブジェクトと一緒に単一のシステムオブジェクトにリンクし、システムリンカーがその単一のシステムオブジェクトとすべての最終的なプログラムへのcgoの依存関係。

テスト目的で今のところそのオブジェクトをアセンブルする方法はありますか？ goを除いてgcc -c asm_amd64.sように？

目的は、runtime / cgo / asm_amd64.sがGoオブジェクトにアセンブルされ、cmd / linkが他のすべてのGoオブジェクトと一緒に単一のシステムオブジェクトにリンクし、システムリンカーがその単一のシステムオブジェクトとすべての最終的なプログラムへのcgoの依存関係。

これまでのところ、私はこれらのオブジェクトを見つけました：

• go.o：明らかにgoツールチェーンから
• _cgo_.o ：gccによって生成され、使用できません
• 000000.o：gccによって生成され、使用できません
• 000001.o：更新：実際にはgoリンカーによって生成されますが、gccシンボルが含まれています。 使用できません。

go.oが最大のオブジェクトです。

@ianlancetaylor

あなたの言ったことは正しくないと思います。 crosscall_amd64は000001.oにありますが、そのファイルには「すべてのgoコード」が含まれていません。

000001.o:     file format pe-x86-64

SYMBOL TABLE:
[201](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x0000000000000440 crosscall_amd64
[206](sec  0)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x0000000000000000 free

このファイルは明らかにgccによって生成されたものであり、プロセスが遅すぎます。

テスト目的で今のところそのオブジェクトをアセンブルする方法はありますか？ goを除いてgcc-c asm_amd64.sのように？

asm_amd64.sはランタイムパッケージの一部です。 「gobuild」コマンドがasm_amd64.sファイルをどのように使用するかを次のように確認できます。

$ touch asm_amd64.s
$ GOOS=windows go build -x runtime 2>&1 | grep asm_amd64.s
/home/a/go/pkg/tool/linux_amd64/asm -trimpath $WORK -I $WORK/runtime/_obj/ -I /home/a/go/pkg/include -D GOOS_windows -D GOARCH_amd64 -o $WORK/runtime/_obj/asm_amd64.o ./asm_amd64.s
$

アレックス

ありがとう。

シンボルcrosscall_amd64は、runtime / cgo /gcc_amd64.sファイルで定義されています。 そのファイルはGCCによってコンパイルされます（すべてのruntime / cgo / gcc_ *ファイルも同様です）。 したがって、すべてのGoコードを含む単一のgo.oファイルに結合されるわけではありません。 前に説明したファイルruntime / cgo / asm_amd64.sは、シンボルcrosscall2定義します。 そのシンボルはgo.oにあります。

ありがとう。

さて、アクセス違反でクラッシュする実行可能ファイルをリンクすることができました
go.runtime.rt0_go + 5F-> go .___ acrt_stdio_initializer。

それは私が今のところ持っているすべての時間です。 後でこれに戻ります。

@alexbrainmanその通りです。

@alexbrainman続行するにはMSVCが必要です。 これについてサポートが必要かどうかをお知らせください。

続行するにはMSVCが必要です。

私はこれをインストールしていますhttps://www.visualstudio.com/downloads/#build-tools-for-visual-studio-2017

インストールしたらどうすればよいですか？

アレックス

それをインストールしたら、goライブラリである「libgo」をビルドする必要があります。 次のファイルをcgoフォルダーからコピーし

• gcc_amd64.S
• gcc_fatalf.c
• gcc_libinit_windows.c
• gcc_util.c
• gcc_windows_amd64.c
• libcgo.h

MSVCと互換性があるようにgcc_windows_amd64.cを調整する必要があります。 次のように関数を変更します。

static void
threadentry(void *v)
{
    fprintf(stderr, "threadentry: started");
    abort();

    ThreadStart ts;

    ts = *(ThreadStart*)v;
    free(v);

    ts.g->stackhi = (uintptr)&ts;
    ts.g->stacklo = (uintptr)&ts - STACKSIZE + 8*1024;

    /*
     * Set specific keys in thread local storage.
     */
    __writegsqword(0x28, (unsigned long long) ts.tls);
    *(void **)ts.tls = (void *) ts.g;

    crosscall_amd64(ts.fn);
}

「build.bat」と呼ばれるこれらすべてのファイルを含む新しいファイルをフォルダーに作成します。

REM TMP use gcc for assmebly file, in future port to ml64
gcc -c gcc_amd64.S
cl -c gcc_fatalf.c
cl -c gcc_libinit_windows.c
cl -c gcc_windows_amd64.c
cl -c gcc_util.c

ren gcc_amd64.o gcc_amd64.obj

lib gcc_amd64.obj gcc_fatalf.obj gcc_libinit_windows.obj ^
    gcc_windows_amd64.obj gcc_util.obj ^
    /OUT:libgo.lib

リクエストどおりにフォルダが構成されたらお知らせください。

ちなみに、これに取り組んでくれてありがとう。 あなたたちは本当に魔法の言語を作成しました。

リクエストどおりにフォルダが構成されたらお知らせください。

あなたがここで説明したように、私はなんとかlibgo.libを構築することができましたhttps://github.com/golang/go/issues/20982#issuecomment -327365063
次に何をすればいいですか？

アレックス

では、次のファイルが必要です。

• libgo.lib
• グー
• hello.cgo2.o
• こんにちはC

hello.cは次のとおりです。

#include <stdio.h>

extern void hello()
{
    printf("Hello World from C");
}

hello.cgo2.oとgo.oを取得するには、次のファイルから始める必要があります。

package main

/*
    extern void hello();
*/
import "C"
import "fmt"

func main() {
    fmt.Println("Hello from Go!")
    C.hello()
}

「hello.go」と呼ばれる

$ env：TMPからファイルを継続的にコピーするPowerShellスクリプトを設定します。

while ($true) {  cp -r $env:TMP\go-* C:\Users\User\Downloads }

次に、フォルダー内のhello.cとhello.goしてgo buildを実行します。 コピー先の場所から必要なファイルを回復できるはずです。

上記で指定したファイルを入手したら、次の方法でビルドできます。

cl libgo.lib go.o hello.cgo2.o hello.c Ws2_32.lib Winmm.lib -link /DEBUG:FULL

ご不明な点がございましたらお知らせください。

cl libgo.lib go.o hello.cgo2.o hello.c Ws2_32.lib Winmm.lib -link / DEBUG：FULL

これにより、go.exe実行可能ファイルが作成されますが、実行されません。 そこには賢明なasmコードはありません。 最初の指示はどこにも飛びつきません。 それはただの混乱です。

たぶん、あなたは本当に単純な何かから始めるべきです。 「INT $ 3」を実行し、他に何もない単一のasm関数を使用してasmファイル（Go asm file）を記述します。 そして、それから実行可能プログラムを構築してみてください-プログラムは最初から関数を実行する必要があります。

たぶん、最初にGoツールを使用して（そして必要に応じてgccを使用して）ビルドしてから、MSVCを使用して同じことを試してみてください。

アレックス

アレックス、助けてくれてありがとう。 私はそれに取り組みます。

参考までに、これら2つの記事をここに添付します。 それ以外の場合、これ以上の更新はありません。

私は実際に、msvcライブラリのみを使用するかなり複雑なgoプログラムを動作させました。 バニラmsvcリンカーとllvm-lldの両方が.bssセクションを正しく処理しなかったことが判明しました。

リンカにパッチを適用すると、プログラムを実行できるようになります。

残念ながら、 go buildは、 _cgo_.o / _all.o生成すると壊れます。 cgoでこれら2つのファイルを生成する背後にある理論的根拠に光を当てることは可能ですか？

go tool cgoを実行して、cgoを直接実行できます。 ソースはここにあります： https ：

また、これを実行できるとしたら、それは素晴らしいことです。 私はこれに時間を割いていないので、進歩はありませんでした。 申し訳ありません。

一連の手縫いで正しく実行できるプログラムをすでに入手しています。ここでやろうとしているのは、プロセスを統合して、痛みを軽減できるかどうかを確認することです。 :-)

手縫いのプロセスを文書化できれば、私がお手伝いできるかもしれません。

見ただけで、 _cgo_.oは次のように生成されているようです（簡略化）：

gcc [*.c] [*.cxx] -o _cgo_.o

ここから： https ：

また、ドキュメントについては、こちらを参照してください。
https://github.com/golang/go/blob/840f2c167f1d5196559d8a1e77c370960e66d34e/src/cmd/cgo/doc.go#L607

理想的には、オブジェクトファイルを前処理してlink.exeと互換性を持たせ、摩擦を最小限に抑えるgoプログラムを作成しますが、それは一種の目標です。

ポインタをありがとう-私はすぐにプロセスを書き留めるつもりです。

残念ながら、 .bssセクションではなく.dataセクションで初期化されていないデータを出力するようにgccを変更しない限り、 link.exeを介してリンクを実行できるとは思いませんが、可能です。 llvm-lldを確実に修正して、 .bssセクションを認識します（これは私が行ったことです）。

_cgo_.oと_all.o別々に取り組む必要があります。 私はそれらについていくつか質問があります：

（1） _cgo_.oは、goランタイムが含まれていないため、最終的な実行可能ファイルではないようです。 コンパイラが構造体の定義を理解するためにDWARFシンボルを調べているように見えます。 問題は、外部の多数のライブラリ、特にmsvcによって生成されたライブラリとリンクする場合、実行可能ファイルを生成するのが難しいことです。

このステップを回避することは可能ですか？

（2）現在はGNU ldを使用して、GCCで-Wl,-rを渡すことにより、すべてのオブジェクトファイルを_all.oにステッチします。 これは、（1）他のリンカーがこの機能を備えていないようであり、（2）コマンドがCGO_LDFLAGS影響を受けるため問題があります。 たとえば、次のコマンドは誤った結果を生成します。

CGO_LDFLAGS="-Wl,-T,my-linker-script"
gcc .... $CGO_LDFLAGS -Wl,-r,...

バンドルされたオブジェクトファイルの代わりに実行可能ファイルを生成します。

生成された.aにすべてのオブジェクトファイルを直接配置するだけで、この手順を完全に回避することは可能ですか？

@zoobaこのパッチでMSFTにlink.exeを更新させる可能性は何ですか？

残念ながら、.bssセクションではなく.dataセクションで初期化されていないデータを出力するようにgccを変更しない限り、link.exeを介してリンクを実行できるとは思いませんが、llvm-lldを修正して.bssセクションを認識することは間違いありません。 （これは私がやったことです）。

MSFTが更新されないと仮定してlink.exe （可能性のある）を、持つオブジェクトファイルをコンパイルするとよいでしょうcl.exeではなくgcc 。

_cgo_.oは、goランタイムが含まれていないため、最終的な実行可能ファイルではないようです。

そうです、基本的に2セットのオブジェクトファイル（私は思う）が最終的に一緒にリンクされます。 go.oファイル（IIRC）には、すべてのgoコードとランタイムが含まれ、他のオブジェクトにはCコードが含まれています。 2セットのオブジェクト間をジャンプするためのアセンブリルーチンがあります。

また、Unixアセンブリファイルをコンパイルするにはclangが必要です。

ここでは、 -Wl,-rはlib.exe [object files] /OUT:objを実行するのと同じになります。 このオプションは、「インクリメンタルリンク」を意味します。これは、「いくつかの入力ファイルを取得し、いくつかの作業を行ってから、別のオブジェクトファイルを吐き出す」ことを意味します。 今のところ「作業を行う」部分について心配しない場合は、オブジェクトファイルが次の場合を除いて、「いくつかの入力ファイルやオブジェクトファイルを取得し、別のオブジェクトファイルを吐き出す」という要件を取ることができます。図書館。

オプション-fno-zero-initialized-in-bssを使用して、.bssセクションではなく.dataセクションに変数を配置しないようにGCCに指示できます。

ヒントでは、cgoコードをビルドするときに-Wl,-r使用しなくなったことに注意してください。

cmd / linkがMSVCオブジェクトファイルを.sysoファイルとして使用するために、それらを理解する必要はありません。 これらのファイルは、とにかく外部リンカに渡されるだけです。 したがって、ここで必要なのは、MSVCリンカーを外部リンカーとして呼び出すことだと思います。これは、 -extldオプションを使用して実行できるはずです。 あなたがすでにそれをしているなら、私の謝罪。 その場合、何が失敗していますか？

あなたがすでにそれをしているなら、私の謝罪。 その場合、何が失敗していますか？

IIRC、gccで生成されたオブジェクトのlink.exeバーフ。

確かに、 CC環境変数を適切に設定することにより、MSVCCのコンパイラも使用する必要があります。 GCCオブジェクトとMSVCオブジェクトを1つのリンクに結合することはうまくいかないと思います。

しかし、その後、ランタイムCライブラリがプリコンパイルされるという問題が発生します。 そして、それらを再コンパイルしようとすると、 clがUNIXアセンブリをコンパイルできないという問題が発生します。 そして、ランタイムライブラリの一部を移植し、それらをリンクしようとします。これは私が行って失敗したことです。

途中のどこかで、 clはコードの重要な部分を誤ってコンパイルします。 これを修正するための私のアイデアは、MSVCコードをフラットC APIを使用してDLLに分解し、動作が停止するまでランタイムライブラリを段階的にコンパイルすることです。

問題を解決するための@haohuiの考えは異なっていました。 彼は問題の根本を修正するのではなく、リンカーにパッチを当てることで問題を回避しました。 明らかに彼は私よりも多くの成功を収めましたが、それはおそらく彼のアプローチが私よりもうまくいく可能性が高いためです。

この時点（IMHO）でお勧めするのは、ランタイムライブラリが機能しなくなるまで、またはgccコードがなくなるまで、 clを使用してランタイムライブラリを段階的にコンパイルすることです。 そうすれば、問題がどこにあるかを正確に知ることができます。

また、リンカーパッチを使用すると、DLLは必要ありません。

llvm-lldのパッチは、 https： //bugs.llvm.org/show_bug.cgi 。

例を示すために少し時間を費やします。

+1 @haohuiこれを進めてくれてありがとう！

@haohuiパッチはどのバージョンのllvmに適用されますか？ パッチの使用方法とMSVCファイルへのリンク方法に関する指示はありますか？

_cgo_.oファイルと_all.oファイルに関しては、同じ問題が発生したため、この問題の修正が他の問題の修正になる可能性があります： https ：

これに関するすべての作業に感謝します。 順調に進んでいるようです。 新機能はGo1.11まで凍結されるため、マイルストーンが変更されます。

それで私は昨夜この中に飛び込んだ。 msvc：clを介してすべてをビルドし、 ます。 しかし、問題は軍団です。

したがって、 msvc：clがC99を完全にサポートしていないなどの単純な問題を超えて（現在、タイプ_Complexを処理できません）。 gointernalsによってビルドされたPEライブラリとmsvcによってビルドされたPEライブラリを組み合わせると、より体系的な問題が発生します。 具体的には、 msvc：linkは.bssセグメントを吹き飛ばします（このデータを.dataにスローする可能性があると思います）。これは、goアセンブラーSB（pseudo reg）が、.bssが移動された場合に誤ったアドレス指定をもたらすように見えるため、問題です。 。

私の最初の考えは、アセンブラに.bssと.noptrbssに入るものをそれぞれ.dataと.noptrdataに配置させることでした。 これが可能かどうかさえわかりません。 私がそれをいじるのは成功せず、アドレス指定は完全に失敗します。

今のところlink.exeは使えないと思います。 lld-link.exeから始めるべきだと思います

その背後にある考えが、.bssデータを移動しないようにlld-linkにパッチを適用できるということであれば、私はその魅力を理解しています。 現実的には、目標が実際のmsvcツールチェーンをサポートすることである場合は、内部コンパイルに進み、データを.bss /.noptrbssに配置する必要があります。

lld-link.exeをgoで再配布することはできませんか？ これは、LTCGが有効になっていない限り、MSVCオブジェクトファイルをサポートするための最もリスクの低いパスのようです。 理想的ではないことは理解していますが、リソースの制約に直面しています。

それはまた、最良の戦略である漸進的な進歩を可能にします。

さて、いくつかの良いフォローアップニュース、私は昼食時にこれに取り組むのに1時間を費やすことができました。

現時点では、問題の前半の例が機能しています。

- hello.go:
package main

/*
    extern void hello();
*/
import "C"

func main() {
    C.hello()
}

- extern.c
#include <stdio.h>

extern void hello()
{
    printf("Hello World from C");
}

>ac.out.exe
Hello World from C

バイナリは、MSVCおよびGoツールチェーンで完全に構築されています（GCCまたは他のLLVMはインストールされていません）。

調査結果：

• Go tools / link.exeが内部アセンブリの.bssデータを.dataに出力することは、最終的にはかなり簡単でした。
• いくつかのASMピースをmsvc用に調整する必要がありました
• いくつかのGCC＃defがシムされました
• cgoで生成された.cファイルの一部にいくつかの小さな調整を加える必要がありました
• 複素数は、サポートされていない時点でシムする必要があります
• msvcサポート用にビルドまたはリンクするには、追加のフラグを直接追加する必要がある可能性があります。ldflagsなどでは不十分です。

次のステップ：
今週末に時間があれば、変更をフォークに入れる作業をしますが、ビルド/リンクのフラグの背後にある機能です。 その後、PRを行ってレビューを行い、種類を検討します。 .bssデータを移動しても、どこかに何らかの影響がないことを100％確信しているわけではありません。

私が考えることができる唯一の欠点は、バイナリのサイズが大きくなることですが、問題はないはずです。

わかった！

申し訳ありませんが、これをまとめるのにさらに数日かかりました。 したがって、パッチの最初のドラフトはここにあります： https ： https://github.com/cchamplin/go/tree/msvc_toolchain_support

これはまだ大雑把ですが、msvcを使用してコードを正常にビルドできます。

人々が今これをテストし始めてバグを私に報告して、私がこれを上流のより良い場所に置くことができれば素晴らしいと思います。 また、誰かがテストを書くことをチップしたいなら、それは素晴らしいでしょう！

使用法：

go build -compiler msvc [path]

• 複素数は、私たちがそれらを機能させることができるかどうかを理解するまで、現在サポートされていません。
• msvcコンパイラを使用してgoランタイムをビルドしようとするとどうなるかわかりません。
• gccはまだ必要であり、コンパイル時に定義と型データを取得するためにgcoによって使用されますが、ビルドには使用されません）。 これを回避できるかどうかはわかりませんが、msvcには同じドワーフとコードの#defineダンプを実行できるものは何もありません...誰かがこれについてアイデアを持っているなら、それは素晴らしいことです

リンクされたパッチは、ブートストラップの問題を引き起こします。

@alexbrainman toolchain1ブーストラッピングフェーズ中にどのファイルがpkg/boostrap/src/bootstrapにコピーされるかは、どこでどのように決定されますか？

cc @alexbrainman

リンクされたパッチは、ブートストラップの問題を引き起こします。

今日、ブートストラップがどのように機能するのかわかりません。 しかし、他の人（ @rscと@ianlancetaylor）が助けてくれると確信しています。

ブートストラップが機能しない場合、 @ cchamplinがmake.batをどのように実行するのだろうか。

アレックス

@xoviat何が問題なのかわかりませんが、ブートストラップディレクトリのリストはcmd / dist /buildtool.goにあります。

ねえ@ alexbrainman 、 @ ianlancetaylor 、 @ xoviat申し訳ありませんが、もっと徹底的に検証する必要があったと思います。

ここhttps://github.com/cchamplin/go/commit/69a5cfc1dd0106fd8a2928a83e4c7001e81e89b8でブランチを更新し、ブートストラップの問題を修正しました。今は正しくブートストラップする必要があると思います。

いくつかの/ src / internal / syscallディレクトリをcmd / internal / msvcにコピーする必要がありました。 それは大きな問題になるのでしょうか？ src / internalを使用せずにレジストリにアクセスする方法がわかりません。

いくつかの/ src / internal / syscallディレクトリをcmd / internal / msvcにコピーする必要がありました。 それは大きな問題になるのでしょうか？ src / internalを使用せずにレジストリにアクセスする方法がわかりません。

最近のやり方はわかりませんが、ソースファイルを手動でコピーしなくてもcmd / distでできるのではないかと思います。 コードを送信する準備ができたら、RussまたはIanがお手伝いすると確信しています。

@bradfitzと@ianlancetaylorがここでどのように進めるかを決める時が来たと思います。 GoにgccだけでなくMicrosoftビルドツールもサポートさせたいですか？ 対応するMicrosoftツールをビルダーにインストールする必要があります（CLの受け入れを開始する前にインストールする必要があります）。 おそらく、新しい環境変数を導入する必要があります。 新しいドキュメント。

答えが「はい」の場合、 @ cchamplinはhttps://golang.org/doc/contribute.htmlに従って、コードの変更を送信する必要があります。 変更は非常に大きいため、個別に確認して送信できるように、小さなCLに分割する必要があります。 変更を送信するには、変更ごとにall.batPASSが必要です。 最初のCLの送信を開始する前に、すべてのCLを確認できれば便利です。

ありがとうございました。

アレックス

GoにgccだけでなくMicrosoftビルドツールもサポートさせたいですか？

このパッチは、私がすでにパッチを処理している＃17014も容易にすることに注意してください。

答えが「はい」の場合、 @ cchamplinはhttps://golang.org/doc/contribute.htmlに従って、コードの変更を送信する必要があります。 変更は非常に大きいため、個別に確認して送信できるように、小さなCLに分割する必要があります。

はい、そしてそれを分割することは大したことではないはずです。 すべてのコードをクリーンアップしたり、ドキュメントを作成したり、テストを作成したりする前に、これが問題になる可能性があるかどうかを知る必要があります。

GoにgccだけでなくMicrosoftビルドツールもサポートさせたいですか？

私の考えでは、答えはイエスです。 コンパイラ自体はVSCommunityで無料であり、完全なWindowsサポートがないことは本当にイライラします。 Windowsツールチェーンはサポートされていないため、 github.com/Microsoft/hcsshimをコンパイルするためにLinuxボックスを立てる必要はありません（たとえば）。

Windowsツールチェーンをサポートしない理由は何でしょうか？

原則として、MSVCオブジェクトファイルをサポートすることは問題ないと思います。 ビルダーが必要になります。

私の主な関心事は、WindowsまたはMSVCのリリース間でフォーマットがどの程度変わる可能性があるかです。 他のほとんどのプラットフォームで使用されているELF形式は非常に安定しています。 新しいプロセッサのサポートを追加する以外の方法でELFサポートを微調整する必要があることはめったにありません。 MSVCファイル形式も同様に安定していますか？

MSVCツールチェーンに関連付けられている形式はかなり安定しています。 最大の問題は、ツール自体をサポートすることです。 Microsoftは、Visual Studioのリリース間で物事（ファイルとレジストリエントリ）を移動する傾向があります。 これのほとんどは（少なくとも私が書いたパッチでは）構成可能ですが、Visual Studioの新しいメジャーバージョンがリリースされたときに、Goを変更しないとビルドツールチェーンとして互換性がない可能性があります。 ただし、サポートされている以前のバージョンのVisualStudioはすべて引き続き機能します。

私の知る限り、C ABI（C ++ではなく）だけにさらされた場合、COFF形式は妥当な安定性を備えています。 また、広範囲にわたって文書化されており、LLVMはリファレンス実装を提供します。

@cchamplin MSVCとリンクする前に、ユーザーにvcvarsall.batを呼び出すように要求することをお勧めします。 これにより、メンテナンスがほぼゼロに大幅に削減されます。

ビルダーが必要になります。

@ianlancetaylor MSVCオブジェクトが意図したとおりに機能することが証明されたら、msys / cygwinビルダーとMSVCビルダーの両方が必要になると思いますか、それともMSVCビルダーのみが必要になると思いますか？

cygwinツールの使用を好む人もいると思いますが、それらはすでに機能しており、引き続き機能させたいので、2つのビルダーが必要だと思います。

このスレッドの下部から、MSVCの問題が整理されているように見えます。 ただし、問題が発生した場合は、MSVCチームに所属しています。 githubまたは電子メール（[email protected]）で私にpingしてください。

ビルダーが必要になります。

はい。 そして、MSビルドツールをインストールするように既存のビルダーを変更することから始める必要があります。 したがって、この問題のCLを受け入れるときに、それらを使用できます。

gccツールとmicrosoftツールの両方をすべてのビルダーにインストールできます。 gccツールとMicrosoftツールの両方を一度にテストするall.batを実行できますか？ そうでない場合は、さまざまなツール用にさまざまなビルダーを構成する必要があります。 使用する外部コンパイラとリンカを制御するパラメータは何ですか？

私の主な関心事は、WindowsまたはMSVCのリリース間でフォーマットがどの程度変わる可能性があるかです。

Windowsにコンパイラがインストールされていません。 自分でインストールする必要があります。 gccと同じように。 好きなバージョンをインストールします。 異なるビルダーで異なるgccバージョンを実行することもできます。

MSVCファイル形式も同様に安定していますか？

私はそれについて何も知りません。 提供されているツールを使用しているだけだと思います。

アレックス

私の主な関心事は、WindowsまたはMSVCのリリース間でフォーマットがどの程度変わる可能性があるかです。 他のほとんどのプラットフォームで使用されているELF形式は非常に安定しています。 新しいプロセッサのサポートを追加する以外の方法でELFサポートを微調整する必要があることはめったにありません。 MSVCファイル形式も同様に安定していますか？

はい、COFFは非常に安定しています。

@bradfitzと@ianlancetaylorこの問題の変更をテストするためにWindowsビルダーを利用できるようにするために何が必要ですか？ https://github.com/golang/go/issues/20982#issuecomment-370719472で私の質問を参照して

ありがとうございました

アレックス

今すぐmsvcオブジェクトをサポートしますか？

変更https://golang.org/cl/110555はこの問題に言及しています： debug/pe: parse the import directory correctly

@alexbrainman @bradfitz @ianlancetaylor ：

パッチをクリーンアップしてより消化しやすい部分に分割するために必要な作業のほとんどを実行しました。 プロジェクトへの実際の提出の準備がほぼ整っていると思います。 コードを送信する前にビルダーの状況についての情報を待つ必要があるのか​​、それともできるだけ早く実行するのかを知る必要があると思いますか？

CLはいつでも送信できますが、誰かがビルダーをセットアップする必要があります。 そうでなければ、それらをテストする方法がありません。

@ johnsonj 、MSVCコンパイラツールをWindowsイメージに追加できますか？

理想的には、新しいホストタイプを追加せず、既存のWindowsホストタイプの1〜3にCygwinに加えてMSVCツールを持たせたいと思います。 そして、それらの変更されたホストタイプの上にさらにビルダー構成を追加できます。

/ cc @andybons @bcmills as FYI（Windowsの処理がどのように行われるかについて...私たちはJeffに助けを求めます:)）

@ johnsonj 、MSVCコンパイラツールをWindowsイメージに追加できますか？

@cchamplinビルダーに必要なツールを自分で追加してみることをお勧めします。 他に誰もいませんが、あなたは何が必要かを知っています。 詳細な手順については、golang.org / x / build / env / windowsディレクトリを参照してください。 特に、startup.ps1にさらに行を追加したいと思うかもしれません。 そのディレクターで何を変更する必要があるかがわかったら、変更を加え、 https：//golang.org/doc/contribute.htmlを介してレビューのために変更を送信します

理想的には、新しいホストタイプを追加せず、既存のWindowsホストタイプの1〜3にCygwinに加えてMSVCツールを持たせたいと思います。 そして、それらの変更されたホストタイプの上にさらにビルダー構成を追加できます。

Windowsには常にMingw（gcc）Cコンパイラとリンカーがありました。 異なるCビルドツールのセットはありません。 Microsoft Cコンパイラのサポートを追加したら、all.batを1回実行するだけでMingw関数とMicrosoft C関数の両方をテストすることは可能でしょうか？ または、MingwまたはMicrosoft Cはお互いを除外しますか？ MingwまたはMicrosoftを指すように環境変数を設定する必要がありますが、両方を指すことはありませんか？ コードをどのように構造化してテストする必要があるかを理解しようとしていると思います。 また、これにより、必要なビルダーの数が決まります。

アレックス

画像内のバイナリをベイク処理する方法を調べます

変更https://golang.org/cl/112036はこの問題に言及しています： env/windows: add visual studio tools to image

@johnsonj @bradfitz ：それをビルダーに入れてくれてありがとう。

@alexbrainman @bradfitz @ianlancetaylor ：このための戦略をテストする限り、私は何をすべきか正確には

このためのテスト戦略に関する限り、私は何をすべきか正確にはわかりません。 ウィンドウで両方のツールチェーンに対してdisttestを実行するパスを取り、すべてのテストを2回実行できますか、それともcgoテストを2回（gccに対して1回、msvcに対して1回）だけテストする必要がありますか？

@cchamplinあなたの質問に対する答えはありません。 イアンは答えを知っていると思います。

アレックス

cgoだけでなく、すべてのテストを2回実行するコストはいくらですか？

@ mxplusb 、Windowsの新しいビルド構成を実行するだけで、既存の3と並行して実行されます。新しいビルダー構成で問題ありません。 定期的に追加しています。

それを変える方法を教えてください：異なる/新しい環境変数を設定すると、何かがそれを拾うと思いますか？

これを機能させるには、おそらくいくつかのことが必要です。

適切なvsvars.batが実行/呼び出された後、distテストが実行するgoテストが内部で実行されるシェル/環境の内部で実行する必要があります。

または、適切なvsvarをdistで実行し、必要な環境変数を抽出してから、それらを設定/受け渡ししてテストを行うこともできます。

また、-compiler msvc setを使用してテストを実行することをdistまたはmake.batに通知するために、環境変数が必要になる場合もあります。

適切なvsvars.batが実行/呼び出された後、distテストが実行するgoテストが内部で実行されるシェル/環境の内部で実行する必要があります。

または、適切なvsvarをdistで実行し、必要な環境変数を抽出してから、それらを設定/受け渡ししてテストを行うこともできます。

dist.exeまたはgo.exeからバッチファイルを実行しない方がいいと思います。 バッチファイルを扱うのは面倒です。

また、-compiler msvc setを使用してテストを実行することをdistまたはmake.batに通知するために、環境変数が必要になる場合もあります。

私はイアンがここでの最善のアプローチが何であるかを知ってくれることを望んでいました。 私が知っていることから、UnixでもさまざまなCコンパイラ（gccまたはclang）をサポートしています。 確かに、ビルドプロセスでは、さまざまなCコンパイラをテストできます。

アレックス

go build -compiler msvc使用を計画していることに気づきませんgo build -compilerオプションは、Goコンパイラ（現在はgcまたはgccgo）の名前を取ります。 Cコンパイラの名前は取りません。 CコンパイラはCC環境変数で渡されます。 デフォルトのCコンパイラは、make.batのコメントに記載されているように、make.batの実行時にCC_FOR_TARGET環境変数を設定することによって設定されます。

all.batを実行する前に、 CC_FOR_TARGET環境変数をmsvcに設定するように調整するビルダーがあると思います。 なぜ他のことをしなければならないのかわかりません。

CコンパイラはCC環境変数で渡されます。 デフォルトのCコンパイラは、make.batのコメントに記載されているように、make.batの実行時にCC_FOR_TARGET環境変数を設定することによって設定されます。

説明してくれてありがとうイアン。

@cchamplin既存のモデルに合うように変更を調整できることを願っています。 ご不明な点がございましたら、お気軽にお問い合わせください。 ありがとうございました。

all.batを実行する前に、CC_FOR_TARGET環境変数をmsvcに設定するように調整するビルダーがあると思います。

https://build.golang.orgに3つのamd64Windowsビルダーがあり

アレックス

@ianlancetaylor @ alexbrainman - compilerフラグについて理解しました。 CC="msvc" （または実際にはCC="cl.exe" ）を設定するだけで機能させる簡単な方法はないと思います。 CCは、MSVCビルドが機能するためにGCCの場所を指す必要があります。 msvcコンパイラツールセットには、CGOが必要なイントロスペクション（定義ルックアップ、型解決）を実行できるようにするためのツールがないため、MSVCビルドではGCCが引き続き必要であり、GCCは実際のコンパイル/リンクフェーズでは使用されません。

ビルドするために新しいフラグを追加することはすべて受け入れられますか（ツールチェーンなど）？ 私はすでにツールチェーンフラグをcgoに追加する必要があったと思います。

また、all.batの前にCC_FOR_TARGET設定すると、ブートストラップで使用されるコンパイラに影響を与えるため、悪影響が生じる可能性があります。 ブートストラッププロセス中にMSVCを使用できるとは思いません（100％ではありません。実際に試したことはありませんが、機能するかどうかは非常に疑わしいです）。

なるほど、MSVCの場合、GCCとMSVCの両方が必要ですか？ GCCはcgoツールでのみ使用されますか？ これは、GCCとMSVCがまったく同じABIを実装することに完全に依存することを意味するため、やや不幸に思えますが、それはかなり可能性が高いと思います。

GCCに設定できる別の環境変数CC_FOR_CGO追加できると思います。

make.batで使用されるCC_FOR_TARGETは、runtime / cgoのビルドに使用されます。 使用しているCコンパイラでruntime / cgoがビルドされていない場合、cgoがどのように機能するかは私にはわかりません。

おそらく、make.batが呼び出されたときにCC_FOR_TARGETをcl 、 CGO_ENABLEDを0設定して動作させることから始める必要があります。

ありがとう@ianlancetaylor ：

なるほど、MSVCの場合、GCCとMSVCの両方が必要ですか？ GCCはcgoツールでのみ使用されますか？ これは、GCCとMSVCがまったく同じABIを実装することに完全に依存することを意味するため、やや不幸に思えますが、それはかなり可能性が高いと思います。

私はそれが不幸であることに同意します、そしていくつかの代替案を知ってうれしいです、私はまだそれを見つけていません。 この方法でビルドするリスクは確かにあります（たとえば、ビルドされるcgoコードは、ビルド元と見なされるコンパイラに応じて、異なる型の定義または定義を持ちます）。 そのため、いくつかの調整を行わないと、ビルドが常に成功したり正しく機能したりするわけではありません（私の実装ではこれを処理するメカニズムがありますが、少し手動のプロセスです）。 残念ながら、これはMSVCツールチェーンを使用したい場合に人々がとらなければならないリスクであり、私たちにできることは今のところそれを文書化することだけだと思います。

同様に、MSVCコンパイラがc99に準拠していないという理由だけで、MSVCで構築されたcgoプログラムでcomplex64およびcomplex128のサポートを提供するための実際の道はまだありません。

GCCに設定できる別の環境変数CC_FOR_CGO追加できると思います。

したがって、現在の実装では、go buildがMSVCでビルドするように指示されている場合、デフォルトでパス上のcl.exeが検索されますが、これは環境変数MSCCでオーバーライドできます。 CGOは、生成されたzdefaultcc.goにあるgcc /何でもにフォールバックするCC環境変数を引き続き使用します。

make.batで使用されるCC_FOR_TARGETは、runtime / cgoのビルドに使用されます。 使用しているCコンパイラでruntime / cgoがビルドされていない場合、cgoがどのように機能するかは私にはわかりません。

現在の実装では、goツールチェーン全体がgccによって構築されている場合でも、cgoはmsvcバイナリに対して問題なく機能します。 たとえば、MSVCコードがgo / srcに追加されます。 all.batは、gccを使用してgo環境を構築するために実行されます。 その後、go / bin / go.exeを使用してmsvcツールチェーンでビルドできます（フラグが提供されていると想定）。 私はあなたがここで言っていることを誤解しているかもしれません。

msvcを使用してビルドするように指示することは、コンパイラをclに切り替えるよりも複雑であるため、これに関する複雑さ。 MSVCツールチェーンはgccツールチェーンとは大きく異なります。 MSVCでは、vcvars.bat内で実行することで環境をセットアップする必要があります（または、vcvars.batを実行し、セットアップした環境変数から必要なすべての情報を抽出してビルドで使用するなど、v8が行うことを実行します）。処理する）。 MSVC環境に入った後の主な違いは、ツール自体がcl.exeを使用してCおよびC ++ファイルをコンパイルし、ml.exeおよびml64.exeを使用してファイルをアセンブルし、最後にlink.exe（ms）を使用してすべてをリンクします。 つまり、 CC=cl.exeを設定して、適切なフラグを渡すだけではありません。 それは理にかなっていますか/物事を明確にするのに役立ちますか？

さらに明確にするために

make.batで使用されるCC_FOR_TARGETは、runtime / cgoのビルドに使用されます。 使用しているCコンパイラでruntime / cgoがビルドされていない場合、cgoがどのように機能するかは私にはわかりません。

go buildは、ビルドプロセス中にruntime / cgoから適切なファイルを選択しています（例： go build / go test / go run -ビルダープロセスではありません）。 msvcツールチェーンが選択されました。

これがどのように機能するかについての提案を受け入れていますが、goツールの新しいコマンドラインオプションは必要ありません。 goツールに関する限りGCCのように動作するが実際にはMSVCを実行する純粋なGoプログラムを作成できますか？

goツールに関する限りGCCのように動作するが実際にはMSVCを実行する純粋なGoプログラムを作成できますか？

私はそれがうまくいくかもしれないと信じています、私がその道で何かを進めることができるかどうか見てみましょう。

さらに、他のツールにコマンドラインフラグを追加することも問題になるかどうかを明確にする必要があると思います。 現在、このための包括的なパッチは、さまざまなツールでいくつかの新しいコマンドラインフラグを作成しています

• cmd / cgo
  
  
  
  • -toolchain [gcc、msvc]（デフォルトはgcc）cgo出力ファイルをビルドするときに使用するツールチェーン
  
  
• cmd / link
  
  
  
  • -rlocbss（デフォルトはfalse）.bssを.dataに再配置します
  
  
  • -toolchain [gcc、msvc]（デフォルトはgcc）外部リンクに使用されるツールチェーン
  
  

また、次のビルドオプション/ cgo環境変数を作成します。

• MSCXX
• MSCC
• MSCFLAGS
• MSCPPFLAGS
• MSCXXFLAGS
• MSLDFLAGS

数分間考えた後、コンパイラコマンドをプロキシするだけでは克服するのが難しいかもしれないいくつかのハードルがあります。

1. go buildは、ビルドするランタイム/ cgoファイルを決定するために外部ツールチェーンが何であるかを知る必要があります。そうしないと、互換性のないgccバージョンをプロキシコマンドに渡すだけになります。 プロキシ自体の内部でこれをハックすることはできるかもしれませんが、runtime / cgoに追加のファイルが追加された場合、脆弱で壊れてしまう可能性があります。
2. cmd / cgoは、使用する出力Cコードのバージョンを選択するために使用されている外部ツールチェーンの種類を知る必要があります
3. プロキシプログラムは、gccを実行する必要があるかどうか（cmd / cgoによって呼び出される場合など）を知るメカニズム、または渡される可能性のあるcl.exeを実行するメカニズムを必要としますが、呼び出し元はツールチェーンを知る必要があります。または、cmd / cgoが存在しないフラグをgccに渡します。
4. go buildはcmd / linkを呼び出します。このツールチェーンは、.bssから.dataへの再配置を実行し、特定のフラグをリンカーに渡すことができるように、ツールチェーンを知る必要があります（後者を処理できる可能性があります）ただし、プロキシ自体の一部です）

go build使用してmsvcビルドを決定する環境変数を指定しますか？ msvcを使用してプログラムを構築したいだけの人にとっては、バーが高くなると思いますが、vsvars.bat内で実行することに加えて、複数の環境変数を設定する必要があります（少なくともCCとUNDECIDED_TURN_ON_MSVC_BUILD_VAR ）

別の方法は、指定されたCCでgo build偽のnoopコマンドを実行させ、ロゴ/ヘッダーを解析してmsvcまたはgccかどうかを検出し、その時点で適切なツールチェーンの調整を続行することです。 ...これがどれほど脆弱であるか、またはclangのようなmsvc互換ツールチェーンでどのように機能するかはわかりません。

最近このGithubの問題を発見しましたが、この作業は私にとって非常にエキサイティングです。 近い将来、これがどこかに着陸することを願っています。

私の意図は、Windows上のCGoを、MSVCを使用して構築されたサードパーティコードのラッパーとして使用することです。 mingw-w64を使用してソースから再構築することはできません。 私はそれを実行するための比較的深刻なテストケースをいくつか持っているので、それをかなりうまく検証することができます。

とにかく、 @ cchamplinとそれに取り組んでいる他の人に感謝します、そしてとにかく私が助けることができることを私に知らせてください。

@cchamplin私は、Windowsとcgoのコンパイラツールチェーンについて危険であることが十分にわかっているので、支援できる可能性があります。 あなたが取り組んできたもののいくつかについて私に追いつくことができますか？ 私が支援するために何ができるかを見ていきます。 @deadprogramのユースケースを知っているので、テストの準備ができたら、高度なテストベッドを用意しています。

ねえ@mxplusb 、パッチは実際には多かれ少なかれ準備ができています。 時間を見つけることができれば、今夜または明日、gerritに変更を送信します。これにより、すべてのレビュー、更新、および承認を受けるための作業が開始されます。

変更https://golang.org/cl/133937はこの問題に言及しています： cmd/link: Add flag rlocbss to relocate .bss data to .data

変更https://golang.org/cl/133938はこの問題に言及しています： runtime/cgo: MSVC toolchain support in cgo native code

変更https://golang.org/cl/133939はこの問題に言及しています： cmd/cgo: Add toolchain flag to cgo command for MSVC support

変更https://golang.org/cl/133946はこの問題に言及しています： cmd/compile: Add support for MSVC toolchain to go build

一部のコミットで問題をタイプミスしたようです。 レビュープロセスを開始し、修正するための最良の方法を決定します。

変更https://golang.org/cl/133943は、この問題について言及しています： cmd/cgo: Add support for CC_FOR_CGO environment variable

変更https://golang.org/cl/133942はこの問題に言及しています： tests: Update various tests to prepare for MSVC compiler toolchain

変更https://golang.org/cl/133940はこの問題に言及しています： misc/cgo: Adjust tests to be compatible with MSVC toolchain support

変更https://golang.org/cl/133941はこの問題に言及しています： runtime: Add runtime.CompilerType to denote between host compiler type

変更https://golang.org/cl/133945はこの問題に言及しています： cmd/link: Add external toolchain support for MSVC

変更https://golang.org/cl/133944はこの問題に言及しています： cmd/compile, cgo: Add support for MSVC flags

@cchamplin最終決定は何でしたか説明できますか？ MSVCサポートはどのように見えますか？ どのコマンドラインフラグが追加されますか？ MSVCのダウンロードに加えて、ユーザーは自分の環境に対して何をする必要がありますか？ ありがとう

また、どうすればこのパッチを試すことができますか？ リポジトリでコミットが見つかりませんでした。

@rasky変更がレビューされているため、まだ少し流動的です。 設定する必要のある特定のコマンドラインフラグはおそらくないでしょう。CC環境変数がMSVCを指すか、CCが設定されていないcgoアプリケーションを構築するだけで、cl.exeはパス上にありますが、gccはそうではありません。

@blizzardplus上記と同様に、レビューでは現在多くのことが流動的であるため、試してみるのは少し早いかもしれません（ただし、あなた次第です）。 関連するすべての変更は、gopherbotによってこの問題に投稿されました。ここで、それらを見つけることができます。

@cchamplinは、 gccまたはclangいずれかを使用したクロスコンパイルのサポートがありますか？ もしそうなら、彼らはテストされていますか？

@cchamplin 9/11以降、CLでの活動は見られません。これについては前進が見られますか、それとも追加のリソースが必要ですか？

これは、その後に行われていない場合は- C-アーカイブctorsセクションが.CRT $ XCU（https://msdn.microsoft.com/en-us/library/bb918180.aspx）に変更されなければならないための作業には、このため@cchamplin golangランタイムは初期化されません。 また、これに設定すると、gccでも正常に機能することがわかります-gcc stilはこれらの関数を取得し、テキストセクションに移動し、mainを変更して実際のmainの前に呼び出します。 Visual Studioは.aアーカイブファイルを理解できます。プリコンパイル/アセンブルされたファイルのインターフェイスはCであるため、これをアーカイブに含めるだけで問題は発生しません。 2つの.textセクションに関する警告がありますが、単純なケースは正常に機能しているようです（問題がないことを確認するためにさらにテストが必要です）。

また、これがc-sharedで機能するためには、エクスポートされる関数を__declspec（dllexport）で装飾する必要がありますが、// exportのこの展開がどこで発生するかがわかりません。

@ blizzardplusclang -MSVCをサポートするためのフォローアップパッチがあります。 この場合、クロスコンパイルとはどういう意味かわかりませんか？ Windows以外のシステムではMSVCツールチェーンを使用できなくなります。 他のクロスコンパイル機能は変更しないでください。

@kshelton残念ながら、私が発表している作品や会議には他のプロジェクトがあるので、これは私にとって非常に忙しい時期です。 12月まで、パッチに必要なリファクタリングを取り戻すことができない場合があります。

@ksheltonありがとう。 パッチを再確認していません。c-archiveがMSVCで機能しない、または具体的に無効にすることを前提に開発したと思いますか？ プラグイン/共有をWindowsで動作させようとしたときに、エクスポートを適切に装飾しようと試みました。 私が信じている他の問題がありますが、私は2つの問題を混同している可能性があります。 ELFとWindows.edata、idata、およびEATのPLT / GOTに共有コードを配置する方法には実際の問題があります。 私が直面した問題のほとんどは、移転とそれを機能させることができないことに関するものだったと思います。 誰かがこれについて洞察を持っているなら、それは素晴らしいでしょう。 ＃19282を参照

@cchamplin私があなたのCLの上にGoを構築できるかどうか見てみました

https://go-review.googlesource.com/c/go/+/133946/3

このバッチファイルを使用して環境を設定しました

set TERM=msys
set MYHOME=c:\users\alex\dev
set GOROOT=%MYHOME%\go
set GOROOT_BOOTSTRAP=%MYHOME%\go1.4.3
set GOPATH=%MYHOME%
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Auxiliary\Build\vcvars64.bat"
set CC=cl
set PATH=%PATH%;%MYHOME%\my\bin\;%GOROOT%\bin
cd %GOROOT%\src
CMD

make.batを実行すると、このエラーが発生します

C:\Users\Alex\Desktop>set TERM=msys

C:\Users\Alex\Desktop>set MYHOME=c:\users\alex\dev

C:\Users\Alex\Desktop>set GOROOT=c:\users\alex\dev\go

C:\Users\Alex\Desktop>set GOROOT_BOOTSTRAP=c:\users\alex\dev\go1.4.3

C:\Users\Alex\Desktop>set GOPATH=c:\users\alex\dev

C:\Users\Alex\Desktop>call "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Auxiliary\Build\vcvars64.bat"
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0.26730.12
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
Microsoft Windows [Version 10.0.17134.407]
(c) 2018 Microsoft Corporation. All rights reserved.

c:\Users\Alex\dev\go\src>make
Building Go cmd/dist using c:\users\alex\dev\go1.4.3
go tool dist: cannot invoke C compiler "cl": exit status 2

Go needs a system C compiler for use with cgo.
To set a C compiler, set CC=the-compiler.
To disable cgo, set CGO_ENABLED=0.

Command output:

Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25507.1 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9002 : ignoring unknown option '--help'
cl : Command line error D8003 : missing source filename

The system cannot find the batch label specified - fail

c:\Users\Alex\dev\go\src>

ここで何が欠けていますか？

ありがとうございました。

アレックス

@alexbrainman

ここで何が欠けていますか？

少なくともCC_FOR_CGO = gccを設定する必要があります。 また、MSVCを使用して自分自身を構築しようとしたこともありません。 これが機能するかどうか/サポートする必要があるかどうかはわかりません。

-NS

少なくともCC_FOR_CGO = gccを設定する必要があります。

https://go-review.googlesource.com/c/go/+/133940には、いくつかのテストが含まれています。 テストに合格したことを確認するにはどうすればよいですか？ 正確な手順は何ですか？

また、Goビルダーhttps://build.golang.orgは％GOROOT％\ src \ all.batを実行して、すべてのテスト（https://go-review.googlesource.com/c/go/+/にリストされているものを含む）を検証します。 133940）合格。 ％GOROOT％\ src \ all.batがhttps://go-review.googlesource.com/c/go/+/133940から調整されたテストを実行するようにGoコードを変更することをどのように提案しますか

また、MSVCを使用して自分自身を構築しようとしたこともありません。 これが機能するかどうか/サポートする必要があるかどうかはわかりません。

gccをインストールしなくても、all.batを実行して正常に完了することができます。 現在のバージョンのGoをビルドするには、別のバージョンのGo（少なくともgo1.4）のみが必要です。 CgoだけがCコンパイラを必要とします、私はあなたの変更がMSVCによって構築されたCgoバージョンを実装しているという印象を受けました。 しかし、おそらく、私は間違っています。 私が間違っている場合は私を訂正してください。

ありがとうございました。

アレックス

@alexbrainman

https://go-review.googlesource.com/c/go/+/133940には、いくつかのテストが含まれています。 テストに合格したことを確認するにはどうすればよいですか？ 正確な手順は何ですか？

おそらく、all.batはgccバージョンとmsvcバージョンの両方のテストをテストできます。 おそらく、実行するテストのバージョンをall.batに指示する環境変数を使用できます。その場合、2つの異なるビルダーに異なるバージョンのテストを実行させることができます。 あなたはそれについてすべて考えましたか？

はい、この正確なメカニズムはhttps://go-review.googlesource.com/c/go/+/133946/で使用されてい

gccをインストールしなくても、all.batを実行して正常に完了することができます。 現在のバージョンのGoをビルドするには、別のバージョンのGo（少なくともgo1.4）のみが必要です。 CgoだけがCコンパイラを必要とします、私はあなたの変更がMSVCによって構築されたCgoバージョンを実装しているという印象を受けました。 しかし、おそらく、私は間違っています。 私が間違っている場合は私を訂正してください。

あなたは正しいです。 Go自体は正常に構築されるはずです。 GOTESTMSVC = 1のときにrun.batがいくつかの環境変数を設定するように変更されたため、テストに到達するときに問題が発生する可能性があります。 goがmsvcでビルドされているかどうかを検出し、テストが失敗しないように適切なdist環境変数を設定することもできます。

次に、GOTESTMSVC = 1およびGOVSVARSPATH = somevsvars.batパスを設定します。 その後、all.batを使用したビルドで、gccテストとmsvccgoテストの両方を実行する必要があります。

やってみました。

使った

commit e56d52f66b95b87001867a2487a11bd961f40d4d (HEAD)
Author: Caleb Champlin <[email protected]>
Date:   Sat Sep 8 00:26:32 2018 -0600

    cmd/compile: add support for MSVC toolchain to go build

    Allows building with MSVC as an external compiler/linker.

    Setting CC=cl.exe inside an MSVC environment will automatically
    build cgo executables using MSVC as the external compiler and
    linker.

    For the builders setting the environment variable GOVSVARSPATH
    to the location of a msvsvars.bat file and setting the
    environment variable GOTESTMSVC=1 will automatically cause
    all.bat to run tests and compiler with both gcc and MSVC.

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

私は最初にこのバッチファイルを実行します：

set TERM=msys
set MYHOME=c:\users\alex\dev
set GOROOT=%MYHOME%\go
set GOROOT_BOOTSTRAP=%MYHOME%\go1.4.3
set GOPATH=%MYHOME%
set MINGW=%MYHOME%\mingw64_4.9.1

set GOTESTMSVC=1
set GOVSVARSPATH="C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Auxiliary\Build\vcvars64.bat"

set PATH=%PATH%;%MINGW%\bin;%MYHOME%\my\bin\;%GOROOT%\bin
cd %GOROOT%\src
CMD

次に、 all.batます。 all.batはで失敗します

--- FAIL: TestDocsUpToDate (0.00s)
    help_test.go:26: alldocs.go is not up to date; run mkalldocs.sh to regenerate it
go test proxy starting
go test proxy running at GOPROXY=http://127.0.0.1:52023/mod
go proxy: no archive w.1 v1.2.0
go proxy: no archive x.1 v1.0.0
go proxy: no archive z.1 v1.2.0
go proxy: no archive rsc.io v1.5.0
go proxy: no archive example.com/unused v0.0.0
go proxy: no archive example.com/unused v0.0.0
go proxy: no archive sub.1 v1.0.0
go proxy: no archive badsub.1 v1.0.0
go proxy: no archive versioned.1 v1.0.0
go proxy: no archive versioned.1 v1.1.0
go proxy: no archive golang.org/x/text/language 14c0d48
go proxy: no archive golang.org/x/text/language 14c0d48
go proxy: no archive golang.org/x/text/language 14c0d48
go proxy: no archive golang.org/x/text/foo 14c0d48
go proxy: no archive golang.org/x 14c0d48
go proxy: no archive golang.org 14c0d48
go proxy: no archive example.com/split/subpkg v1.0.0
FAIL
FAIL    cmd/go  147.247s
ok      cmd/go/internal/cache   13.115s
ok      cmd/go/internal/dirhash 0.518s
ok      cmd/go/internal/generate        0.180s
ok      cmd/go/internal/get     0.761s
ok      cmd/go/internal/imports 0.212s
ok      cmd/go/internal/load    1.050s
ok      cmd/go/internal/modconv 1.596s
ok      cmd/go/internal/modfetch        0.881s
ok      cmd/go/internal/modfetch/codehost       0.179s
ok      cmd/go/internal/modfile 0.193s
ok      cmd/go/internal/modload 2.820s
ok      cmd/go/internal/module  0.860s
ok      cmd/go/internal/mvs     0.255s
ok      cmd/go/internal/par     0.107s
ok      cmd/go/internal/search  0.087s
ok      cmd/go/internal/semver  0.140s
ok      cmd/go/internal/txtar   0.249s
ok      cmd/go/internal/web2    0.136s
ok      cmd/go/internal/work    0.200s
ok      cmd/gofmt       0.216s
ok      cmd/internal/buildid    0.522s
ok      cmd/internal/dwarf      0.077s
ok      cmd/internal/edit       0.160s
ok      cmd/internal/goobj      2.430s
ok      cmd/internal/obj        0.103s
ok      cmd/internal/obj/arm64  0.190s
ok      cmd/internal/obj/x86    0.845s
ok      cmd/internal/objabi     0.063s
ok      cmd/internal/src        0.093s
ok      cmd/internal/test2json  0.253s
ok      cmd/link        6.285s
ok      cmd/link/internal/ld    24.147s
ok      cmd/link/internal/sym   0.887s
ok      cmd/nm  7.678s
ok      cmd/objdump     2.772s
ok      cmd/pack        3.256s
ok      cmd/trace       0.449s
ok      cmd/vendor/github.com/google/pprof/internal/binutils    0.479s
ok      cmd/vendor/github.com/google/pprof/internal/driver      6.103s
ok      cmd/vendor/github.com/google/pprof/internal/elfexec     0.079s
ok      cmd/vendor/github.com/google/pprof/internal/graph       0.455s
ok      cmd/vendor/github.com/google/pprof/internal/measurement 0.066s
ok      cmd/vendor/github.com/google/pprof/internal/report      0.154s
ok      cmd/vendor/github.com/google/pprof/internal/symbolizer  0.096s
ok      cmd/vendor/github.com/google/pprof/internal/symbolz     0.078s
ok      cmd/vendor/github.com/google/pprof/profile      0.527s
ok      cmd/vendor/github.com/ianlancetaylor/demangle   0.109s
ok      cmd/vendor/golang.org/x/arch/arm/armasm 0.424s
ok      cmd/vendor/golang.org/x/arch/arm64/arm64asm     0.537s
ok      cmd/vendor/golang.org/x/arch/ppc64/ppc64asm     0.155s
ok      cmd/vendor/golang.org/x/arch/x86/x86asm 0.239s
ok      cmd/vendor/golang.org/x/crypto/ssh/terminal     0.174s
ok      cmd/vendor/golang.org/x/sys/windows     0.334s
ok      cmd/vendor/golang.org/x/sys/windows/registry    0.199s
ok      cmd/vendor/golang.org/x/sys/windows/svc 0.316s
ok      cmd/vendor/golang.org/x/sys/windows/svc/eventlog        0.089s
ok      cmd/vendor/golang.org/x/sys/windows/svc/mgr     0.432s
ok      cmd/vet 6.392s
ok      cmd/vet/internal/cfg    0.102s
2018/12/16 15:55:18 Failed: exit status 1

また、GOTESTMSVCとGOVSVARSPATHを設定すると、all.batを実行するユーザーに有効な場合があります。 しかし、CgoにMSVCを使用する必要がある場合、変更の他のユーザーは何をしますか？ そのためのあなたの計画は何ですか？

アレックス

@alexbrainman
何が起こっているのかわかりません。 そのテストはマスターで私にとって失敗しています

> git status
On branch master
Your branch is up to date with 'origin/master'

> cd src\cmd\go
> go test .\help_test.go
--- FAIL: TestDocsUpToDate (0.00s)
    help_test.go:26: alldocs.go is not up to date; run mkalldocs.sh to regenerate it

help.go https://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/internal/help/help.go#L37
base.Go.Commandsを繰り返し処理します。 これはmain.goで初期化されますhttps://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/main.go#L43
しかし、そのinit関数がテスト実行可能ファイルでどのように呼び出されるかはわかりません。したがって、これは全面的に失敗するはずなので、マスターが現在どのようにテストに合格しているかわかりません。

また、GOTESTMSVCとGOVSVARSPATHを設定すると、all.batを実行するユーザーに有効な場合があります。 しかし、CgoにMSVCを使用する必要がある場合、変更の他のユーザーは何をしますか？ そのためのあなたの計画は何ですか？

したがって、MSVCを使用してCgoコードをビルドしたいだけの状況では

call vsvars64.bat
set CC_FOR_CGO=gcc
set CC=cl.exe
go build

必要なのはそれだけだと思います

そのinit関数がテスト実行可能ファイルでどのように呼び出されるかわからないので、マスターが現在どのようにテストに合格しているかわかりません。これは全面的に失敗するはずだと思います。

cmd / go内のファイルでgo testを使用する場合、goツールはcmd / goパッケージをビルドしてからテストをビルドし、テストドライバーを生成してビルドし、すべてを新しいメインパッケージにリンクします。 これは、cmd / go自体がメインパッケージである場合でも発生します。 つまり、cmd / go / *。goのメインパッケージは、テストの目的では非メインパッケージとして扱われます。 これにより、必要に応じて、テストでメインパッケージで定義されている関数を呼び出すことができます。

申し訳ありませんが、返信が遅くなります。 しかし、私にはこれをもう一度調べる自由な時間がありませんでした。

何が起こっているのかわかりません。 そのテストはマスターで私にとって失敗しています

マスターは使いませんでした。 私はあなたのe56d52f66b95b87001867a2487a11bd961f40d4dコミットを使用しました。 レビューのために送信する前に、そのコミットでall.batを実行しませんでしたか？ all.batは成功しましたか？ そのコミットでall.batをもう一度実行して、システム構成に関係があるかどうかを確認できますか。 ありがとうございました。

したがって、MSVCを使用してCgoコードをビルドしたいだけの状況では

call vsvars64.bat
set CC_FOR_CGO=gcc
set CC=cl.exe
go build

必要なのはそれだけだと思います

2つの環境変数は、おそらく、平均的なユーザーには複雑すぎます。 そして、 CC_FOR_CGO=gccは私には奇妙に見えます-なぜMSVCでコードをビルドするためにgccを使用するのですか？

アレックス

@alexbrainman

マスターは使いませんでした。 私はあなたのe56d52f66b95b87001867a2487a11bd961f40d4dコミットを使用しました。 レビューのために送信する前に、そのコミットでall.batを実行しませんでしたか？ all.batは成功しましたか？ そのコミットでall.batをもう一度実行して、システム構成に関係があるかどうかを確認できますか。 ありがとうございました。

テストを実行したときに奇妙な結果が得られたのは、私のシステム構成と関係があると思います。 私は問題を修正し、変更セットにいくつかの更新をプッシュしたと思います。

2つの環境変数は、おそらく、平均的なユーザーには複雑すぎます。 そして、CC_FOR_CGO = gccは私には奇妙に見えます-なぜMSVCでコードをビルドするためにgccを使用するのですか？

私の間違いですが、実際にはおそらくCC_FOR_CGO = gcc.exeであるはずです。 しかし、あなたの質問に答えるために; gerritから：

PS1、1324行目：
cgoには、型分析に使用できるgccがまだ必要です。 CCがMSVCコンパイラに設定されている場合、cgoにはCC_FOR_CGOによって提供されるGCCを呼び出す手段が必要です。 残念ながら、MSVCツールチェーンには、gccから収集されているのと同じタイプの情報を提供するメカニズムがありません。 理論的には、cgoで使用される型情報を収集するために、go固有のツールを作成できますが、範囲外であり、かなりの労力がかかる可能性があります（C / C ++コードの静的型分析を実行するために個人的に何かを書いたことはありません）。

また、GCCとMSVCの実行の間にキャッシュがクリアされた状態で何かが壊れたようですが、一部のテストがまだキャッシュされているかのように動作している理由がわかりません。

私は問題を修正し、変更セットにいくつかの更新をプッシュしたと思います。

このセットアップhttps://github.com/golang/go/issues/20982#issuecomment-447618566 on

commit 5479fc9fe61fb998082fea5cb423314cc1afa649 (HEAD)
Author: Caleb Champlin <[email protected]>
Date:   Sat Sep 8 00:26:32 2018 -0600

    cmd/compile: add support for MSVC toolchain to go build

    Allows building with MSVC as an external compiler/linker.

    Setting CC=cl.exe inside an MSVC environment will automatically
    build cgo executables using MSVC as the external compiler and
    linker.

    For the builders setting the environment variable GOVSVARSPATH
    to the location of a msvsvars.bat file and setting the
    environment variable GOTESTMSVC=1 will automatically cause
    all.bat to run tests and compiler with both gcc and MSVC.

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

私をさらに連れて行きますが、それでも失敗します

##### API check
+pkg go/build, type Context struct, CompilerType string
+pkg go/build, type Package struct, CgoMSCFLAGS []string
+pkg go/build, type Package struct, CgoMSCPPFLAGS []string
+pkg go/build, type Package struct, CgoMSCXXFLAGS []string
+pkg go/build, type Package struct, CgoMSLDFLAGS []string
+pkg os, method (*File) SyscallConn() (syscall.RawConn, error)

ALL TESTS PASSED

**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0.26730.12
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

# runtime/cgo
msvc_libinit_windows.c
msvc_libinit_windows.c(133): error C2220: warning treated as error - no 'object' file generated
msvc_libinit_windows.c(133): warning C4710: 'int fprintf(FILE *const ,const char *const ,...)': function not inlined
C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\ucrt\stdio.h(826): note: see declaration of 'fprintf'
go tool dist: FAILED: go install -gcflags=all= -ldflags=all= std cmd: exit status 2

c:\Users\Alex\dev\go\src>

私の間違いですが、実際にはおそらくCC_FOR_CGO = gcc.exeであるはずです。

gcc.exeの.exeについては気にしません。 私の問題は

• MSVCを使用するにはgccツールとMSVCツールの両方が必要です（ユーザーに説明するのは難しいでしょう）が、それについては何もできないことを理解しています。

• 両方の環境変数CC_FOR_CGO = gccとCC = cl.exeを設定する必要がありました-CC_FOR_CGOが常にgccに設定されていると仮定できますか？

しかし、あなたの質問に答えるために; gerritから：

説明ありがとうございます。

アレックス

@alexbrainman

# runtime/cgo
msvc_libinit_windows.c
msvc_libinit_windows.c(133): error C2220: warning treated as error - no 'object' file generated
msvc_libinit_windows.c(133): warning C4710: 'int fprintf(FILE *const ,const char *const ,...)': function not inlined
C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\ucrt\stdio.h(826): note: see declaration of 'fprintf'
go tool dist: FAILED: go install -gcflags=all= -ldflags=all= std cmd: exit status 2

どういうわけかmsvc_libinit_windows.cの別の/古いコピーを持っていない限り、その警告がどのように発生するかはわかりません。 この行が含まれていることを確認できますか？

// src/runtime/cgo/msvc_libinit_windows.c
#pragma warning(disable:4668 4255 4710)

stdioインクルードではC4710を抑制する必要があります。 あなたのバージョンのMSVCは私のバージョンとは少し異なっているようですが、これも原因である可能性があります。 しかし、なぜ彼らが別のバージョンでその抑制を積極的に無視するのかはわかりません。

また、何があってもグローバルに抑制を含めるように変更を加えることもできます

// src/cmd/go/internal/work/exec.go
// Line 2719
cgoMSCPPFLAGS = append(cgoMSCFLAGS, "/wd4668") // this should be cgoMSCFLAGS = append(cgoMSCFLAGS, "/wd4668") I'll fix the change set to correct
+cgoMSCFLAGS = append(cgoMSCFLAGS, "/wd4710") 

両方の環境変数CC_FOR_CGO = gccとCC = cl.exeを設定する必要がありました-CC_FOR_CGOが常にgccに設定されていると仮定できますか？

CC_FOR_CGOが設定されていない場合にgccが存在するかどうかをgcoがチェックするのは問題ないと思います。 CC_FOR_CGOは、パスにgccがない私のような人々のためのものです。 私のCC_FOR_CGOは、CC_FOR_CGO = I：\ Development \ tmd-gcc \ bingcc.exeのようになります。 GCCがMSVCビルドのパス上にないというユースケースをサポートしたくない場合は、私に知らせてください。環境変数をまとめて取り除くことができます。

このバージョンをもう一度試しました

commit 6741b7009d1894b5bf535d82ad46f4a379651670 (HEAD)
Author: Caleb Champlin <[email protected]>
Date:   Sat Sep 8 00:26:32 2018 -0600

    cmd/compile: add support for MSVC toolchain to go build

    Allows building with MSVC as an external compiler/linker.

    Setting CC=cl.exe inside an MSVC environment will automatically
    build cgo executables using MSVC as the external compiler and
    linker.

    For the builders setting the environment variable GOVSVARSPATH
    to the location of a msvsvars.bat file and setting the
    environment variable GOTESTMSVC=1 will automatically cause
    all.bat to run tests and compiler with both gcc and MSVC.

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

同じエラーが発生します

##### API check
+pkg go/build, type Context struct, CompilerType string
+pkg go/build, type Package struct, CgoMSCFLAGS []string
+pkg go/build, type Package struct, CgoMSCPPFLAGS []string
+pkg go/build, type Package struct, CgoMSCXXFLAGS []string
+pkg go/build, type Package struct, CgoMSLDFLAGS []string
+pkg os, method (*File) SyscallConn() (syscall.RawConn, error)

ALL TESTS PASSED

**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0.26730.12
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

# runtime/cgo
msvc_libinit_windows.c
msvc_libinit_windows.c(133): error C2220: warning treated as error - no 'object' file generated
msvc_libinit_windows.c(133): warning C4710: 'int fprintf(FILE *const ,const char *const ,...)': function not inlined
C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\ucrt\stdio.h(826): note: see declaration of 'fprintf'
go tool dist: FAILED: go install -gcflags=all= -ldflags=all= std cmd: exit status 2

c:\Users\Alex\dev\go\src>

この行が含まれていることを確認できますか？

// src/runtime/cgo/msvc_libinit_windows.c
#pragma warning(disable:4668 4255 4710)

これは私のsrc / runtime / cgo /msvc_libinit_windows.cファイルの始まりです

// Copyright 2018 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

// +build cgo

#define WIN64_LEAN_AND_MEAN
// Suppress MSVC specific warnings.
// C4668: symbol' is not defined as a preprocessor macro, 
// replacing with '0' for 'directives'.
// C4255: function' : no function prototype given: converting '()' 
// to '(void)'.
// C4710: function' : function not inlined
#pragma warning(disable:4668 4255 4710)
#include <windows.h>
#include <process.h>
...

また、何があってもグローバルに抑制を含めるように変更を加えることもできます

// src/cmd/go/internal/work/exec.go
// Line 2719
cgoMSCPPFLAGS = append(cgoMSCFLAGS, "/wd4668") // this should be cgoMSCFLAGS = append(cgoMSCFLAGS, "/wd4668") I'll fix the change set to correct
+cgoMSCFLAGS = append(cgoMSCFLAGS, "/wd4710") 

私はこの変更を行いました：

c:\Users\Alex\dev\go\src>git diff
diff --git a/src/cmd/go/internal/work/exec.go b/src/cmd/go/internal/work/exec.go
index 49d1d849f5..9fb442ab95 100644
--- a/src/cmd/go/internal/work/exec.go
+++ b/src/cmd/go/internal/work/exec.go
@@ -2717,6 +2717,7 @@ func (b *Builder) cgo(a *Action, cgoExe, objdir string, pcCFLAGS, pcMSCFLAGS, pc
        cgoLDFLAGS = append(cgoLDFLAGS, pcLDFLAGS...)
        if cfg.BuildContext.CompilerType == "msvc" {
                cgoMSCFLAGS = append(cgoMSCFLAGS, "/wd4668")
+               cgoMSCFLAGS = append(cgoMSCFLAGS, "/wd4710")

                cgoMSCPPFLAGS = append(cgoMSCPPFLAGS, pcMSCFLAGS...)
                cgoMSCPPFLAGS = append(cgoMSCPPFLAGS, "/c")

c:\Users\Alex\dev\go\src>

しかし、同じエラーが表示されます

##### API check
+pkg go/build, type Context struct, CompilerType string
+pkg go/build, type Package struct, CgoMSCFLAGS []string
+pkg go/build, type Package struct, CgoMSCPPFLAGS []string
+pkg go/build, type Package struct, CgoMSCXXFLAGS []string
+pkg go/build, type Package struct, CgoMSLDFLAGS []string
+pkg os, method (*File) SyscallConn() (syscall.RawConn, error)

ALL TESTS PASSED

**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0.26730.12
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

# runtime/cgo
msvc_libinit_windows.c
msvc_libinit_windows.c(133): error C2220: warning treated as error - no 'object' file generated
msvc_libinit_windows.c(133): warning C4710: 'int fprintf(FILE *const ,const char *const ,...)': function not inlined
C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\ucrt\stdio.h(826): note: see declaration of 'fprintf'
go tool dist: FAILED: go install -gcflags=all= -ldflags=all= std cmd: exit status 2

c:\Users\Alex\dev\go\src>

アレックス

私は昨夜これを再現しようとしていましたが、再現できませんでした。 あなたがこれを経験しているかどうか疑問に思います： https ：

最新のSDKおよびビルドツールに更新することは可能ですか？ SDK10.0.17763.0を使用しています。 およびビルドツール/ devenvのバージョン15.9.28307.222

MSVCを使用してWindowsDLLを構築しようとしていますが、Goが65535を超える（または番号ではない）警告を無効にしようとしているため、MSVCが停止しているようです。

いいえ。 WerrorはGCCオプションであり、すべての警告をエラーとして扱います。

MSVCの場合、 WXを使用する必要があります。

@pravic良い点、どうすればいいですか？ 私はそれを設定していません、私がしているのは：

set CC=cl.exe
go build -o next.dll .\main.go

@galich残念ながら、MSVCの統合に従わないため、仕方がありません。

たとえば、このスレッドに関連するパッチはどこにありますか？ マスターか他のどこかで？

@pravicここで変更を見つけることができます： https ： //go-review.googlesource.com/c/go/+/133946/5

@mxplusbリンクに感謝します、/ Werrorに関する私の特定の問題はそこで解決されているようです。
これがいつベータ版/毎晩/安定版になるか知っていますか？

最新のSDKおよびビルドツールに更新することは可能ですか？ SDK10.0.17763.0を使用しています。 およびビルドツール/ devenvのバージョン15.9.28307.222

@cchamplinついに、MSVCを更新することができました。 私が今持っています

c:\Users\Alex\dev\go\src>%GOVSVARSPATH%
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

c:\Users\Alex\dev\go\src>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27030.1 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

c:\Users\Alex\dev\go\src>

このバージョンをもう一度試しました

commit 6741b7009d1894b5bf535d82ad46f4a379651670 (HEAD)
Author: Caleb Champlin <[email protected]>
Date:   Sat Sep 8 00:26:32 2018 -0600

    cmd/compile: add support for MSVC toolchain to go build

    Allows building with MSVC as an external compiler/linker.

    Setting CC=cl.exe inside an MSVC environment will automatically
    build cgo executables using MSVC as the external compiler and
    linker.

    For the builders setting the environment variable GOVSVARSPATH
    to the location of a msvsvars.bat file and setting the
    environment variable GOTESTMSVC=1 will automatically cause
    all.bat to run tests and compiler with both gcc and MSVC.

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

そしてall.batは正常に完了します。 しかし、私はこれらの警告を受け取ります。

##### ../misc/cgo/stdio

##### ../misc/cgo/life

##### ../misc/cgo/test
# _/c_/Users/Alex/dev/go/misc/cgo/test
issue28896.cgo2.c
.\issue28896.go(30): warning C4820: '<anonymous-tag>': '4' bytes padding added after data member 'g1'
.\issue28896.go(36): warning C4820: '<anonymous-tag>': '4' bytes padding added after data member 'f2'
# _/c_/Users/Alex/dev/go/misc/cgo/test
cthread_windows.c
c:\users\alex\dev\go\misc\cgo\test\cthread_windows.c(39) : warning C5045: Compiler will insert Spectre mitigation for memory load if /Qspectre switch specified
c:\users\alex\dev\go\misc\cgo\test\cthread_windows.c(37) : note: index 'i' range checked by comparison on this line
c:\users\alex\dev\go\misc\cgo\test\cthread_windows.c(39) : note: feeds call on this line
PASS
scatter = 00007FF670706000
hello from C
sqrt is: 0
ok      _/c_/Users/Alex/dev/go/misc/cgo/test    3.534s
# _/c_/Users/Alex/dev/go/misc/cgo/test
issue28896.cgo2.c
.\issue28896.go(30): warning C4820: '<anonymous-tag>': '4' bytes padding added after data member 'g1'
.\issue28896.go(36): warning C4820: '<anonymous-tag>': '4' bytes padding added after data member 'f2'
# _/c_/Users/Alex/dev/go/misc/cgo/test
cthread_windows.c
c:\users\alex\dev\go\misc\cgo\test\cthread_windows.c(39) : warning C5045: Compiler will insert Spectre mitigation for memory load if /Qspectre switch specified
c:\users\alex\dev\go\misc\cgo\test\cthread_windows.c(37) : note: index 'i' range checked by comparison on this line
c:\users\alex\dev\go\misc\cgo\test\cthread_windows.c(39) : note: feeds call on this line
PASS
scatter = 00007FF7DD026000
hello from C
sqrt is: 0
ok      _/c_/Users/Alex/dev/go/misc/cgo/test    3.229s
# _/c_/Users/Alex/dev/go/misc/cgo/test
issue28896.cgo2.c
.\issue28896.go(30): warning C4820: '<anonymous-tag>': '4' bytes padding added after data member 'g1'
.\issue28896.go(36): warning C4820: '<anonymous-tag>': '4' bytes padding added after data member 'f2'
# _/c_/Users/Alex/dev/go/misc/cgo/test
cthread_windows.c
c:\users\alex\dev\go\misc\cgo\test\cthread_windows.c(39) : warning C5045: Compiler will insert Spectre mitigation for memory load if /Qspectre switch specified
c:\users\alex\dev\go\misc\cgo\test\cthread_windows.c(37) : note: index 'i' range checked by comparison on this line
c:\users\alex\dev\go\misc\cgo\test\cthread_windows.c(39) : note: feeds call on this line
PASS
scatter = 00007FF655CF6000
hello from C
sqrt is: 0
ok      _/c_/Users/Alex/dev/go/misc/cgo/test    3.172s

##### ../test/bench/go1
testing: warning: no tests to run
PASS
ok      _/c_/Users/Alex/dev/go/test/bench/go1   3.178s

##### ../test

##### API check
+pkg go/build, type Context struct, CompilerType string
+pkg go/build, type Package struct, CgoMSCFLAGS []string
+pkg go/build, type Package struct, CgoMSCPPFLAGS []string
+pkg go/build, type Package struct, CgoMSCXXFLAGS []string
+pkg go/build, type Package struct, CgoMSLDFLAGS []string
+pkg os, method (*File) SyscallConn() (syscall.RawConn, error)

ALL TESTS PASSED

---
Installed Go for windows/amd64 in c:\Users\Alex\dev\go
Installed commands in c:\Users\Alex\dev\go\bin
*** You need to add c:\Users\Alex\dev\go\bin to your PATH.

c:\Users\Alex\dev\go\src>

また、すべてのテストを2回実行していることに気づきました。

...
##### API check
+pkg go/build, type Context struct, CompilerType string
+pkg go/build, type Package struct, CgoMSCFLAGS []string
+pkg go/build, type Package struct, CgoMSCPPFLAGS []string
+pkg go/build, type Package struct, CgoMSCXXFLAGS []string
+pkg go/build, type Package struct, CgoMSLDFLAGS []string
+pkg os, method (*File) SyscallConn() (syscall.RawConn, error)

ALL TESTS PASSED

**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'


##### Testing packages.
ok      archive/tar     0.256s
ok      archive/zip     2.070s
ok      bufio   (cached)
ok      bytes   1.624s
ok      compress/bzip2  (cached)
ok      compress/flate  1.067s
...

どうして？

アレックス

@alexbrainmanこれらのテスト、特にこの場合はスペクターの警告では、警告を抑制できる可能性があります。

2回実行されるテストの場合、ビルダーに対してそのように実行されたと思います。gccコンパイルでテストを1回実行し、MSVC（有効な場合）でテストを再度実行して、両方のツールチェーンでのコンパイルが機能することを確認します。 ここで何が必要かわからないので、MSVCを有効にしてall.batを呼び出すと、MSVCでのみテストを実行するように変更できます。お知らせください。 その場合、MSVCでビルドするビルダーとは対照的に、MSVCだけに追加のビルダーを追加する必要があると思いますか？

Windowsでは、両方のシナリオをテストするために、MinGW-W64ツールチェーンを使用して1つのビルダーを実行し、MSVCツールチェーンを使用して別のビルダーを実行する必要があることに同意しました。

ビルダーではそのように行われたと思います。gccコンパイルでテストを1回実行し、次にMSVC（有効な場合）でテストを再度実行して、両方のツールチェーンでのコンパイルが機能することを確認します。

両方のツールチェーンが存在する場合に既存のワークロードを壊さないことが保証されるように、これが推奨される動作であることに同意します。

警告は、これらのテスト、特にこの場合はスペクター警告で抑制される可能性があります。

Goコマンドは警告を表示しないため、警告は表示されません。

また、 go envコマンドがCC_FOR_CGO変数を表示しないことに気づきました。 CC_FOR_CGOがgoビルドの動作に影響を与える場合は、CC_FOR_CGOを他の人と一緒に表示する必要があります。 本当にCC_FOR_CGO変数が必要ですか？ 他に何がありますが、CC_FOR_CGO = gccでしょうか？

2回実行されるテストの場合、ビルダーに対してそのように実行されたと思います。gccコンパイルでテストを1回実行し、MSVC（有効な場合）でテストを再度実行して、両方のツールチェーンでのコンパイルが機能することを確認します。

多くのテストはgccを使用していません。 パッケージテストが理由もなく2回実行されるのは、人やコンピューターの時間の無駄です。 https://github.com/golang/go/issues/20982#issuecomment -480569880からわかるように、 archive/zipパッケージテストが2回実行されました-2回目の実行の必要はありません。

それをどのように調整するかはわかりませんが、run.batのgo tool dist test呼び出しを置き換えて、MSVCビルドのテストに必要なテストの選択だけを実行する必要があります。 たとえば、特定のテストだけを選択する方法については、 go tool dist test -hを@bradfitzは、distコマンドにMSVC固有のテストを実行するように指示するフラグまたは環境変数を作成できる可能性があります。

しかし、一般的にあなたのhttps://go-review.googlesource.com/c/go/+/133946/5は私のために実行可能ファイルを構築しています。 たとえば、gccを使用して実行可能ファイルをビルドできます。

c:\Users\Alex\dev\src\issue\go\20982\hello>type *

hello.c


#include <stdio.h>

extern void hello()
{
    printf("Hello World from C");
}

hello.go


package main

/*
        extern void hello();
*/
import "C"
import "fmt"

func main() {
    fmt.Println("Hello from Go!")
        C.hello()
}

c:\Users\Alex\dev\src\issue\go\20982\hello>go build

c:\Users\Alex\dev\src\issue\go\20982\hello>hello
Hello from Go!
Hello World from C
c:\Users\Alex\dev\src\issue\go\20982\hello>

その後、MSVCで実行可能ファイルをビルドできます

c:\Users\Alex\dev\src\issue\go\20982\hello>%GOVSVARSPATH%
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

c:\Users\Alex\dev\src\issue\go\20982\hello>set CC=cl

c:\Users\Alex\dev\src\issue\go\20982\hello>go build
# issue/go/20982/hello
hello.c
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\stdio.h(948): warning C4710: 'int printf(const char *const ,...)': function not inlined
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\stdio.h(948): note: see declaration of 'printf'

c:\Users\Alex\dev\src\issue\go\20982\hello>hello
Hello from Go!
Hello World from C
c:\Users\Alex\dev\src\issue\go\20982\hello>

したがって、MSVCを使用してビルドするには、ユーザーがMSバッチファイルを実行してすべての環境変数を設定する必要があります（出力のGOVSVARSPATHを参照）。これは標準であり、Goとは関係ありません。 そしてset CC=cl 。 十分に単純です。

このアプローチで私が目にする唯一の問題は、MSVCユーザーがまだgccをインストールする必要があるということです。 gccは、すべてのCインターフェイスを検出するためにcmd / cgoによって使用されます。この部分は、MSVCを使用して実装されていません。 cmd / cgoがどのように機能するかを知らない人にとっては珍しいように聞こえますが、それが何であるかです。

@ianlancetaylorと@bradfitzは、これを前進させるのにすべて合理的に聞こえますか？ これをgo1.13で利用できるようにする必要がありますか？

MSVCが既にインストールされているビルダーは、すべての新しいコードをテストできます。 他のビルダーはテストをスキップします。

アレックス

gccは、すべてのCインターフェイスを検出するためにcmd / cgoによって使用されます。この部分は、MSVCを使用して実装されていません。

どうすればそれを克服できますか？ 理想的には、gccの要件がなく、MSVCだけが必要な場合に最適です。

どうすればそれを克服できますか？

gccを使用するcmd / cgoの部分は、MSVCを使用するように書き直す必要があります。 もし可能ならば。

アレックス

この機能が本番環境に近いのではないかと思っていましたか？ 1.13のタグが付けられていて、それが出たばかりです。 拡張コードにリンクされているGoc-archiveビルドを使用してPython拡張機能をビルドしようとしていますが、PythonにはMSVCが必要です。

この問題の状況がわかりません。 リリースからリリースへとキックフォワードされているので、計画外に移動します。 1.14に入ると、すばらしい。

ダブルコンパイラの要件があっても、現在の実装が次のリリースに組み込まれることを望んでいます。 少なくとも、MSVCを使用して実行可能ファイル/ライブラリをコンパイルすることが可能になります。これは何もないよりはましです。

ダブルコンパイラの要件があっても、現在の実装が次のリリースに組み込まれることを望んでいます。

これは良い「ベータ」実装になると思います。 これにより、バグがフラッシュされ、実装が成熟し始めることができます。 深刻なレビューを受ける前に、他に何をする必要がありますか？

したがって、私の観点から、そしてこれを最後に見たとき（〜6か月前）から思い出すことができることから、コードレビュープロセスのために完了する必要のあるクリーンアップ項目が12個ほどありました。 別のツールチェーンで動作するように非常に小さな変更を加えて基本的にコピーされた一部のテストを重複排除するには、追加の作業が必要になる場合もあります。 特定のmsvc警告を確認してオフにする必要もあります。

主な未解決の問題は次のとおりです。

gccなしで型分析を行うことはできません。これに対する簡単な、または即時の解決策はありません。

セットアップを完了し、ビルダーにとってすべてがどのように機能するかを確認します。

過去6か月間にコンパイラとリンカーにかなり重要な変更が加えられ、これに対して行われている現在の作業に深刻な影響を与える可能性があると思いますが、それを確認することはできませんでした。 Goのコンパイラ/リンカー/ツールチェーンのナビゲートに関する複雑さと高い学習曲線のために、変更がこの一連の作業に与える影響を把握するのに十分な速度に達するには、かなりの時間がかかる場合があります。

複雑な数値型はサポートされていません。 MSCVのClibは単に互換性がありません。 これをC ++でシムする方法はおそらくあると思いますが、MSVCツールチェーンに精通しているMSの誰かがチャイムを鳴らすことができるかどうかはわかりません。

残念ながら、人生や他のプロジェクトは、私がこれにもっと時間を費やすのをかなり大きく妨げていますが、私は今後数週間でこれに時間を費やすつもりです。

@manbearianこの問題は、golangにMSVCサポートを追加することに関するものです。 MSVCチームの誰がMSVCの質問について相談するのが良いでしょうか？

@ kesmit13および@mxplusb

この

https://go-review.googlesource.com/c/go/+/133946/5

動作する@cchamplin最新のコードです。

コードに関する私の現在の懸念は、それを使用する方法が不明確であるということです。 どのコマンドを実行しますか？ 環境をどのように設定する必要がありますか？

次のステップは、誰かがそのコードを試して使用し、実際に使用できるかどうかを確認することだと思います。 それが機能する場合は、他の人もコードを使用できるように、手順を文書化する必要があります。 多分それは複雑すぎるか、機能しません。 それに応じてコードを調整する必要があります。

コードの現在の状態に満足したら、マスターにリベースする必要があります。 変更が調整されたさまざまなファイルが多すぎるため、リベースするのは簡単ではありません。 変更を調整して変更を少なくすることができるので、リベースが簡単になります。

アレックス

@mxplusb @ kesmit13現在の実装はマスターに対してリベースされており、ここで見つけることができます： https ：//go-review.googlesource.com/c/go/+/133946/6

@alexbrainman

コードに関する私の現在の懸念は、それを使用する方法が不明確であるということです。 どのコマンドを実行しますか？ 環境をどのように設定する必要がありますか？

これの使用方法に関するドキュメントを追加する必要があることに同意します。 どこに置けばいいのかよくわかりませんが、考えがあれば教えてください。 Idkは、MSVCを介してビルド/実行するためにcmd / goドキュメントの下に配置する必要があるのか​​、CGOドキュメントの下に配置する必要があるのか​​、あるいは完全に別の場所に配置する必要があるのでしょうか。

多くのテストはgccを使用していません。 パッケージテストが理由もなく2回実行されるのは、人やコンピューターの時間の無駄です。 ＃20982（コメント）からわかるように、アーカイブ/ zipパッケージのテストは2回実行されました-2回目の実行の必要はないと思います。

それをどのように調整するかはわかりませんが、MSVCビルドをテストするために必要なテストの選択だけを行うために、run.batのgo tool disttestの呼び出しを置き換える必要があるかもしれません。 たとえば、特定のテストだけを選択する方法については、go tool dist test-hを参照してください。 @bradfitzは、distコマンドにMSVC固有のテストを実行するように指示するフラグまたは環境変数を作成できる可能性があります。

この変更には、MSVCの処理を実行していることを通知するためにdistに追加された環境変数「GO_TEST_TESTINGMSVC」がすでに含まれていると思います。 私がよくわからないのは、すべてのテストを2回実行しなかった場合に、MSVCだけが影響を与える可能性のあるものに実行されるテストをどのようにフィルタリングするかです。 潜在的にはCGO関連のテストに限定するだけですが、CGOテストはいたるところにあると思いますが、distにそれらを除外するメカニズムがあるかどうかわかりません。

どこに置けばいいのかよくわかりませんが、考えがあれば教えてください。

ドキュメントを更新する前に、MSVCを使用してCgoコードをビルドする方法をここで説明する必要があると思います。 @mxplusbと@ kesmit13の場合は、変更を試すことができます。

たとえば、gccを使用してCgoコードをビルドするには、

1. ％PATH％を調整してgcc.exeを含めます
2. %GOROOT%\srcディレクトリからmake.batを実行して最初にビルドします
3. 標準のgo buildおよびgo installコマンドを使用する

MSVCで同じことをするにはどうすればよいですか？

私がよくわからないのは、すべてのテストを2回実行しなかった場合に、MSVCだけが影響を与える可能性のあるものに実行されるテストをどのようにフィルタリングするかです。 潜在的にはCGO関連のテストに限定するだけですが、CGOテストはいたるところにあると思いますが、distにそれらを除外するメカニズムがあるかどうかわかりません。

％GOROOT％\ misc \ cgoディレクトリから始めます。 そこで構築できるソースが何であれ、構築する必要があります。 それ以上のものはあなた次第です。

アレックス

@cchamplinこれが遅れて申し訳ありませんが、今週はテストしてどうなるかをお知らせするために最善を尽くします。

こんにちは、パーティーに遅れて申し訳ありません... MSVCの機能に関する質問に答えたり、できる人に案内したりできます。 会話を読み通しましたが、残念ながら、MSVCにない場合とない場合がある必要なGCC機能を理解するのに十分な知識がありません。

こんにちはフォークス、
この機能はGo1.14でリリースされましたか？
リリースされた場合は、利用可能なドキュメントを共有して利用してください。
まだリリースされていない場合、いつリリースされるかについて何か考えはありますか？
MSVCのサポートを熱心に待っています。
前もって感謝します ：）

こんにちは、誰も私の詳細情報の要求に応答しなかったので、何が必要かわかりません。 誰かが私に記入してもらえますか？

残念ながら、誰かがこの問題に積極的に取り組んでいるかどうかはわかりません。

こんにちは、誰も私の詳細情報の要求に応答しませんでした...

こんにちは@manbearian

それはどのリクエストですか？ どのような情報が必要ですか？

アレックス

私はこのスレッドの前半で情報のためにタグ付けされましたが、人々が何を探しているのかわからず、助けることができませんでした。 助けが必要ないなら、それは素晴らしいことです。 教えてください。

教えてください。

@manbearian

あなたの申し出をありがとう。 誰があなたにタグを付けたのかわかりません。 それでも助けが必要な場合は、再度タグを付けます。

アレックス

まだリリースされていない場合、いつリリースされるかについて何か考えはありますか？
MSVCのサポートを熱心に待っています。

@ dhinesherode91

コードはそこにあり、完全です。 これを本当に妨げているのは、変更をテストしてフィードバックを提供し、適切にレビューして承認できるようにすることだけだと思います。 しかし、私は現在のマスターの上に変更をリベースすることを躊躇しています。 私はそれを5〜6回実行しましたが、非常に時間がかかり、テストやフィードバックが得られません。 追加の関係者がこれのテストに参加する意思がない限り、問題は水中で死んでいる可能性があります。

追加の関係者がこれのテストに参加する意思がない限り、問題は水中で死んでいる可能性があります。

@cchamplinは、変更をテスト/デバッグするために私を頼りにしています。 ツールチェーンを使用した経験はありませんが、コミットを確認しました。コミットは非常によく構成され、文書化されているようです。

@cchamplin実装部分が完了したと聞いて
私はテストの部分に参加することに興味がありますが、私はGoLangの初心者であり、Windows API（数週間前に開始）の優れた学習者でもあります。 多くの公式リソースが利用できるように見えるので、MS C ++でWindowsAPIを使用することを計画していました。 しかし、その後、マルチプラットフォームシステムプログラミングに使用できる言語（システムプログラミング用）を探し始め、GoLangに感銘を受けました。 常に私の側からの貢献の準備ができており、多くの指導が必要です。

@cchamplinリベースする場合は、その上に構築してみます。 作業中のいくつかのプロジェクトからmingw64要件を削除したいと思います。 私のビルドツールはすべてMSVC用にセットアップされているので、パッチを使用する以外に何もする必要はありません。

@cchamplinも、

@ericlagergren

@cchamplinも、

私が理解しているかどうかはわかりませんが、 https： //go-review.googlesource.com/c/go/+/133946/6で、関連するコミットの多くは、ある程度の容量でGoのcgo部分に直接触れています。

@ccahoonわかりました、私はそれらを逃したに違いありません。 cgoツールが更新されていない場合は、更新することを提案しました。

@ericlagergren

作業中のいくつかのプロジェクトからmingw64要件を削除したい

参考までに。 NS

https://go-review.googlesource.com/c/go/+/133946/6

変更を行うには、Mingwが必要です。 @cchamplinの変更を使用するには、MingwツールとMSVCツールの両方をインストールする必要があります。

アレックス

@cchamplin 、なぜMingwがまだ必要なのですか？ この依存関係を削除するには何が必要ですか？

@alexbrainman私は間違って話しました。 非MSVCビルドプロセスにはautotoolsが必要なため、現時点ではMSYS2（mingw64を含む）を使用する必要があります。 それを削除すると素晴らしいだろう。 しかし、 @ cglongが言ったように、なぜこれにもmingw64が必要になるのかわかりません。

@ericlagergren @cglong CGOは、コンパイルに使用されているCコードに関する型情報を収集して利用できるようにする必要があります。 GCCには、タイプデータを便利に解析可能な形式で出力するフラグがあります。 私の知る限り、MSVCには同じ情報を提供する機能がありません。 goでツールを構築するには、CおよびC ++コードをlex /解析するためのコードだけでなく、プリプロセッサディレクティブを理解して評価するためのコードも必要になります。 Goでそのようなものを構築することはかなり大きな仕事になるでしょう。 おそらくどこかにすでに利用可能なライブラリがありますが、それを採用する方法を理解することはできますか？

@cchamplin gotcha、それが私が考えたものです。 libclangやcznic / ccのようなサードパーティのライブラリを知っています。 しかし残念ながら、libclangは巨大であり、cznic / ccはWindowsまたはmacOSでテストされていません。 PDBは十分な情報を提供していませんか？

CGOは、コンパイルに使用されているCコードに関するタイプ情報を収集して利用できるようにする必要があります。 GCCには、タイプデータを便利に解析可能な形式で出力するフラグがあります。 私の知る限り、MSVCには同じ情報を提供する機能がありません。

おそらく@manbearianはここにいくつかのポインタを提供できるかもしれませんか？

GCCが出力型データを特別な形式で出力するとは言えません。 デバッガー向けのDWARFデバッグデータを出力し、cgoはdebug / dwarfパッケージを使用してそのデータを読み取ります。 MSVCにはおそらくデバッグ形式もあります。 その形式がどこかに文書化されている場合は、DWARFデータと同じようにcgoを使用して読み取ることができます。

@ianlancetaylorMSVCはPDBファイルをhttps://github.com/Microsoft/microsoft-pdbを参照して

FWIW、MSVCのデバッグ出力を読むことは、 https： //github.com/golang/go/issues/20982#issuecomment-648462003でcgoツールについて言及したときに私が話していたことです

GCCが出力型データを特別な形式で出力するとは言えません。 デバッガー向けのDWARFデバッグデータを出力し、cgoはdebug / dwarfパッケージを使用してそのデータを読み取ります。 MSVCにはおそらくデバッグ形式もあります。 その形式がどこかに文書化されている場合は、DWARFデータと同じようにcgoを使用して読み取ることができます。

@ericlagergren @ianlancetaylor
したがって、その大部分であるDWARFデータが必要です。 ただし、理論的にはPDBデータから同じ情報を取得できます。

ただし、私が具体的に言及したのは、GCCが生成するDWARFデータだけでなく、前処理が行われた後にすべての#defineを出力するgcc -E-dMの出力でした。 PDB自体が同じ情報を提供する可能性があります...私が疑っているのは、実際にコンパイルしなくても、MSVCにデバッグ情報/タイプ情報を任意の容量でダンプさせることができるかどうかです。コード。 現在、CGOはGCCでまさにそれを行っています。

/ EP / d1PPは、メモリから-E-dMに似たものを出力するはずです。

/ EP / d1PPは、メモリから-E-dMに似たものを出力するはずです。

もしそうなら、それは素晴らしいことだと思いますが、/ d1PPは文書化されていないフラグだと思いますか？ 今まで見たことがありません。 それは、同等のタイプ情報を前もって取得することを残すだけです。

@cchamplinええ、それは文書化されてい

誰かがMSVCサポートの現在の状態の簡単な要約を教えてもらえますか？ 私はこの低レベルのコンパイラーのものすべてをあまり理解していません。 C＃/ UWPから使用したいgoライブラリがあるというだけです。これは、gobuildとbuildmodec-sharedですでに機能しています。 ただし、goから生成されたDLLには、MSVCツールチェーンでのみ設定できるコンパイラ/リンカーフラグがないため、そのアプリはWindowsストアで受け入れられません。

だから：どうすればこれをここでテストできますか？ アドバイスをいただければ幸いです。 ありがとうございました！

goから生成されたDLLが、MSVCツールチェーンによってのみ設定できるコンパイラ/リンカーフラグを見逃しているため、そのアプリはWindowsストアに受け入れられません。

@TopperDEL Windows Storeは、どのコンパイラフラグが欠落しているかを教えてくれますか？ mingw-64がそれらをサポートしている場合は、dllをビルドするときに、適切なフラグを指定して-extldflagsをいつでも使用できます。

@qmuntalはい、そうです：
「アプリをリンクするときに、必要なリンカーオプション（SAFESEH、DYNAMICBASE、NXCOMPAT、およびAPPCONTAINER）を適用します。」

私はすでに試しました
go build -ldflags="-s -w '-extldflags=-Wl,--dynamicbase,--high-entropy-va'" -o storj_uplink.dll -buildmode c-shared

しかし、それはストアの提出に関して何も変わりませんでした。 そして、私の理解では、少なくともSAFESEHはMSVC固有のものですよね？

「アプリをリンクするときに、必要なリンカーオプション（SAFESEH、DYNAMICBASE、NXCOMPAT、およびAPPCONTAINER）を適用します。」

Mingw-w64でSAFESEHフラグまたはAPPCONTAINERフラグを有効にする簡単な方法はわかりません。おそらく、このプロジェクトhttps://github.com/status-im/mingw-windows10-uwpでガイダンスを得ることができます。

一方、DYNAMICBASEとNXCOMPATはgo 1.16（＃41421を参照）でデフォルトで有効になりますが、前述のように-extldflagsすでに使用できます。実際、一部のプロジェクトではこれを行っています。

@qmuntalありがとう！ それで、少なくとも上記の私のextldflagsは正しいはずですか？
Windows10-uwpのmingwを見てみましょう。