Go: cmd/tautan: mendukung file objek msvc

/cc @alexbrainman

@xoviat apa masalah yang Anda alami? Saya harus bisa mereproduksinya di sini. Jadi, tolong, berikan semua langkah yang perlu saya ikuti untuk mereproduksi ini.

Terima kasih

Alex

PS: Saya tidak akan punya komputer sampai akhir Juli. Saya akan melihat ini kemudian.

apa masalah yang anda alami?

Saya belum mencobanya, tetapi saya ingin secara khusus memanggil fungsi c dalam file objek msvc dengan menautkannya sebagai .syso dengan go linker. Semua yang saya baca menunjukkan bahwa ini tidak mungkin, tetapi saya akan membuat prosedur untuk mereproduksi kesalahan spesifik yang terjadi.

secara khusus memanggil fungsi c dalam file objek msvc dengan menautkannya sebagai .syso dengan tautan go

Sudahkah Anda mencoba membuatnya menjadi DLL, dan menggunakannya dari dalam DLL?

Saya akan membuat prosedur untuk mereproduksi kesalahan spesifik yang terjadi.

Silakan lakukan. Terima kasih.

Alex

Sudahkah Anda mencoba membuatnya menjadi DLL, dan menggunakannya dari dalam DLL?

Itu sebenarnya rencana awal saya. Saya menggunakan swig sehingga tidak begitu nyaman untuk mengkompilasi kode c yang dihasilkan secara terpisah dan kemudian menulis ulang fungsinya sebagai ekspor DLL. Ini tidak sulit, tetapi menjengkelkan ketika alur kerja dengan gcc hanya go generate; go build .

Baiklah, saya punya prosedur. Mulailah dengan file-file ini:

halo.go:

package main

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

func main() {
    C.hello()
}

halo.c:

#include <stdio.h>

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

kemudian jalankan perintah ini (dengan msvc di jalur):

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

Hasil:
Warning: corrupt .drectve at end of def file

Saat menjalankan file yang dihasilkan:

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

Saya tidak menginstal perintah cl di pc saya. Bagaimana cara menginstal msvc?

Terima kasih.

Alex

Anda memerlukan "build tools 2017" di sini . Microsoft sebenarnya kini mengizinkan siapa saja untuk menggunakan visual studio secara gratis asalkan bukan untuk pengembangan komersial. Jika terlalu merepotkan, saya bisa memberi Anda file objek jika Anda mau.

Jika saja c++ bukan apa-apa, saya tidak perlu khawatir tentang ini. Tapi itu, jadi rasa sakitnya berlanjut ...

Anda memerlukan "alat build 2017" di sini.

Mengerti. Terima kasih.

Jika terlalu merepotkan, saya bisa memberi Anda file objek jika Anda mau.

Ya, tolong, posting hello.obj di suatu tempat.

Memikirkan hal ini lagi. Anda sebenarnya menggunakan gcc untuk menautkan file objek yang dikompilasi dengan kompiler msvc. Bisakah Anda mencoba dan melakukan latihan Anda, tetapi mengganti langkah "go build" dengan gcc yang menghubungkan hello.obj ke program C? Mungkin sudah pernah dilakukan. Saya menduga, jika kita tahu bagaimana melakukannya, kita mungkin bisa melakukan hal serupa dengan Go.

Alex

AFAIK lld https://github.com/llvm-mirror/lld mendukung file objek msvc.

File objek ada di sini: https://github.com/xoviat/msvcgo/blob/master/hello.syso

lld https://github.com/llvm-mirror/lld mendukung file objek msvc

Go menggunakan tautan gcc (bukan lld) di Windows.

File objek ada di sini: https://github.com/xoviat/msvcgo/blob/master/hello.syso

Saya akan mencobanya ketika saya pulang pada bulan Agustus. Terima kasih.

Alex

Go menggunakan tautan gcc (bukan lld) di Windows.

Aku tahu. Tetapi lld adalah dokumentasi sumber terbuka terbaik dari format objek msvc.

Saya sebenarnya mendapatkan kesalahan yang sama dari ld jadi kesalahan itu pasti berasal dari ld.

Saya sebenarnya mendapatkan kesalahan yang sama dari ld jadi kesalahan itu pasti berasal dari ld.

Ya. Kita perlu mencari tahu bagaimana membangun program C dengan mengkompilasi bagian dengan msvc, dan menautkan dengan gcc.

Alex

Maafkan ketidaktahuan saya, tapi apa sebenarnya tautan gcc? Apakah ini menghubungkan output dari go linker?

Menjalankan objconv pada file objek untuk dikonversi ke elf:

objconv -felf hello.obj hello.syso

Kami sekarang memiliki kesalahan ini:

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

Mungkin stdio terlarang?

Maafkan ketidaktahuan saya, tapi apa sebenarnya tautan gcc? Apakah ini menghubungkan output dari go linker?

Anda menggunakan 2 program untuk membangun program Go Anda:

• compiler mengonversi file .go Anda (1 paket pada saat itu) menjadi file objek yang disimpan di bawah direktori %GOPATH%/pkg;
• linker yang membuat file .exe akhir dari file objek dari bawah %GOPATH%/pkg.

Terkadang (ketika salah satu paket Anda menggunakan Cgo), tautan Go memanggil tautan eksternal untuk menemukan semua bit yang diimplementasikan dalam C. Bayangkan Anda memanggil printf dari kode C Anda. Kode terkompilasi C printf harus menjadi bagian dari Go yang dapat dieksekusi, tetapi Go linker tidak tahu di mana mendapatkannya. Jadi Go linker memanggil linker eksternal untuk memasukkan kode itu.

Current Go menggunakan compiler/linker gcc untuk mengkompilasi dan menautkan kode C (kami menggunakan mingw gcc). Jika Anda akan mengkompilasi kode C Anda dengan kompiler yang berbeda (oleh Microsoft), Anda harus menggunakan linker koresponden (oleh Microsoft) untuk menemukan semua kode C eksternal yang dibuat oleh kompiler.

Jadi, saya kira, saya salah menyarankan untuk menggunakan tautan gcc. Untuk skenario umum, Anda harus menggunakan kompiler dan tautan Microsoft. Kami harus mencari tahu apa yang dibutuhkan tautan Microsoft sebagai input dan mencocokkannya.

Anda mungkin lolos tanpa MC linker, jika kode C Anda tidak memiliki kode eksternal. Silakan coba beberapa program C yang sangat sederhana (seperti yang menambahkan 2 bilangan bulat atau sesuatu). Itu mungkin hanya berfungsi seperti yang Anda jelaskan di atas.

Alex

Mungkin stdio terlarang?

Saya menduga Anda perlu menghubungi tautan Microsoft untuk menemukan kode itu.

Alex

Saya tidak memastikan tapi

objconv -felf hello.obj hello.syso

Mungkin, Anda harus mencoba melakukan coff atau omf daripada elf?

Mungkin, Anda harus mencoba melakukan coff atau omf daripada elf?

@xoviat ya, Anda tidak boleh mengonversi file .obj ke elf, versi Windows dari gcc menghasilkan file pe/coff sama seperti kompiler Windows lainnya.

Alex

tautan Go memanggil tautan eksternal untuk menemukan semua bit yang diimplementasikan di C.

Apa perintah khusus yang digunakan? Jika saya mengetahui perintah mingw, maka mungkin saya dapat melanjutkan ke jalur perbandingan file untuk mencoba mendapatkan msvc agar sesuai dengan apa yang dikeluarkan mingw.

Anda dapat melihat komentar yang tepat dengan menjalankan go build -ldflags=-v .

Oke, jadi dari apa yang bisa saya katakan:

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

Go tampaknya membuat direktori sementara dengan file-file ini. Apakah ada cara untuk mempertahankan direktori sementara sehingga saya dapat memeriksa isinya?

Coba go build -work

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

File objek tersisa di direktori ini.

Opsi -work sebenarnya tidak akan mempertahankan file sementara yang dibuat oleh penaut. Saat ini Anda hanya perlu mengedit sumber tautan untuk tidak menghapus direktori. Kita mungkin harus menambahkan opsi untuk itu, dengan satu atau lain cara.

Saat ini Anda hanya perlu mengedit sumber tautan untuk tidak menghapus direktori.

Jika Anda tidak keberatan, saya akan menunggu sampai ini diterapkan di HEAD sehingga saya tidak perlu melakukan pekerjaan yang berulang.

Apakah ada cara untuk mempertahankan direktori sementara sehingga saya dapat memeriksa isinya?

program cmd/link memiliki flag -tmpdir untuk itu. Anda dapat menggunakannya seperti ini:

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>

Alex

Ini hanya untuk referensi saya sendiri, tetapi ini perlu porting ke 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);
}

Saya tidak akan meremehkan waktu yang saya perlukan untuk menyelesaikan tugas ini karena saya sama sekali tidak terbiasa dengan perakitan.

• [x] Pahami apa yang dilakukan majelis
• [x] Port ke rakitan MSVC
• [x] Memahami _beginthread vs CreateThread
• [x] Beralih ke CreateThread

Juga, simbol yang tidak ditentukan:

• [x] timeBeginPeriod --> winmm.lib
• [x] waktuMulaiPeriode
• [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

Oke, jadi pindah ke sini lebih cepat dari yang diharapkan!

Semua: apakah asm_amd64.s dirakit oleh assembler go (dengan assembly ganjil) atau assembler gcc?

Tampaknya gcc tidak akan merakitnya, yang berarti mungkin sedang dirakit. Dan kemudian pertanyaannya menjadi: bagaimana merakitnya dengan assembler go menjadi sebuah objek.

Maksudnya adalah runtime/cgo/asm_amd64.s dirangkai menjadi objek Go, lalu cmd/link menautkannya bersama-sama dengan semua objek Go lainnya ke dalam satu objek sistem, lalu penaut sistem menautkan objek sistem tunggal itu ditambah semua cgo dependensi ke dalam program akhir.

Apakah ada cara untuk merakit objek itu untuk saat ini untuk tujuan pengujian? Suka gcc -c asm_amd64.s kecuali dengan go?

Maksudnya adalah runtime/cgo/asm_amd64.s dirangkai menjadi objek Go, lalu cmd/link menautkannya bersama-sama dengan semua objek Go lainnya ke dalam satu objek sistem, lalu penaut sistem menautkan objek sistem tunggal itu ditambah semua cgo dependensi ke dalam program akhir.

Sejauh ini saya menemukan objek-objek ini:

• go.o : jelas dari go toolchain
• _cgo_.o : dihasilkan oleh gcc, tidak dapat digunakan
• 000000.o : dihasilkan oleh gcc, tidak dapat digunakan
• 000001.o : Pembaruan: sebenarnya dihasilkan oleh tautan go, tetapi berisi simbol gcc. Tidak dapat digunakan.

go.o adalah objek terbesar.

@ianlancetaylor

Saya tidak berpikir apa yang Anda katakan itu benar. crosscall_amd64 terletak di 000001.o, tetapi file itu tidak memiliki "semua kode 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

File ini jelas dibuat oleh gcc, yang terlambat dalam prosesnya.

Apakah ada cara untuk merakit objek itu untuk saat ini untuk tujuan pengujian? Suka gcc -c asm_amd64.s kecuali dengan go?

asm_amd64.s adalah bagian dari paket runtime. Anda dapat melihat bagaimana perintah "go build" menggunakan file asm_amd64.s, seperti:

$ 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
$

Alex

Terima kasih.

Simbol crosscall_amd64 didefinisikan dalam file runtime/cgo/gcc_amd64.s. File itu dikompilasi oleh GCC (seperti semua file runtime/cgo/gcc_*). Jadi tidak digabungkan menjadi satu file go.o yang berisi semua kode Go. File yang kita bicarakan sebelumnya, runtime/cgo/asm_amd64.s, mendefinisikan simbol crosscall2 . Anda akan menemukan simbol itu di go.o.

Terima kasih.

Oke, saya telah berhasil menautkan executable yang mogok pada pelanggaran akses saat masuk
go.runtime.rt0_go+5F --> go.___acrt_stdio_initializer.

Itu semua waktu yang saya miliki untuk saat ini; Saya akan kembali lagi nanti.

@alexbrainman Itu benar.

@alexbrainman Anda perlu MSVC untuk melanjutkan. Beri tahu saya apakah Anda memerlukan bantuan dalam hal ini.

Anda memerlukan MSVC untuk melanjutkan.

Saya menginstal ini https://www.visualstudio.com/downloads/#build -tools-for-visual-studio-2017

Apa yang harus saya lakukan setelah diinstal?

Alex

Setelah Anda menginstalnya, Anda perlu membangun "libgo," yang merupakan perpustakaan go. Salin file berikut dari folder cgo :

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

Kita perlu menyesuaikan gcc_windows_amd64.c agar kompatibel dengan MSVC. Ubah fungsinya sebagai berikut:

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);
}

Buat file baru di folder dengan semua file ini bernama "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

Beri tahu saya jika Anda memiliki folder yang terstruktur seperti yang diminta.

By the way, terima kasih untuk keduanya bekerja pada ini dan untuk pergi. Kalian telah menciptakan bahasa yang benar-benar ajaib.

Beri tahu saya jika Anda memiliki folder yang terstruktur seperti yang diminta.

Saya berhasil membangun libgo.lib seperti yang telah Anda jelaskan di sini https://github.com/golang/go/issues/20982#issuecomment -327365063
Apa yang harus saya lakukan selanjutnya?

Alex

Oke, jadi sekarang kita membutuhkan file-file berikut:

• libgo.lib
• zat yang lengket dan kental
• halo.cgo2.o
• halo.c

hello.c adalah sebagai berikut:

#include <stdio.h>

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

Untuk mendapatkan hello.cgo2.o dan go.o , Anda harus memulai dengan file berikut:

package main

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

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

disebut "halo.go"

Siapkan skrip PowerShell yang terus-menerus menyalin file dari $ env:TMP :

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

Kemudian jalankan go build dengan hello.c dan hello.go di dalam folder. Anda harus dapat memulihkan file yang diperlukan dari lokasi tempat mereka disalin.

Setelah Anda memiliki file yang ditentukan di atas, Anda dapat membangun dengan:

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

Beri tahu saya jika Anda memiliki pertanyaan.

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

Itu membuat file yang dapat dieksekusi go.exe, tetapi tidak berjalan. Saya tidak melihat kode asm yang masuk akal di sana. Instruksi pertama hanya melompat ke mana-mana. Ini hanya kekacauan.

Mungkin Anda harus mulai dengan sesuatu yang sangat sederhana. Tulis file asm (Go asm file) dengan fungsi asm tunggal yang mengeksekusi "INT $3" dan tidak memiliki yang lain. Dan coba buat program yang dapat dieksekusi darinya - program harus menjalankan fungsi Anda sejak awal.

Mungkin membangunnya menggunakan alat Go terlebih dahulu (dan juga menggunakan gcc jika diperlukan), lalu coba dan lakukan hal yang sama menggunakan MSVC.

Alex

Alex, terima kasih atas bantuanmu. Saya akan bekerja pada itu.

Aku akan melampirkan ini dua artikel di sini untuk referensi saya sendiri. Jika tidak, saya tidak memiliki pembaruan lebih lanjut.

Saya sebenarnya mendapatkan program go yang cukup rumit yang hanya menggunakan perpustakaan msvc. Ternyata vanilla msvc linker dan llvm-lld tidak menangani bagian .bss .

Setelah saya menambal tautan, program dapat berjalan.

Sayangnya go build rusak ketika menghasilkan _cgo_.o / _all.o . Apakah mungkin untuk menjelaskan alasan di balik pembuatan dua file ini di cgo?

Anda dapat menjalankan go tool cgo untuk menjalankan cgo secara langsung. Sumbernya ada di sini: https://github.com/golang/go/tree/master/src/cmd/cgo

Juga, jika Anda bisa menjalankan ini, itu akan luar biasa. Saya hanya belum mencurahkan waktu untuk ini, jadi belum ada kemajuan. Maaf tentang itu.

Saya sudah mendapatkan program yang dapat berjalan dengan benar melalui serangkaian jahitan tangan -- yang saya coba lakukan di sini adalah melihat apakah prosesnya dapat diintegrasikan kembali ke go untuk membuatnya tidak terlalu menyakitkan. :-)

Jika Anda dapat mendokumentasikan proses jahitan tangan, maka saya mungkin dapat membantu.

Hanya dari melihat, _cgo_.o tampaknya dihasilkan seperti ini (disederhanakan):

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

Dari sini: https://github.com/golang/go/blob/b4c84a1b010f012668b5e3ccaf63f609cd11c5fe/src/cmd/go/internal/work/exec.go#L1975

Juga, lihat di sini untuk dokumentasi:
https://github.com/golang/go/blob/840f2c167f1d5196559d8a1e77c370960e66d34e/src/cmd/cgo/doc.go#L607

Idealnya kita akan menulis program go yang melakukan pra-proses file objek sehingga kompatibel dengan link.exe untuk gesekan minimal, tapi itu semacam tujuan peregangan.

Terima kasih atas petunjuknya -- saya akan segera menuliskan prosesnya.

Sayangnya saya tidak berpikir penautan dapat dilakukan melalui link.exe kecuali kita mengubah gcc untuk memancarkan data yang tidak diinisialisasi di bagian .data alih-alih bagian .bss -- tetapi kita bisa pasti memperbaiki llvm-lld untuk mengenali bagian .bss (yang telah saya lakukan).

Kita perlu menangani _cgo_.o dan _all.o secara terpisah. Saya punya beberapa pertanyaan tentang mereka:

(1) Tampaknya _cgo_.o bukan final yang dapat dieksekusi karena tidak mengandung runtime go. Sepertinya kompiler melihat simbol DWARF untuk mengetahui definisi struct. Masalahnya adalah sulit untuk menghasilkan yang dapat dieksekusi jika Anda akan menautkan dengan sejumlah perpustakaan secara eksternal, terutama yang dihasilkan oleh msvc.

Apakah mungkin untuk menghindari langkah ini?

(2) go saat ini gunakan GNU ld untuk menggabungkan semua file objek ke dalam _all.o melalui meneruskan -Wl,-r di GCC. Ini bermasalah karena (1) tampaknya penaut lain tidak memiliki fitur ini, dan (2) perintah dipengaruhi oleh CGO_LDFLAGS . Misalnya, perintah berikut menghasilkan hasil yang salah:

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

Ini menghasilkan file yang dapat dieksekusi alih-alih file objek yang dibundel.

Apakah mungkin untuk menghindari langkah ini sama sekali hanya dengan meletakkan semua file objek ke dalam .a dihasilkan secara langsung?

@zooba Apa peluang MSFT untuk memperbarui link.exe dengan tambalan ini?

Sayangnya saya tidak berpikir penautan dapat dilakukan melalui link.exe kecuali kita mengubah gcc untuk memancarkan data yang tidak diinisialisasi di bagian .data alih-alih bagian .bss -- tetapi kita pasti dapat memperbaiki llvm-lld untuk mengenali bagian .bss (yang telah saya lakukan).

Jadi dengan asumsi bahwa MSFT tidak memperbarui link.exe (yang mungkin), akan lebih baik untuk mengkompilasi file objek dengan cl.exe daripada gcc .

Tampaknya _cgo_.o bukan final yang dapat dieksekusi karena tidak mengandung runtime go.

Itu benar, pada dasarnya ada dua set file objek (saya pikir) yang pada akhirnya dihubungkan bersama. File go.o (IIRC) berisi semua kode go + runtime, dan objek lain berisi kode C. Ada rutinitas perakitan untuk melompat di antara dua set objek.

Juga, kita membutuhkan clang untuk mengkompilasi file rakitan Unix.

Untuk tujuan kita, -Wl,-r akan sama dengan menjalankan lib.exe [object files] /OUT:obj . Opsi ini berarti "tautan secara bertahap", yang berarti "ambil beberapa file input, lakukan beberapa pekerjaan, lalu keluarkan file objek lain." Jika kita tidak khawatir tentang bagian "melakukan beberapa pekerjaan" untuk saat ini, kita dapat mengambil persyaratan sebagai "ambil beberapa file input dan/atau file objek dan keluarkan file objek lain" kecuali dalam kasus kita file objek akan menjadi Perpustakaan.

Anda dapat memberitahu GCC untuk menghindari menempatkan variabel di bagian .data daripada bagian .bss dengan menggunakan opsi -fno-zero-initialized-in-bss .

Perhatikan bahwa pada tip kita tidak lagi menggunakan -Wl,-r saat membuat kode cgo.

Seharusnya cmd/link tidak perlu memahami file objek MSVC untuk menggunakannya sebagai file .syso . File-file itu hanya diteruskan ke tautan eksternal. Jadi saya pikir apa yang diperlukan di sini adalah memanggil tautan MSVC sebagai tautan eksternal, yang seharusnya dapat Anda lakukan dengan menggunakan opsi -extld . Jika Anda sudah melakukan itu, saya minta maaf; dalam hal ini, apa yang gagal?

Jika Anda sudah melakukan itu, saya minta maaf; dalam hal ini, apa yang gagal?

IIRC, link.exe barf pada objek yang dihasilkan gcc.

Benar, Anda juga harus menggunakan kompiler MSVC C, dengan mengatur variabel lingkungan CC tepat. Saya tidak berpikir itu akan berhasil menggabungkan objek GCC dan objek MSVC dalam satu tautan.

Tetapi kemudian Anda mengalami masalah di mana pustaka runtime C dikompilasi sebelumnya. Dan jika Anda mencoba untuk mengkompilasi ulang mereka, Anda mengalami masalah bahwa cl tidak dapat mengkompilasi Majelis unix. Jadi Anda mem-porting bagian-bagian dari perpustakaan runtime dan mencoba menautkannya, yang saya lakukan dan gagal.

Di suatu tempat di sepanjang jalan, cl mengkompilasi bagian penting dari kode. Ide saya untuk memperbaikinya adalah dengan memfaktorkan kode MSVC menjadi DLL dengan flat C API, dan kemudian secara bertahap mengkompilasi lebih banyak perpustakaan runtime sampai berhenti bekerja.

Ide @haohui untuk memperbaiki masalah berbeda. Alih-alih memperbaiki akar masalah, dia mengatasinya dengan menambal linker. Jelas dia lebih sukses daripada saya, tapi itu mungkin karena pendekatannya, dengan melihat ke belakang, lebih mungkin berhasil daripada saya.

Apa yang saya sarankan pada saat ini (IMHO) adalah untuk secara bertahap mengkompilasi lebih banyak perpustakaan runtime dengan cl sampai berhenti bekerja atau sampai Anda tidak memiliki kode gcc yang tersisa. Maka Anda tahu persis di mana masalahnya.

Dan dengan tambalan tautan, tidak diperlukan DLL.

Patch llvm-lld tersedia di https://bugs.llvm.org/show_bug.cgi?id=35283

Saya akan meluangkan waktu untuk memberikan contoh.

+1 @haohui Terima kasih banyak telah meneruskan ini!

@haohui Versi llvm mana yang berlaku untuk tambalan Anda? Adakah instruksi tentang cara menggunakan tambalan Anda dan cara menautkan ke file MSVC?

Mengenai file _cgo_.o dan _all.o , saya memiliki masalah yang sama, jadi mungkin perbaikan untuk masalah ini dapat menjadi perbaikan untuk masalah lain juga: https://github.com/golang/go /isu/17014

Terima kasih untuk semua pekerjaan ini. Kedengarannya seperti kemajuan yang baik sedang dibuat. Fitur baru dibekukan hingga Go 1.11, jadi mengubah tonggak sejarah.

Jadi saya melompat ke ini tadi malam. Dimungkinkan untuk membangun semuanya melalui msvc:cl lalu menautkan semuanya melalui msvc:link. Namun, masalahnya sangat banyak.

Jadi di luar masalah sederhana seperti msvc:cl tidak sepenuhnya mendukung C99 (Saat ini kami tidak dapat menangani tipe _Complex). Ada lebih banyak masalah sistemik dengan menyisir lib PE yang dibuat oleh internal go dan yang dibuat oleh msvc. Secara khusus msvc:link menghancurkan segmen .bss (saya pikir itu mungkin hanya membuang data ini ke .data) yang merupakan masalah karena sepertinya assembler go SB (pseudo reg) menghasilkan pengalamatan yang salah jika .bss dipindahkan .

Pikiran awal saya adalah mencoba agar assembler menempatkan hal-hal yang akan masuk ke .bss dan .noptrbss masing-masing menjadi .data dan .noptrdata. Saya bahkan tidak yakin apakah ini mungkin; mengutak-atiknya belum berhasil dan pengalamatan disemprot sepenuhnya.

Saya tidak berpikir itu mungkin untuk menggunakan link.exe untuk saat ini. Saya pikir kita harus mulai dengan lld-link.exe

Jika pemikiran di balik itu adalah bahwa kita dapat menambal lld-link agar tidak berpindah-pindah data .bss, saya mengerti daya tariknya. Secara realistis jika tujuannya adalah untuk mendukung rantai alat msvc yang sebenarnya, maka masuklah ke kompilasi internal yang menempatkan data ke dalam .bss/.noptrbss untuk perlu ditangani.

Tidak bisakah kita mendistribusikan ulang lld-link.exe dengan go? Itu sepertinya jalur berisiko terendah untuk mendukung file objek MSVC selama LTCG tidak diaktifkan. Saya mengerti itu tidak ideal tetapi kami menghadapi kendala sumber daya.

Hal ini juga memungkinkan kemajuan tambahan yang merupakan strategi terbaik.

Oke, beberapa berita lanjutan yang bagus, saya bisa menghabiskan satu jam mengerjakan ini saat makan siang.

Saat ini saya memiliki contoh dari masalah sebelumnya yang berfungsi:

- 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

Biner dibangun sepenuhnya dengan MSVC dan toolchain Go (tidak ada GCC atau LLVM lain yang diinstal).

Temuan:

• Memiliki alat Go/link.exe menghasilkan data .bss untuk rakitan internal ke .data pada akhirnya cukup sepele
• Beberapa bagian ASM harus disesuaikan untuk msvc
• Beberapa #def GCC di-shimm
• Beberapa penyesuaian kecil harus dilakukan pada beberapa file .c yang dihasilkan cgo
• Bilangan kompleks perlu diputar, saat ini tidak didukung
• Kemungkinan flag tambahan perlu ditambahkan langsung untuk membangun atau tautan untuk dukungan msvc, ldflags dll tidak akan cukup

Langkah selanjutnya:
Jika saya punya waktu akhir pekan ini, saya akan berusaha mendapatkan perubahan saya menjadi garpu dan tetapi fungsionalitas di balik bendera di build/link. Setelah itu saya akan mendapatkan PR untuk ditinjau sehingga kami dapat menentukan jenisnya. Saya tidak 100% yakin bahwa memindahkan data .bss tidak akan berdampak apa-apa.

Satu-satunya hal yang menarik yang dapat saya pikirkan adalah bahwa itu akan meledakkan ukuran biner, tetapi seharusnya tidak apa-apa.

Oke!

Maaf saya butuh beberapa hari ekstra untuk mengumpulkan ini. Jadi draf pertama di tambalan dapat ditemukan di sini: https://github.com/cchamplin/go/commit/69a5cfc1dd0106fd8a2928a83e4c7001e81e89b8 :: https://github.com/cchamplin/go/tree/msvc_toolchain_support

Ini masih kasar tetapi saya berhasil membuat kode dengan msvc.

Jika akan luar biasa jika orang dapat mulai menguji ini sekarang dan melaporkan bug kembali kepada saya sehingga saya bisa mendapatkan ini di tempat yang lebih baik untuk hulu. Juga jika ada yang ingin ikut serta dalam tes menulis, itu akan luar biasa!

Penggunaan:

go build -compiler msvc [path]

• Bilangan kompleks tidak didukung saat ini sampai saya mengetahui apakah kita dapat membuatnya bekerja.
• Saya tidak tahu apa yang terjadi jika Anda mencoba membangun runtime go dengan kompiler msvc.
• gcc masih dibutuhkan dan digunakan oleh gco untuk mendapatkan definisi dan tipe data saat kompilasi tidak digunakan untuk membangun apa pun ). Saya tidak tahu apakah kita bisa menyiasatinya, msvc tidak memiliki apa pun yang dapat melakukan hal yang sama dan #define dump kode... jika ada yang punya ide tentang ini, itu bagus

Patch yang ditautkan menciptakan masalah bootstrap.

@alexbrainman Bagaimana dan di mana ditentukan file mana yang akan disalin ke pkg/boostrap/src/bootstrap selama fase boostrapping toolchain1 ?

cc @alexbrainman

Patch yang ditautkan menciptakan masalah bootstrap.

Saya tidak tahu bagaimana bootstrap bekerja saat ini. Tapi saya yakin orang lain ( @rsc dan @ianlancetaylor) dapat membantu.

Saya ingin tahu bagaimana @cchamplin menjalankan make.bat jika bootstrap tidak berfungsi.

Alex

@xoviat Saya tidak tahu apa masalahnya, tetapi daftar direktori bootstrap ada di cmd/dist/buildtool.go.

Hai @alexbrainman , @ianlancetaylor , @xoviat maaf soal itu saya kira saya harus memverifikasi lebih teliti.

Saya telah memperbarui cabang di sini https://github.com/cchamplin/go/commit/69a5cfc1dd0106fd8a2928a83e4c7001e81e89b8 dengan perbaikan untuk masalah bootstrap, saya pikir itu harus bootstrap dengan benar sekarang.

Saya memang harus menyalin beberapa direktori /src/internal/syscall ke cmd/internal/msvc. Apakah itu akan menjadi masalah besar? Saya tidak yakin bagaimana cara mendapatkan akses ke registri tanpa menggunakan src/internal.

Saya memang harus menyalin beberapa direktori /src/internal/syscall ke cmd/internal/msvc. Apakah itu akan menjadi masalah besar? Saya tidak yakin bagaimana cara mendapatkan akses ke registri tanpa menggunakan src/internal.

Saya tidak tahu bagaimana melakukannya saat ini, tetapi saya menduga cmd/dist dapat melakukannya tanpa Anda menyalin file sumber secara manual. Saya yakin Russ atau Ian akan membantu Anda ketika Anda siap untuk mengirimkan kode.

Saya pikir sudah waktunya bagi @bradfitz dan @ianlancetaylor untuk memutuskan bagaimana melanjutkan di sini. Apakah kami ingin Go mendukung alat pembuatan Microsoft serta gcc? Kita harus menginstal alat Microsoft koresponden ke pembangun kita (kita harus melakukannya sebelum kita mulai menerima CL). Kami mungkin harus memperkenalkan variabel lingkungan baru. Dokumentasi baru.

Jika jawabannya ya, maka @cchamplin harus mengirimkan perubahan kodenya sesuai https://golang.org/doc/contribute.html Apakah Anda bersedia melakukannya? Perubahannya cukup besar, sehingga perlu dipecah menjadi CL yang lebih kecil, sehingga dapat ditinjau dan diajukan secara terpisah. Setiap perubahan harus memiliki all.bat PASS sebelum dapat dikirimkan. Alangkah baiknya jika kita bisa melihat semua CL sebelum kita mulai mengirimkan CL terlebih dahulu.

Terima kasih.

Alex

Apakah kami ingin Go mendukung alat pembuatan Microsoft serta gcc?

Sekedar catatan patch ini juga memfasilitasi #17014 dimana saya sudah memiliki patch yang sedang dalam proses.

Jika jawabannya ya, maka @cchamplin harus mengirimkan perubahan kodenya sesuai https://golang.org/doc/contribute.html Apakah Anda bersedia melakukannya? Perubahannya cukup besar, sehingga perlu dipecah menjadi CL yang lebih kecil, sehingga dapat ditinjau dan diajukan secara terpisah.

Ya, dan memecahnya seharusnya bukan masalah besar. Saya hanya perlu tahu apakah ini adalah sesuatu yang mungkin masuk sebelum saya melakukan upaya untuk membersihkan semua kode, dokumentasi tertulis, tes dibuat, dll.

Apakah kami ingin Go mendukung alat pembuatan Microsoft serta gcc?

Dalam benak saya, jawabannya adalah ya. Kompiler itu sendiri gratis dengan VS Community, dan tidak memiliki dukungan penuh Windows benar-benar membuat frustrasi. Saya tidak perlu berdiri di kotak Linux untuk mengkompilasi github.com/Microsoft/hcsshim (misalnya), karena rantai alat Windows tidak didukung.

Apa alasan untuk tidak mendukung rantai alat Windows?

Saya pikir pada prinsipnya baik-baik saja untuk mendukung file objek MSVC. Kita perlu memiliki seorang pembangun.

Perhatian utama saya adalah seberapa banyak format dapat berubah antara rilis Windows atau MSVC. Format ELF yang digunakan pada kebanyakan platform lain sangat stabil; kami sangat jarang harus mengubah dukungan ELF dengan cara apa pun selain menambahkan dukungan untuk prosesor baru. Apakah format file MSVC juga stabil?

Format yang terkait dengan rantai alat MSVC cukup stabil. Masalah terbesar adalah mendukung alat itu sendiri. Microsoft memiliki kecenderungan untuk memindahkan berbagai hal (file dan entri registri) di antara rilis Visual studio. Sebagian besar dapat dikonfigurasi (setidaknya di tambalan yang saya tulis) tetapi kemungkinan masih ada bahwa ketika versi utama baru dari visual studio dirilis, itu mungkin tidak kompatibel sebagai toolchain build tanpa perubahan pada Go. Namun, semua versi studio visual sebelumnya yang didukung akan terus berfungsi.

Sejauh yang saya tahu, format COFF memiliki stabilitas yang wajar jika Anda hanya mengekspos diri Anda ke C ABI (bukan C++). Ini juga didokumentasikan secara luas dan LLVM menyediakan implementasi referensi.

@cchamplin Saya akan merekomendasikan mengharuskan pengguna untuk memanggil vcvarsall.bat sebelum menautkan dengan MSVC. Ini akan secara signifikan mengurangi pemeliharaan hingga mendekati nol.

Kita perlu memiliki seorang pembangun.

@ianlancetaylor setelah objek MSVC terbukti berfungsi sebagaimana dimaksud, apakah Anda yakin akan ada kebutuhan untuk pembuat msys/cygwin dan pembuat MSVC, atau akankah hanya ada pembuat MSVC?

Saya yakin beberapa orang akan lebih suka menggunakan alat cygwin, dan mereka sudah bekerja dan kami ingin mereka terus bekerja, jadi saya pikir kami membutuhkan dua pembuat.

Hei, tampaknya dari bagian bawah utas ini Anda telah menyelesaikan masalah MSVC Anda. Tetapi jika Anda mengalami masalah, saya berada di tim MSVC. Jangan ragu untuk ping saya di github atau email ([email protected])

Kita perlu memiliki seorang pembangun.

Ya. Dan sebaiknya kita mulai dengan mengubah builder yang ada agar MS build tools terinstal. Jadi kami dapat menggunakannya karena kami menerima CL untuk masalah ini.

Kami dapat menginstal alat gcc dan alat microsoft di semua pembuat kami. Bisakah kita menjalankan all.bat yang menguji alat gcc dan microsoft sekaligus? Jika tidak, maka kita perlu memiliki builder yang berbeda yang dikonfigurasi untuk alat yang berbeda. Apa parameter yang mengontrol compiler dan linker eksternal yang digunakan?

Perhatian utama saya adalah seberapa banyak format dapat berubah antara rilis Windows atau MSVC.

Anda tidak menginstal kompiler dengan Windows. Anda harus menginstalnya sendiri. Sama seperti yang kita lakukan dengan gcc. Kami menginstal versi apa pun yang kami suka. Kami bahkan dapat menjalankan versi gcc yang berbeda pada builder yang berbeda.

Apakah format file MSVC juga stabil?

Saya tidak tahu apa-apa tentang itu. Saya menduga Anda hanya menggunakan alat yang disediakan.

Alex

Perhatian utama saya adalah seberapa banyak format dapat berubah antara rilis Windows atau MSVC. Format ELF yang digunakan pada kebanyakan platform lain sangat stabil; kami sangat jarang harus mengubah dukungan ELF dengan cara apa pun selain menambahkan dukungan untuk prosesor baru. Apakah format file MSVC juga stabil?

Ya, COFF sangat stabil.

@bradfitz dan @ianlancetaylor apa yang kita perlukan agar pembuat windows tersedia untuk menguji perubahan untuk masalah ini? Lihat pertanyaan saya di https://github.com/golang/go/issues/20982#issuecomment -370719472

Terima kasih

Alex

apakah go mendukung objek msvc sekarang?

Ubah https://golang.org/cl/110555 menyebutkan masalah ini: debug/pe: parse the import directory correctly

@alexbrainman @bradfitz @ianlancetaylor :

Saya telah melakukan sebagian besar pekerjaan yang saya yakini untuk membersihkan tambalan dan memecahnya menjadi bagian yang lebih mudah dicerna. Saya yakin saya hampir siap untuk penyerahan sebenarnya ke proyek. Saya kira saya perlu tahu apakah saya harus menunggu kabar tentang situasi pembangun sebelum mengirimkan kode atau melakukannya secepatnya?

Anda dapat mengirim CL kapan saja, tetapi seseorang perlu menyiapkan pembuat. Jika tidak, kami tidak memiliki cara untuk mengujinya.

@johnsonj , dapatkah Anda menambahkan alat kompiler MSVC ke gambar Windows kami?

Saya idealnya ingin tidak menambahkan jenis host baru dan hanya membuat 1-3 dari jenis host Windows kami yang ada memiliki alat MSVC selain Cygwin. Dan kemudian kita dapat menambahkan lebih banyak konfigurasi pembangun di atas jenis host yang dimodifikasi tersebut.

/cc @andybons @bcmils sebagai FYI (untuk bagaimana hal-hal Windows terjadi ... kami mohon bantuan Jeff :))

@johnsonj , dapatkah Anda menambahkan alat kompiler MSVC ke gambar Windows kami?

@cchamplin Saya sarankan Anda mencoba menambahkan alat apa pun yang diperlukan untuk pembuatnya sendiri. Tidak ada orang lain, tetapi Anda tahu apa yang dibutuhkan. Anda dapat melihat di direktori golang.org/x/build/env/windows untuk instruksi lengkapnya. Khususnya Anda, mungkin, ingin menambahkan lebih banyak baris ke startup.ps1. Setelah Anda mengetahui apa yang perlu diubah dalam direktur itu, buat perubahan dan kirimkan perubahan Anda untuk ditinjau melalui https://golang.org/doc/contribute.html Setelah diterima, kami dapat memperbarui pembuat menggunakan petunjuk ini.

Saya idealnya ingin tidak menambahkan jenis host baru dan hanya membuat 1-3 dari jenis host Windows kami yang ada memiliki alat MSVC selain Cygwin. Dan kemudian kita dapat menambahkan lebih banyak konfigurasi pembangun di atas jenis host yang dimodifikasi tersebut.

Kami selalu memiliki kompiler dan tautan Mingw (gcc) C di windows. Kami tidak pernah memiliki set alat build C yang berbeda. Setelah kami menambahkan dukungan untuk kompiler Microsoft C, apakah mungkin untuk menguji fungsi Mingw dan Microsoft C dengan menjalankan all.bat ? Atau apakah Mingw atau Microsoft C saling mengecualikan? Apakah kita harus mengatur beberapa variabel lingkungan untuk menunjuk ke Mingw atau ke Microsoft, tetapi tidak pernah keduanya? Saya kira saya mencoba memahami bagaimana kode perlu disusun dan diuji. Juga ini akan menentukan berapa banyak pembangun berbeda yang kita butuhkan.

Alex

Saya akan melihat ke dalam memanggang binari pada gambar

Ubah https://golang.org/cl/112036 menyebutkan masalah ini: env/windows: add visual studio tools to image

@johnsonj @bradfitz : Terima kasih telah memasukkannya ke dalam

@alexbrainman @bradfitz @ianlancetaylor : Sejauh menguji strategi untuk ini, saya tidak yakin apa yang harus dilakukan. Kita dapat mengambil jalur menjalankan tes dist untuk kedua rantai alat di jendela dan melakukan setiap tes dua kali, atau haruskah kita hanya menguji tes cgo dua kali (sekali untuk gcc, sekali untuk msvc)?

Sejauh menguji strategi untuk ini, saya tidak yakin apa yang harus dilakukan. Kita dapat mengambil jalur menjalankan tes dist untuk kedua rantai alat di jendela dan melakukan setiap tes dua kali, atau haruskah kita hanya menguji tes cgo dua kali (sekali untuk gcc, sekali untuk msvc)?

@cchamplin Saya tidak punya jawaban untuk pertanyaan Anda. Saya kira Ian tahu jawabannya.

Alex

Berapa biaya menjalankan semua tes dua kali alih-alih hanya cgo?

@mxplusb , kita bisa menjalankan konfigurasi build baru untuk Windows dan itu akan berjalan secara paralel dengan yang sudah ada 3. Konfigurasi builder baru baik-baik saja. Kami menambahkannya secara teratur.

Katakan saja kepada saya bagaimana membuatnya berbeda: atur variabel lingkungan yang berbeda/baru dan kemudian sesuatu akan mengambilnya, saya berasumsi?

Mungkin perlu beberapa hal agar ini berfungsi.

Entah kita perlu menjalankan di dalam di dalam Shell/lingkungan tempat tes go yang dijalankan oleh tes dist akan dijalankan di dalam setelah vsvars.bat yang sesuai dijalankan/dipanggil

Atau kita dapat meminta dist mengeksekusi vsvars yang sesuai dan mengekstrak variabel lingkungan yang dibutuhkannya dan kemudian mengatur/menyerahkannya untuk diuji.

Kami juga mungkin ingin beberapa variabel lingkungan memberi tahu dist atau make.bat bahwa kami ingin menjalankan tes dengan set -compiler msvc.

Entah kita perlu menjalankan di dalam di dalam Shell/lingkungan tempat tes go yang dijalankan oleh tes dist akan dijalankan di dalam setelah vsvars.bat yang sesuai dijalankan/dipanggil

Atau kita dapat meminta dist mengeksekusi vsvars yang sesuai dan mengekstrak variabel lingkungan yang dibutuhkannya dan kemudian mengatur/menyerahkannya untuk diuji.

Saya lebih suka jika kita tidak menjalankan file batch dari dist.exe atau go.exe. Sulit untuk berurusan dengan file batch.

Kami juga mungkin ingin beberapa variabel lingkungan memberi tahu dist atau make.bat bahwa kami ingin menjalankan tes dengan set -compiler msvc.

Saya berharap Ian akan tahu apa pendekatan terbaik di sini. Dari apa yang saya tahu, kami juga mendukung kompiler C yang berbeda di Unix (gcc atau dentang). Tentunya proses pembuatan kami memungkinkan kami untuk menguji kompiler C yang berbeda.

Alex

Saya tidak menyadari sebelumnya bahwa Anda berencana untuk menggunakan go build -compiler msvc . Itu tidak masuk akal. Opsi go build -compiler mengambil nama kompiler Go (saat ini gc atau gccgo). Itu tidak mengambil nama kompiler C. Kompiler C dilewatkan dalam variabel lingkungan CC . Kompiler C default diatur dengan menyetel variabel lingkungan CC_FOR_TARGET saat menjalankan make.bat, seperti yang didokumentasikan dalam komentar di make.bat.

Saya berharap bahwa kita akan memiliki pembangun yang kita atur untuk mengatur variabel lingkungan CC_FOR_TARGET ke msvc sebelum menjalankan all.bat. Saya tidak mengerti mengapa kami harus melakukan hal lain.

Kompiler C dilewatkan dalam variabel lingkungan CC. Kompiler C default diatur dengan menyetel variabel lingkungan CC_FOR_TARGET saat menjalankan make.bat, seperti yang didokumentasikan dalam komentar di make.bat.

Terima kasih Ian atas penjelasannya.

@cchamplin Saya harap Anda dapat menyesuaikan perubahan Anda agar sesuai dengan model yang ada. Beri tahu kami, jika Anda memiliki masalah. Terima kasih.

Saya berharap bahwa kita akan memiliki pembangun yang kita atur untuk mengatur variabel lingkungan CC_FOR_TARGET ke msvc sebelum menjalankan all.bat.

Kami memiliki 3 pembuat jendela amd64 di https://build.golang.org. Haruskah kita mengganti satu menjadi MSVC? Apakah kita ingin 386 MSVC builder?

Alex

@ianlancetaylor @alexbrainman Mengerti tentang flag -compiler. Saya tidak berpikir ada cara mudah untuk membuat pengaturan CC="msvc" (atau benar-benar CC="cl.exe" ) berfungsi. CC masih perlu menunjuk ke lokasi GCC agar build MSVC berfungsi. Kumpulan alat kompiler msvc tidak memiliki alat yang tersedia untuk memungkinkan CGO melakukan introspeksi yang diperlukan (pencarian definisi, resolusi tipe) sehingga GCC masih diperlukan pada pembuatan MSVC, GCC tidak digunakan dalam fase kompilasi/penautan yang sebenarnya.

Apakah menambahkan flag baru untuk go build et all dapat diterima (toolchain atau semacamnya)? Saya sudah harus menambahkan flag toolchain ke cgo, saya percaya.

Juga pengaturan CC_FOR_TARGET sebelum all.bat sepertinya memiliki konsekuensi negatif karena akan mempengaruhi compiler yang digunakan dalam bootstrap. Saya tidak percaya MSVC dapat digunakan selama proses bootstrap (saya tidak 100% dalam hal ini, saya belum benar-benar mencoba tetapi saya sangat ragu itu akan berhasil)

Saya mengerti, untuk MSVC kita harus memiliki GCC dan MSVC? Di mana GCC hanya digunakan oleh alat cgo? Tampaknya agak disayangkan, karena itu berarti kita akan benar-benar mengandalkan GCC dan MSVC yang mengimplementasikan ABI yang persis sama, tapi saya rasa itu cukup mungkin.

Saya kira kita dapat menambahkan variabel lingkungan lain CC_FOR_CGO , yang dapat disetel ke GCC.

CC_FOR_TARGET digunakan oleh make.bat akan digunakan untuk membangun runtime/cgo. Tidak jelas bagi saya bagaimana cgo bisa bekerja sama sekali jika runtime/cgo tidak dibangun oleh kompiler C yang Anda gunakan.

Mungkin kita harus mulai dengan membuat semuanya berfungsi saat make.bat dipanggil dengan menyetel CC_FOR_TARGET ke cl dan CGO_ENABLED ke 0 .

Terima kasih @ianlancetaylor :

Saya mengerti, untuk MSVC kita harus memiliki GCC dan MSVC? Di mana GCC hanya digunakan oleh alat cgo? Tampaknya agak disayangkan, karena itu berarti kita akan benar-benar mengandalkan GCC dan MSVC yang mengimplementasikan ABI yang persis sama, tapi saya rasa itu cukup mungkin.

Saya setuju itu sangat disayangkan, dan akan senang mengetahui beberapa alternatif, saya belum menemukannya. Tentu saja ada risiko membangun dengan cara ini (misalnya kode cgo yang sedang dibangun memiliki tipe defs atau definisi yang berbeda tergantung pada kompiler apa yang menurutnya sedang dibangun). Jadi build mungkin tidak selalu berhasil atau berfungsi dengan benar tanpa beberapa penyesuaian (ada mekanisme untuk menangani ini dalam implementasi saya, tetapi ini sedikit proses manual). Sayangnya saya pikir ini adalah risiko yang harus diambil orang jika mereka ingin menggunakan rantai alat MSVC dan yang bisa kita lakukan hanyalah mendokumentasikannya untuk saat ini.

Pada catatan yang sama masih belum ada jalan nyata untuk menyediakan dukungan complex64 dan complex128 dalam program cgo yang dibuat MSVC hanya karena kompiler MSVC tidak sesuai dengan c99.

Saya kira kita dapat menambahkan variabel lingkungan lain CC_FOR_CGO , yang dapat disetel ke GCC.

Jadi implementasi yang saya miliki saat ini adalah jika go build diinstruksikan untuk membangun dengan MSVC maka secara default akan mencari cl.exe di jalur tetapi ini dapat diganti dengan variabel lingkungan MSCC. CGO akan terus menggunakan variabel lingkungan CC yang kembali ke gcc/apa pun yang ada di zdefaultcc.go yang dihasilkan

CC_FOR_TARGET digunakan oleh make.bat akan digunakan untuk membangun runtime/cgo. Tidak jelas bagi saya bagaimana cgo bisa bekerja sama sekali jika runtime/cgo tidak dibangun oleh kompiler C yang Anda gunakan.

Dalam implementasi saat ini cgo akan dengan senang hati bekerja untuk binari msvc bahkan jika seluruh rantai alat go telah dibangun oleh gcc. misalnya kode MSVC ditambahkan ke go/src. all.bat dijalankan membangun lingkungan go menggunakan gcc. Setelah itu go/bin/go.exe dapat digunakan untuk membangun dengan msvc toolchain (dengan asumsi flag disediakan). Saya mungkin salah paham dengan apa yang Anda katakan di sini.

Kompleksitas di sekitar ini karena mengatakan go yang ingin kami bangun dengan msvc lebih rumit daripada hanya mengganti kompiler ke cl. Toolchain MSVC sangat berbeda dari toolchain gcc. Di MSVC, lingkungan perlu diatur melalui menjalankan di dalam vcvars.bat (atau melakukan apa yang dilakukan v8 misalnya yang menjalankan vcvars.bat dan mengekstrak semua informasi yang dibutuhkan dari variabel lingkungan yang diaturnya dan kemudian menggunakannya dalam build mereka proses). Setelah kita berada di lingkungan MSVC perbedaan utama menjadi alat itu sendiri cl.exe digunakan untuk mengkompilasi file C dan C++, ml.exe dan ml64.exe digunakan untuk merakit file, dan akhirnya link.exe (ms) digunakan untuk menghubungkan semuanya bersama-sama. Jadi ini lebih dari sekadar menyetel CC=cl.exe dan memberikan flag yang tepat. Apakah itu masuk akal/membantu memperjelas sesuatu?

Untuk lebih memperjelas tentang

CC_FOR_TARGET yang digunakan oleh make.bat akan digunakan untuk membangun runtime/cgo. Tidak jelas bagi saya bagaimana cgo bisa bekerja sama sekali jika runtime/cgo tidak dibangun oleh kompiler C yang Anda gunakan.

go build sedang memilih file yang sesuai dari runtime/cgo selama proses pembuatan (misalnya go build / go test / go run -- bukan proses pembuat) ketika rantai alat msvc telah dipilih.

Saya terbuka untuk saran tentang cara kerjanya, tetapi seharusnya tidak memerlukan opsi baris perintah baru untuk alat go. Bisakah kita menulis program Go murni yang bertindak seperti GCC sejauh menyangkut alat go tetapi benar-benar menjalankan MSVC?

Bisakah kita menulis program Go murni yang bertindak seperti GCC sejauh menyangkut alat go tetapi benar-benar menjalankan MSVC?

Saya percaya itu mungkin bisa diterapkan, biarkan saya melihat apakah saya bisa mendapatkan sesuatu di jalur itu.

Selain itu, saya kira saya perlu mengklarifikasi jika menambahkan flag baris perintah ke alat lain juga akan menjadi masalah. Saat ini tambalan komprehensif untuk ini membuat beberapa flag baris perintah baru di berbagai alat

• cmd/cgo
  
  
  
  • -toolchain [gcc,msvc] (default ke gcc) Toolchain untuk digunakan saat membuat file keluaran cgo
  
  
• cmd/tautan
  
  
  
  • -rlocbss (default ke false) Pindahkan .bss ke .data
  
  
  • -toolchain [gcc,msvc] (default ke gcc) Toolchain yang akan digunakan untuk penautan eksternal
  
  

kami juga membuat opsi build/variabel lingkungan cgo berikut:

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

Setelah beberapa menit berpikir, ada beberapa rintangan yang mungkin sulit diatasi jika kita hanya mem-proxy perintah kompiler memikirkan program yang berbeda bersama-sama

1. go build perlu mengetahui apa itu toolchain eksternal untuk menentukan file runtime/cgo mana yang akan dibuat, jika tidak maka akan berakhir hanya dengan meneruskan versi gcc yang tidak kompatibel ke perintah proxy kami. Kami mungkin dapat meretas ini di dalam proxy itu sendiri tetapi akan rapuh dan cenderung rusak jika file tambahan ditambahkan ke runtime/cgo.
2. cmd/cgo perlu mengetahui jenis rantai alat eksternal apa yang digunakan untuk memilih versi kode C keluaran mana yang akan digunakan
3. Program proxy akan memerlukan beberapa mekanisme untuk mengetahui apakah program tersebut harus menjalankan gcc (seperti ketika dipanggil oleh cmd/cgo) atau untuk menjalankan cl.exe yang dapat diteruskan tetapi itu berarti penelepon perlu mengetahui rantai alat apa adalah atau kita akan meminta cmd/cgo meneruskan flag yang tidak ada ke gcc.
4. go build memanggil cmd/link yang juga perlu mengetahui toolchain apa sehingga dapat melakukan .bss ke .data relokasi dan agar dapat meneruskan flag tertentu ke linker (kami mungkin dapat menangani yang terakhir ini bagian dalam proxy itu sendiri)

Apakah menentukan variabel lingkungan untuk digunakan go build untuk menentukan build msvc berfungsi? Meskipun saya pikir itu menetapkan standar yang lebih tinggi untuk seseorang yang hanya ingin membangun program dengan msvc, karena mereka sekarang harus mengatur beberapa variabel lingkungan selain menjalankan di dalam vsvars.bat (minimal CC dan UNDECIDED_TURN_ON_MSVC_BUILD_VAR )

Alternatif lain adalah meminta go build menjalankan perintah noop palsu pada CC ditentukan dan kemudian mengurai logo/tajuk untuk mendeteksi apakah itu msvc atau gcc dan melanjutkan dengan penyesuaian rantai alat yang sesuai pada saat itu ...tidak yakin seberapa rapuhnya ini atau bagaimana cara kerjanya dengan rantai alat yang kompatibel dengan msvc seperti dentang.

Menemukan masalah Github ini baru-baru ini, dan pekerjaan ini sangat menarik bagi saya. Saya berharap ini mendarat di suatu tempat dalam waktu dekat.

Niat saya adalah menggunakan CGo di Windows sebagai pembungkus untuk beberapa kode pihak ke-3 yang telah dibuat menggunakan MSVC, yang tidak bisa saya bangun kembali dari sumber menggunakan mingw-w64 . Saya memiliki beberapa kasus uji yang relatif serius untuk dijalankan, sehingga dapat memvalidasinya dengan cukup baik.

Bagaimanapun, terima kasih kepada @cchamplin dan siapa pun yang mengerjakannya, dan tolong beri tahu saya, saya bisa membantu.

@cchamplin Saya cukup tahu untuk berbahaya tentang @deadprogram memiliki jadi saya memiliki test bed canggih baik ketika kita siap untuk tes.

Hai @mxplusb , tambalan sebenarnya kurang lebih sudah siap untuk digunakan. Jika saya dapat menemukan waktu saya akan mengirimkan perubahan ke gerrit malam ini atau besok yang akan membuat kami berjalan untuk mendapatkan semuanya ditinjau, diperbarui, dan disetujui.

Ubah https://golang.org/cl/133937 menyebutkan masalah ini: cmd/link: Add flag rlocbss to relocate .bss data to .data

Ubah https://golang.org/cl/133938 menyebutkan masalah ini: runtime/cgo: MSVC toolchain support in cgo native code

Ubah https://golang.org/cl/133939 menyebutkan masalah ini: cmd/cgo: Add toolchain flag to cgo command for MSVC support

Ubah https://golang.org/cl/133946 menyebutkan masalah ini: cmd/compile: Add support for MSVC toolchain to go build

Sepertinya saya salah ketik masalah di beberapa komit. Saya akan membiarkan proses peninjauan berlangsung dan menentukan cara terbaik untuk memperbaikinya.

Ubah https://golang.org/cl/133943 menyebutkan masalah ini: cmd/cgo: Add support for CC_FOR_CGO environment variable

Ubah https://golang.org/cl/133942 menyebutkan masalah ini: tests: Update various tests to prepare for MSVC compiler toolchain

Ubah https://golang.org/cl/133940 menyebutkan masalah ini: misc/cgo: Adjust tests to be compatible with MSVC toolchain support

Ubah https://golang.org/cl/133941 menyebutkan masalah ini: runtime: Add runtime.CompilerType to denote between host compiler type

Ubah https://golang.org/cl/133945 menyebutkan masalah ini: cmd/link: Add external toolchain support for MSVC

Ubah https://golang.org/cl/133944 menyebutkan masalah ini: cmd/compile, cgo: Add support for MSVC flags

@cchamplin dapatkah Anda menjelaskan apa keputusan akhir? Seperti apa dukungan MSVC? Bendera baris perintah apa yang akan ditambahkan? Apa yang harus dilakukan pengguna terhadap lingkungan mereka selain mengunduh MSVC? Terima kasih

Juga, bagaimana kita bisa mencoba patch ini? Saya tidak dapat menemukan komitmen Anda di repo.

@rasky Masih sedikit berubah saat perubahan ditinjau. Kemungkinan tidak akan ada flag baris perintah khusus yang perlu disetel, cukup buat aplikasi cgo di mana variabel lingkungan CC diarahkan ke MSVC atau tidak ada CC yang disetel, cl.exe ada di jalurnya tetapi gcc tidak.

@blizzardplus Mirip dengan hal-hal di atas sedang banyak berubah sekarang dengan ulasan, jadi mungkin agak awal untuk mulai mencobanya (terserah Anda). Semua perubahan terkait telah diposting kembali ke masalah ini oleh gopherbot, Anda dapat menemukannya di sana.

@cchamplin apakah ada dukungan untuk kompilasi silang menggunakan gcc atau clang ? Jika demikian, apakah mereka diuji?

@cchamplin Saya tidak melihat aktivitas apa pun di CL sejak 9/11, apakah ada kemajuan untuk ini atau apakah itu membutuhkan sumber daya tambahan?

@cchamplin agar ini berfungsi untuk arsip c, bagian ctors harus diubah menjadi .CRT$XCU (https://msdn.microsoft.com/en-us/library/bb918180.aspx) - Jika ini tidak dilakukan maka golang runtime tidak akan diinisialisasi. Juga, ternyata, jika Anda menyetelnya ke ini, ini juga berfungsi dengan baik untuk gcc - gcc masih menggunakan fungsi-fungsi itu, memindahkannya ke bagian teks, dan memodifikasi main untuk memanggilnya sebelum main yang sebenarnya. Visual Studio dapat memahami file .a arsip dan, karena antarmuka file yang telah dikompilasi/dirakit adalah C, seharusnya tidak ada masalah hanya dengan memiliki ini di arsip. Ada peringatan tentang 2 bagian .text tetapi kasus sederhana tampaknya berfungsi dengan baik (perlu pengujian lebih lanjut untuk konfirmasi tidak ada masalah).

Juga, agar ini berfungsi untuk c-shared, fungsi yang akan diekspor harus didekorasi __declspec(dllexport), tetapi sepertinya saya tidak dapat menemukan di mana perluasan //ekspor ini terjadi.

@blizzardplus Ada tambalan tindak lanjut untuk ini untuk mendukung dentang-MSVC. Saya tidak yakin apa yang Anda maksud dengan kompilasi silang dalam kasus ini? Anda tidak akan dapat menggunakan rantai alat MSVC pada sistem non-jendela. Fungsi kompilasi silang lainnya tidak boleh berubah.

@kshelton Sayangnya ini adalah waktu yang sangat sibuk sepanjang tahun bagi saya karena saya memiliki proyek lain dalam pekerjaan dan konferensi yang saya hadiri. Saya mungkin tidak dapat kembali memasukkan refactoring yang diperlukan ke dalam patch hingga Desember.

@kshelton Terima kasih. Saya belum memeriksa tambalan dua kali, saya berasumsi bahwa saya mengembangkannya dengan asumsi bahwa c-archive tidak akan berfungsi pada MSVC, atau secara khusus menonaktifkannya? Saya menempuh jalan untuk mencoba menghias ekspor dengan benar ketika saya mencoba membuat plugin/berbagi berfungsi di windows. Ada masalah lain yang saya yakini, tetapi saya bisa menggabungkan dua masalah. Ada masalah nyata dengan cara memasukkan kode yang dibagikan ke dalam PLT/GOT untuk ELF vs Windows .edata,idata, dan EAT. Saya percaya sebagian besar masalah yang saya hadapi adalah seputar relokasi dan tidak dapat membuatnya bekerja. Jika ada yang memiliki wawasan dalam hal ini, itu akan luar biasa. Lihat #19282

@cchamplin Saya mencoba melihat, apakah saya dapat membangun Go di atas CL Anda

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

Saya menggunakan file batch ini untuk mengatur lingkungan saya

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

dan saya mendapatkan kesalahan ini ketika saya menjalankan 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>

Apa yang kulewatkan di sini?

Terima kasih.

Alex

@alexbrainman

Apa yang kulewatkan di sini?

Anda mungkin setidaknya perlu mengatur CC_FOR_CGO=gcc. Saya juga tidak pernah secara pribadi mencoba membangun go sendiri dengan MSVC. Saya tidak yakin apakah ini akan berhasil/harus didukung.

-C

Anda mungkin setidaknya perlu mengatur CC_FOR_CGO=gcc.

https://go-review.googlesource.com/c/go/+/133940 Anda berisi beberapa tes. Bagaimana cara memverifikasi kelulusan tes? Apa langkah-langkah yang tepat?

Juga pembuat Go https://build.golang.org jalankan %GOROOT%\src\all.bat untuk memverifikasi semua pengujian (termasuk yang terdaftar di https://go-review.googlesource.com/c/go/+/ 133940) lulus. Bagaimana Anda mengusulkan agar kami memodifikasi kode Go untuk membuat %GOROOT%\src\all.bat menjalankan pengujian yang disesuaikan dari https://go-review.googlesource.com/c/go/+/133940. Mungkin all.bat dapat menguji versi pengujian gcc dan msvc. Mungkin kita dapat menggunakan beberapa variabel lingkungan yang memberi tahu all.bat versi pengujian mana yang harus dijalankan - maka kita dapat meminta dua pembuat berbeda menjalankan versi pengujian yang berbeda. Apakah Anda memikirkan itu semua?

Saya juga tidak pernah secara pribadi mencoba membangun go sendiri dengan MSVC. Saya tidak yakin apakah ini akan berhasil/harus didukung.

Anda dapat menjalankan all.bat hingga berhasil diselesaikan tanpa menginstal gcc. Versi Go saat ini hanya membutuhkan versi Go lain (setidaknya go1.4) untuk dibangun. Hanya Cgo yang membutuhkan kompiler C, saya mendapat kesan bahwa perubahan Anda mengimplementasikan versi Cgo yang dibuat oleh MSVC. Tapi, mungkin, saya salah. Tolong koreksi saya jika saya salah.

Terima kasih.

Alex

@alexbrainman

https://go-review.googlesource.com/c/go/+/133940 Anda berisi beberapa tes. Bagaimana cara memverifikasi kelulusan tes? Apa langkah-langkah yang tepat?

Mungkin all.bat dapat menguji versi pengujian gcc dan msvc. Mungkin kita dapat menggunakan beberapa variabel lingkungan yang memberi tahu all.bat versi pengujian mana yang harus dijalankan - maka kita dapat meminta dua pembuat berbeda menjalankan versi pengujian yang berbeda. Apakah Anda memikirkan itu semua?

Ya, mekanisme persis ini digunakan di https://go-review.googlesource.com/c/go/+/133946/. Karena semua panggilan ke run.bat di windows, mekanisme untuk memanggil tes cgo ditempatkan di sana. Jadi, Anda atau pembuatnya akan memulai dengan penyiapan normal CC=gcc. Kemudian Anda akan mengatur jalur GOTESTMSVC=1 dan GOVSVARSPATH=some vsvars.bat. Setelah itu membangun dengan all.bat harus dijalankan melalui tes cgo gcc dan msvc.

Anda dapat menjalankan all.bat hingga berhasil diselesaikan tanpa menginstal gcc. Versi Go saat ini hanya membutuhkan versi Go lain (setidaknya go1.4) untuk dibangun. Hanya Cgo yang membutuhkan kompiler C, saya mendapat kesan bahwa perubahan Anda mengimplementasikan versi Cgo yang dibuat oleh MSVC. Tapi, mungkin, saya salah. Tolong koreksi saya jika saya salah.

Anda benar. Go sendiri harus dibangun dengan baik. Mungkin ada masalah saat melakukan pengujian, karena run.bat telah dimodifikasi untuk mengatur beberapa variabel lingkungan saat GOTESTMSVC=1. Kami mungkin dapat mencoba mendeteksi apakah go baru saja dibuat dengan msvc, dan kemudian mengatur variabel lingkungan dist yang sesuai sehingga pengujian tidak gagal.

Kemudian Anda akan mengatur jalur GOTESTMSVC=1 dan GOVSVARSPATH=some vsvars.bat. Setelah itu membangun dengan all.bat harus dijalankan melalui tes cgo gcc dan msvc.

Saya mencoba itu.

saya menggunakan

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

Saya menjalankan file batch ini terlebih dahulu:

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

dan kemudian jalankan all.bat . all.bat gagal dengan

--- 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

Juga pengaturan GOTESTMSVC dan GOVSVARSPATH mungkin berfungsi untuk orang yang menjalankan all.bat. Tapi apa yang akan dilakukan pengguna lain dari perubahan Anda ketika mereka perlu menggunakan MSVC untuk Cgo? Apa rencana Anda untuk itu?

Alex

@alexbrainman
Saya tidak yakin apa yang terjadi. Tes itu gagal untukku di master

> 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

Di help.go https://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/internal/help/help.go#L37
iterasi melalui base.Go.Commands. Yang diinisialisasi di main.go https://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/main.go#L43
tapi saya tidak yakin bagaimana fungsi init akan dipanggil dalam tes yang dapat dieksekusi, jadi saya tidak tahu bagaimana master lulus tes sekarang, karena saya pikir ini harus gagal di seluruh papan.

Juga pengaturan GOTESTMSVC dan GOVSVARSPATH mungkin berfungsi untuk orang yang menjalankan all.bat. Tapi apa yang akan dilakukan pengguna lain dari perubahan Anda ketika mereka perlu menggunakan MSVC untuk Cgo? Apa rencana Anda untuk itu?

Jadi dalam situasi di mana Anda hanya ingin membuat beberapa kode Cgo dengan MSVC

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

seharusnya semua yang Anda butuhkan, saya pikir

Saya tidak yakin bagaimana fungsi init akan dipanggil dalam tes yang dapat dieksekusi, jadi saya tidak tahu bagaimana master lulus tes sekarang, karena saya pikir ini harus gagal di seluruh papan.

Saat menggunakan go test dengan file dalam cmd/go, alat go akan membangun paket cmd/go dan kemudian membangun tes, menghasilkan driver uji, membangunnya, dan menautkan semuanya menjadi satu paket utama baru. Ini terjadi meskipun cmd/go itu sendiri adalah paket utama. Artinya, paket utama dalam cmd/go/*.go akan diperlakukan sebagai paket non-utama untuk keperluan pengujian. Ini memungkinkan pengujian untuk memanggil fungsi yang ditentukan dalam paket utama jika sesuai.

Maaf, saya lambat membalas. Tapi aku tidak punya waktu luang untuk melihat ini lagi.

Saya tidak yakin apa yang terjadi. Tes itu gagal untukku di master

Saya tidak menggunakan master. Saya menggunakan komit e56d52f66b95b87001867a2487a11bd961f40d4d Anda. Bukankah Anda menjalankan all.bat pada komit itu sebelum mengirimkannya untuk ditinjau? Apakah all.bat berhasil? Bisakah Anda mencoba menjalankan all.bat pada komit itu lagi untuk melihat, apakah itu ada hubungannya dengan konfigurasi sistem saya. Terima kasih.

Jadi dalam situasi di mana Anda hanya ingin membuat beberapa kode Cgo dengan MSVC

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

seharusnya semua yang Anda butuhkan, saya pikir

2 variabel lingkungan, mungkin, terlalu rumit untuk rata-rata pengguna. Dan CC_FOR_CGO=gcc tampak aneh bagi saya - mengapa kami menggunakan gcc untuk membuat kode dengan MSVC?

Alex

@alexbrainman

Saya tidak menggunakan master. Saya menggunakan komit e56d52f66b95b87001867a2487a11bd961f40d4d Anda. Bukankah Anda menjalankan all.bat pada komit itu sebelum mengirimkannya untuk ditinjau? Apakah all.bat berhasil? Bisakah Anda mencoba menjalankan all.bat pada komit itu lagi untuk melihat, apakah itu ada hubungannya dengan konfigurasi sistem saya. Terima kasih.

Saya pikir itu ada hubungannya dengan konfigurasi sistem saya yang memberi saya hasil aneh saat menjalankan tes. Saya pikir saya telah memperbaiki masalah ini dan mendorong beberapa pembaruan ke set perubahan.

2 variabel lingkungan, mungkin, terlalu rumit untuk rata-rata pengguna. Dan CC_FOR_CGO=gcc terlihat aneh bagi saya - mengapa kami menggunakan gcc untuk membuat kode dengan MSVC?

Seharusnya sebenarnya CC_FOR_CGO=gcc.exe, kesalahan saya. Tetapi untuk menjawab pertanyaan Anda; dari gerrit:

PS1, Jalur 1324:
cgo masih membutuhkan gcc yang tersedia untuk analisis tipe. Jika CC diatur ke kompiler MSVC, cgo membutuhkan sarana untuk memanggil GCC yang disediakan oleh CC_FOR_CGO. Sayangnya, rantai alat MSVC tidak memiliki mekanisme untuk menyediakan jenis informasi yang sama yang dikumpulkan dari gcc. Secara teoritis alat khusus go dapat dibuat untuk mengumpulkan informasi jenis yang digunakan oleh cgo tetapi itu mungkin di luar cakupan dan mungkin upaya yang cukup besar (saya pribadi tidak pernah menulis apa pun untuk melakukan analisis tipe statis kode C/C++).

Saya juga tampaknya telah memecahkan sesuatu dengan cache yang jelas antara berjalan untuk GCC vs MSVC, saya tidak yakin mengapa beberapa tes masih bertindak seolah-olah mereka di-cache.

Saya pikir saya telah memperbaiki masalah ini dan mendorong beberapa pembaruan ke set perubahan.

Pengaturan ini https://github.com/golang/go/issues/20982#issuecomment -447618566 di

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

membawa saya lebih jauh, tetapi masih gagal dengan

##### 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>

Seharusnya sebenarnya CC_FOR_CGO=gcc.exe, kesalahan saya.

Saya tidak peduli tentang .exe di gcc.exe. Masalah saya adalah

• Anda memerlukan alat gcc dan MSVC untuk menggunakan MSVC (akan sulit untuk menjelaskannya kepada pengguna kami), tetapi saya mengerti bahwa tidak ada yang dapat dilakukan untuk itu;

• Saya membutuhkan kedua variabel lingkungan CC_FOR_CGO=gcc dan CC=cl.exe set - mungkin kita bisa berasumsi CC_FOR_CGO selalu disetel ke gcc?

Tetapi untuk menjawab pertanyaan Anda; dari gerrit:

Terima kasih telah menjelaskan.

Alex

@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

Saya tidak yakin bagaimana peringatan itu akan terjadi kecuali Anda entah bagaimana memiliki salinan msvc_libinit_windows.c yang berbeda/lama. Bisakah Anda mengonfirmasi bahwa ada baris ini di dalamnya:

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

C4710 harus ditekan untuk menyertakan stdio. Saya melihat bahwa versi MSVC Anda sedikit berbeda dari versi saya, yang juga bisa menjadi penyebabnya. Saya tidak yakin mengapa mereka secara aktif mengabaikan penindasan itu dalam versi yang berbeda.

Anda juga dapat mencoba membuat perubahan untuk memasukkan penindasan secara global, apa pun yang terjadi

// 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") 

Saya membutuhkan kedua variabel lingkungan CC_FOR_CGO=gcc dan CC=cl.exe set - mungkin kita bisa berasumsi CC_FOR_CGO selalu disetel ke gcc?

Saya pikir gco memeriksa apakah gcc ada jika CC_FOR_CGO tidak disetel akan baik-baik saja. CC_FOR_CGO lebih untuk orang-orang seperti saya yang tidak memiliki gcc di jalur mereka. CC_FOR_CGO saya terlihat seperti ini CC_FOR_CGO=I:\Development\tmd-gcc\bingcc.exe. Jika kami tidak ingin mendukung usecase GCC yang tidak berada di jalur untuk pembuatan MSVC, beri tahu saya dan saya dapat menyingkirkan variabel lingkungan secara bersamaan.

Saya mencoba lagi versi ini

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

dan saya mendapatkan kesalahan yang sama

##### 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>

Bisakah Anda mengonfirmasi bahwa ada baris ini di dalamnya:

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

Ini adalah awal dari file src/runtime/cgo/msvc_libinit_windows.c saya

// 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>
...

Anda juga dapat mencoba membuat perubahan untuk memasukkan penindasan secara global, apa pun yang terjadi

// 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") 

Saya membuat perubahan ini:

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>

tapi saya melihat kesalahan yang sama

##### 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>

Alex

Saya mencoba untuk mereproduksi ini tadi malam dan saya tidak bisa. Saya ingin tahu apakah Anda mengalami ini: https://developercommunity.visualstudio.com/content/problem/35734/c-cannot-disable-specific-warnings-with-pragmas-wh.html

Apakah mungkin bagi Anda untuk memperbarui ke SDK dan Alat Bangun terbaru? Saya menggunakan SDK 10.0.17763.0. dan versi 15.9.28307.222 dari alat pembangunan/pengembangan

Saya mencoba membuat Windows DLL dengan MSVC, tetapi sepertinya Go mencoba menonaktifkan beberapa peringatan dengan angka lebih dari 65535 (atau bukan angka), yang menyebabkan MSVC berhenti.

Tidak. Werror adalah opsi GCC, untuk memperlakukan setiap peringatan sebagai kesalahan.

Untuk MSVC Anda harus menggunakan WX .

@pravic poin bagus, bagaimana saya melakukannya? Saya tidak mengaturnya, yang saya lakukan hanyalah:

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

@galich Sayangnya, saya tidak dapat membantu karena saya tidak mengikuti integrasi MSVC.

Misalnya, di mana tambalan yang terkait dengan utas ini? Di master atau di tempat lain?

@pravic Anda dapat menemukan perubahannya di sini: https://go-review.googlesource.com/c/go/+/133946/5

@mxplusb terima kasih atas tautannya, sepertinya masalah khusus saya dengan /Werror telah diselesaikan di sana.
Apakah Anda tahu kapan ini akan menjadi versi beta/nightly/stable?

Apakah mungkin bagi Anda untuk memperbarui ke SDK dan Alat Bangun terbaru? Saya menggunakan SDK 10.0.17763.0. dan versi 15.9.28307.222 dari alat pembangunan/pengembangan

@cchamplin akhirnya saya berhasil memperbarui MSVC saya. saya punya sekarang

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>

Saya mencoba lagi versi ini

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

dan all.bat berhasil diselesaikan. Tapi saya mendapatkan peringatan ini.

##### ../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>

Dan juga saya perhatikan bahwa Anda menjalankan semua tes dua kali.

...
##### 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
...

Mengapa?

Alex

@alexbrainman Peringatan kemungkinan dapat ditekan untuk tes ini, terutama dalam hal ini peringatan momok.

Untuk pengujian yang dijalankan dua kali, saya yakin itu dilakukan dengan cara itu untuk pembuatnya, jalankan pengujian sekali dengan kompilasi gcc kemudian jalankan lagi dengan MSVC (bila diaktifkan) untuk memastikan kompilasi dengan kedua rantai alat berfungsi. Saya tidak yakin apa yang diinginkan di sini, jadi saya dapat mengubahnya sehingga ketika all.bat dipanggil dengan MSVC diaktifkan, kami hanya menjalankan tes dengan MSVC, beri tahu saya. Dalam hal ini saya menganggap pembangun tambahan perlu ditambahkan hanya untuk MSVC, sebagai lawan dari beberapa pembangun yang juga membangun dengan MSVC?

Setuju bahwa pada Windows akan diperlukan untuk menjalankan satu pembuat menggunakan rantai alat MinGW-W64 dan lainnya dengan rantai alat MSVC untuk menguji kedua skenario.

Saya percaya itu dilakukan dengan cara itu untuk pembangun, jalankan tes sekali dengan kompilasi gcc kemudian jalankan lagi dengan MSVC (bila diaktifkan) untuk memastikan kompilasi dengan kedua rantai alat berfungsi.

Saya setuju ini harus menjadi perilaku yang disukai sehingga ada jaminan itu tidak merusak beban kerja yang ada jika kedua rantai alat ada.

Peringatan kemungkinan dapat ditekan untuk tes ini, terutama dalam hal ini peringatan hantu.

Perintah Go tidak menampilkan peringatan, jadi peringatan tidak boleh ditampilkan.

Saya juga memperhatikan bahwa perintah go env tidak menampilkan variabel CC_FOR_CGO. Jika CC_FOR_CGO memengaruhi cara kerja go build, maka CC_FOR_CGO harus ditampilkan bersama dengan yang lain. Apakah kita benar-benar membutuhkan variabel CC_FOR_CGO? Apa lagi, tapi CC_FOR_CGO=gcc bisa?

Untuk pengujian yang dijalankan dua kali, saya yakin itu dilakukan dengan cara itu untuk pembuatnya, jalankan pengujian sekali dengan kompilasi gcc kemudian jalankan lagi dengan MSVC (bila diaktifkan) untuk memastikan kompilasi dengan kedua rantai alat berfungsi.

Banyak tes tidak menggunakan gcc. Buang-buang waktu orang / komputer ketika tes paket berjalan dua kali tanpa alasan. Seperti yang Anda lihat dari https://github.com/golang/go/issues/20982#issuecomment -480569880 archive/zip paket tes dijalankan dua kali - Saya tidak melihat perlunya menjalankan kedua.

Saya tidak yakin bagaimana mengaturnya, tetapi mungkin Anda harus mengganti panggilan go tool dist test di run.bat untuk melakukan pilihan tes yang diperlukan untuk menguji build MSVC. Lihat, misalnya, go tool dist test -h tentang bagaimana Anda dapat memilih hanya beberapa tes tertentu. @bradfitz mungkin kita bisa membuat beberapa flag atau variabel lingkungan yang akan memberi tahu perintah dist untuk menjalankan tes khusus MSVC.

Tetapi secara umum https://go-review.googlesource.com/c/go/+/133946/5 Anda membangun yang dapat dieksekusi untuk saya. Misalnya, saya dapat membangun yang dapat dieksekusi dengan 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>

dan kemudian saya dapat membangun yang dapat dieksekusi dengan 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>

Jadi membangun dengan MSVC akan mengharuskan pengguna untuk menjalankan file batch MS untuk mengatur semua variabel lingkungan (lihat GOVSVARSPATH di output saya) - dan itu, saya asumsikan, standar dan tidak ada hubungannya dengan Go. Dan set CC=cl . Cukup sederhana.

Satu-satunya masalah yang saya lihat dengan pendekatan ini adalah bahwa pengguna MSVC masih harus menginstal gcc. gcc digunakan oleh cmd/cgo untuk menemukan semua antarmuka C - bagian ini tidak diimplementasikan dengan menggunakan MSVC. Kedengarannya tidak biasa bagi orang yang tidak tahu cara kerja cmd/cgo, tetapi memang begitu.

@ianlancetaylor dan @bradfitz apakah ini semua terdengar masuk akal untuk mendorong ini ke depan? Haruskah kita mencoba dan membuatnya tersedia di go1.13 ?

Builder yang telah menginstal MSVC dapat menguji semua kode baru. Pembangun lain hanya akan melewati tes.

Alex

gcc digunakan oleh cmd/cgo untuk menemukan semua antarmuka C - bagian ini tidak diimplementasikan dengan menggunakan MSVC.

Bagaimana itu bisa diatasi? Idealnya akan lebih bagus jika tidak ada persyaratan untuk gcc, hanya MSVC.

Bagaimana itu bisa diatasi?

Bagian dari cmd/cgo yang menggunakan gcc perlu ditulis ulang untuk menggunakan MSVC. Jika itu memungkinkan.

Alex

Saya bertanya-tanya apakah fitur ini lebih dekat untuk membuatnya menjadi produksi? Saya melihat bahwa itu ditandai untuk 1,13, dan itu baru saja keluar. Saya mencoba membuat ekstensi Python menggunakan build Go c-archive yang ditautkan ke kode ekstensi, tetapi Python membutuhkan MSVC.

Saya tidak tahu apa status masalah ini. Sudah ditendang maju dari rilis ke rilis, jadi saya akan memindahkannya ke tidak direncanakan. Jika masuk ke 1,14, bagus.

Bahkan dengan persyaratan kompilator ganda, saya ingin melihat implementasi saat ini membuatnya menjadi rilis berikutnya. Setidaknya memungkinkan untuk mengkompilasi executable/libraries menggunakan MSVC, yang lebih baik daripada tidak sama sekali.

Bahkan dengan persyaratan kompilator ganda, saya ingin melihat implementasi saat ini membuatnya menjadi rilis berikutnya.

Saya pikir ini akan menjadi implementasi "beta" yang bagus. Itu akan memungkinkan bug dihapus dan implementasinya mulai matang. Apa lagi yang harus dilakukan sebelum bisa melalui tinjauan serius?

Jadi dari sudut pandang saya dan apa yang dapat saya ingat dari terakhir kali saya melihat ini (~ 6 bulan yang lalu) ada selusin item pembersihan yang perlu diselesaikan untuk proses peninjauan kode. Pekerjaan tambahan mungkin juga diperlukan untuk menghilangkan duplikasi beberapa tes yang pada dasarnya disalin dengan modifikasi yang sangat kecil untuk bekerja dengan rantai alat yang berbeda. Ada juga kebutuhan untuk meninjau dan mematikan peringatan msvc tertentu.

Masalah utama yang menonjol meliputi:

Kami tidak dapat melakukan analisis tipe tanpa gcc, tidak ada solusi sederhana atau langsung untuk ini.

Menyelesaikan penyiapan dan bagaimana semuanya akan bekerja untuk pembangun.

Saya percaya ada beberapa perubahan yang cukup signifikan pada kompiler dan tautan dalam 6 bulan terakhir yang mungkin sangat memengaruhi pekerjaan yang dilakukan saat ini untuk ini, tetapi saya belum dapat mengonfirmasinya. Karena kompleksitas dan kurva belajar yang tinggi seputar menavigasi kompiler/linker/toolchain Go, mungkin perlu waktu yang cukup lama bagi saya untuk mendapatkan kecepatan yang cukup untuk mengetahui dampaknya jika ada perubahan pada badan pekerjaan ini.

Tidak ada dukungan untuk tipe numerik kompleks. MSCVs C lib sama sekali tidak kompatibel. Saya percaya kemungkinan ada cara untuk menghindari ini dengan C++ tapi saya tidak yakin, mungkin seseorang dari MS yang akrab dengan rantai alat MSVC dapat bergabung.

Sayangnya kehidupan dan proyek-proyek lain telah menghalangi saya untuk meluangkan lebih banyak waktu untuk ini, tetapi saya akan mencoba dan meluangkan waktu untuk ini dalam beberapa minggu mendatang.

@manbearian masalah ini adalah tentang menambahkan dukungan MSVC ke golang. Siapa di tim MSVC yang baik untuk berkonsultasi untuk pertanyaan MSVC?

@kesmit13 dan @mxplusb

Ini

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

adalah @cchamplin kode terbaru yang berfungsi.

Kekhawatiran saya saat ini dengan kode, bahwa tidak jelas bagaimana menggunakannya. Perintah apa yang Anda jalankan? Bagaimana lingkungan saya perlu diatur?

Saya pikir langkah selanjutnya adalah seseorang mencoba dan menggunakan kode itu, dan melihat apakah mereka benar-benar dapat menggunakannya. Jika berhasil, maka langkah-langkahnya perlu didokumentasikan, sehingga orang lain juga dapat menggunakan kode tersebut. Mungkin terlalu rumit, atau tidak berhasil. Daripada kita perlu menyesuaikan kode yang sesuai.

Setelah kami puas dengan status kode saat ini, kami harus mengubahnya menjadi master. Ada terlalu banyak perubahan yang disesuaikan dengan file yang berbeda, sehingga tidak mudah untuk di-rebase. Mungkin kita bisa menyesuaikan perubahan untuk membuat lebih sedikit perubahan, sehingga lebih mudah untuk melakukan rebase.

Alex

@mxplusb @kesmit13 Implementasi saat ini telah di-rebase terhadap master dan dapat ditemukan di sini: https://go-review.googlesource.com/c/go/+/133946/6

@alexbrainman

Kekhawatiran saya saat ini dengan kode, bahwa tidak jelas bagaimana menggunakannya. Perintah apa yang Anda jalankan? Bagaimana lingkungan saya perlu diatur?

Saya setuju bahwa dokumentasi perlu ditambahkan tentang cara menggunakan ini. Saya tidak sepenuhnya yakin di mana harus meletakkannya, beri tahu saya jika Anda memiliki pemikiran. Idk apakah itu harus berada di bawah dokumentasi cmd/go untuk membangun/menjalankan melalui MSVC, atau apakah itu harus hidup di bawah dokumentasi CGO, atau mungkin di tempat lain sama sekali?

Banyak tes tidak menggunakan gcc. Buang-buang waktu orang / komputer ketika tes paket berjalan dua kali tanpa alasan. Seperti yang Anda lihat dari #20982 (komentar) arsip/zip paket tes dijalankan dua kali - saya tidak melihat perlu untuk menjalankan kedua.

Saya tidak yakin bagaimana mengaturnya, tetapi mungkin Anda harus mengganti call of go tool dist test di run.bat untuk melakukan pilihan tes yang diperlukan untuk menguji build MSVC. Lihat, misalnya, go tool dist test -h tentang bagaimana Anda dapat memilih hanya beberapa tes tertentu. @bradfitz mungkin kita bisa membuat beberapa flag atau variabel lingkungan yang akan memberi tahu perintah dist untuk menjalankan tes khusus MSVC.

Perubahan sudah menyertakan variabel lingkungan yang ditambahkan ke dist untuk memberi tahu bahwa kami sedang melakukan hal-hal MSVC "GO_TEST_TESTINGMSVC" Saya percaya. Yang saya tidak yakin adalah bagaimana kita akan memfilter tes untuk dijalankan ke hal-hal yang hanya dapat berdampak pada MSVC jika kita tidak menjalankan semua tes dua kali. Berpotensi hanya membatasi untuk tes terkait CGO, tapi saya yakin ada tes CGO di semua tempat dan saya tidak tahu apakah dist memiliki mekanisme untuk menyaringnya?

Saya tidak sepenuhnya yakin di mana harus meletakkannya, beri tahu saya jika Anda memiliki pemikiran.

Saya pikir sebelum memperbarui dokumentasi apa pun, Anda harus menjelaskan cara membuat kode Cgo dengan MSVC di sini. Untuk @mxplusb dan @kesmit13 agar mereka dapat mencoba perubahan Anda.

Misalnya, untuk menggunakan gcc untuk membuat kode Cgo, saya

1. sesuaikan %PATH% saya untuk menyertakan gcc.exe
2. build Go dulu dengan menjalankan make.bat dari direktori %GOROOT%\src
3. gunakan perintah standar go build dan go install

Bagaimana saya melakukan hal yang sama dengan MSVC?

Yang saya tidak yakin adalah bagaimana kita akan memfilter tes untuk dijalankan ke hal-hal yang hanya dapat berdampak pada MSVC jika kita tidak menjalankan semua tes dua kali. Berpotensi hanya membatasi untuk tes terkait CGO, tapi saya yakin ada tes CGO di semua tempat dan saya tidak tahu apakah dist memiliki mekanisme untuk menyaringnya?

Saya akan mulai dengan direktori %GOROOT%\misc\cgo. Sumber apa pun yang dapat Anda bangun di sana, Anda harus membangun. Apa pun di atas itu terserah Anda.

Alex

@cchamplin maaf atas keterlambatan ini, saya akan melakukan yang terbaik untuk mengujinya minggu ini dan memberi tahu Anda bagaimana kelanjutannya.

Hai, teman-teman maaf terlambat ke pesta... saya dapat mencoba dan menjawab pertanyaan tentang fungsionalitas MSVC atau mengarahkan Anda ke orang-orang yang bisa. saya membaca percakapan, tetapi sayangnya, saya tidak cukup akrab dengan go untuk memahami fungsionalitas GCC yang diperlukan yang mungkin atau mungkin tidak hilang dari MSVC.

Hai Teman-teman,
Apakah fitur ini dirilis di Go 1.14?
Jika dirilis, silakan bagikan dokumen apa pun yang tersedia untuk digunakan.
Jika belum dirilis, apakah ada ide kapan akan dirilis?
Sangat menunggu dukungan MSVC.
Terima kasih sebelumnya :)

Hai, tidak ada yang pernah menanggapi permintaan saya untuk informasi lebih lanjut, jadi saya tidak yakin apa yang dibutuhkan. Dapatkah seseorang mengisi saya silahkan?

Sayangnya, saya tidak tahu apakah ada yang secara aktif menangani masalah ini.

Hai, tidak ada yang pernah menanggapi permintaan saya untuk informasi lebih lanjut, ...

Halo @manbearian

Permintaan yang mana itu? Informasi apa yang Anda butuhkan?

Alex

Saya telah ditandai sebelumnya di utas ini untuk mendapatkan informasi, tetapi saya tidak tahu apa yang dicari orang dan tidak dapat membantu. Jika tidak ada bantuan yang dibutuhkan, itu bagus. Tolong beri tahu saya.

Tolong beri tahu saya.

@manbearian

Terima kasih atas tawaran Anda. Saya tidak tahu siapa yang menandai Anda. Jika mereka masih membutuhkan bantuan, mereka akan menandai Anda lagi.

Alex

Jika belum dirilis, apakah ada ide kapan akan dirilis?
Sangat menunggu dukungan MSVC.

@dhineherode91

Kode ada dan lengkap; Saya percaya satu-satunya hal yang benar-benar menahan ini adalah orang-orang menguji perubahan dan memberikan umpan balik sehingga mereka dapat ditinjau dan disetujui dengan benar. Saya ragu untuk mengubah basis perubahan di atas master saat ini. Saya sudah melakukannya 5-6 kali dan itu sangat memakan waktu, dan kemudian saya tidak mendapatkan pengujian/umpan balik. Kecuali pihak tambahan bersedia untuk berpartisipasi dalam pengujian ini, masalahnya mungkin sudah mati di dalam air.

Kecuali pihak tambahan bersedia untuk berpartisipasi dalam pengujian ini, masalahnya mungkin sudah mati di dalam air.

@cchamplin mengandalkan saya untuk menguji/

@cchamplin Senang mendengar bahwa bagian implementasi telah selesai.
Saya tertarik untuk terlibat dalam bagian pengujian, tetapi saya seorang pemula di GoLang dan juga pembelajar yang baik di windows apis (dimulai beberapa minggu sebelumnya). Saya berencana untuk bekerja dengan windows api di MS C++ karena sepertinya banyak sumber resmi tersedia untuk itu. Tapi kemudian saya mulai mencari bahasa (untuk pemrograman sistem saya) di mana saya bisa menggunakannya untuk pemrograman sistem multi platform saya dan saya terkesan dengan GoLang. Selalu siap untuk kontribusi dari saya dan sangat membutuhkan bimbingan.

@cchamplin jika Anda rebase, saya akan mencoba membangun di atasnya. Saya ingin membatalkan persyaratan mingw64 dari beberapa proyek saya di tempat kerja. Perkakas bangunan saya sudah siap untuk MSVC, jadi saya tidak perlu melakukan apa pun selain menggunakan tambalan Anda.

@cchamplin juga, saya melihat-lihat

@ericlagergren

@cchamplin juga, saya melihat-lihat

Tidak yakin apakah saya mengerti, di https://go-review.googlesource.com/c/go/+/133946/6 banyak komit terkait langsung menyentuh bagian cgo dari Go dalam beberapa kapasitas.

@ccahoon oke, saya pasti merindukan mereka. Jika alat cgo belum diperbarui, saya akan menawarkan untuk melakukan itu.

@ericlagergren

Saya ingin membatalkan persyaratan mingw64 dari beberapa proyek saya di tempat kerja

Hanya FYI. NS

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

perubahan masih membutuhkan Mingw untuk bekerja. Anda perlu menginstal alat Mingw dan MSVC untuk menggunakan perubahan

Alex

@cchamplin , mengapa

@alexbrainman saya salah bicara. Saat ini kita harus menggunakan MSYS2 (termasuk mingw64) karena proses build non-MSVC memerlukan autotools. Menjatuhkan itu akan fantastis. Tetapi juga seperti yang dikatakan @cglong , saya tidak yakin mengapa ini juga membutuhkan mingw64.

@ericlagergren @cglong CGO perlu mengumpulkan dan memiliki informasi jenis yang tersedia tentang kode C yang sedang dikompilasi. GCC memiliki flag yang akan menampilkan tipe data dalam format yang mudah diurai. MSVC sejauh yang saya tahu tidak memiliki fungsi untuk memberikan informasi yang sama. Membangun perkakas saat berjalan tidak hanya membutuhkan kode untuk lex/parsing kode C dan C++ tetapi juga untuk memahami dan mengevaluasi arahan pra-prosesor. Ini akan menjadi usaha yang cukup besar untuk membangun hal seperti itu di Go. Mungkin ada perpustakaan yang sudah tersedia di suatu tempat meskipun kita bisa mencari cara untuk mengadopsi?

@cchamplin mengerti, itulah yang saya pikirkan. Saya tahu perpustakaan pihak ketiga seperti libclang dan cznic/cc. Namun sayangnya libclang berukuran raksasa dan cznic/cc belum diuji pada Windows atau macOS. Apakah PDB tidak memberikan informasi yang cukup?

CGO perlu mengumpulkan dan memiliki informasi jenis yang tersedia tentang kode C yang sedang dikompilasi. GCC memiliki flag yang akan menampilkan tipe data dalam format yang mudah diurai. MSVC sejauh yang saya tahu tidak memiliki fungsi untuk memberikan informasi yang sama.

Mungkin @manbearian mungkin bisa memberikan beberapa petunjuk di sini?

Saya tidak akan mengatakan bahwa GCC memancarkan data tipe keluaran dalam format khusus. Itu memancarkan data debug DWARF yang ditujukan untuk debugger, dan cgo membaca data itu menggunakan paket debug/dwarf. MSVC mungkin juga memiliki format debug. Jika format itu didokumentasikan di mana saja, kita bisa membacanya menggunakan cgo seperti yang kita lakukan pada data DWARF.

@ianlancetaylor MSVC dapat memancarkan file PDB. Lihat https://github.com/Microsoft/microsoft-pdb

FWIW, membaca output debug MSVC adalah apa yang saya bicarakan ketika saya menyebutkan alat cgo di https://github.com/golang/go/issues/20982#issuecomment -648462003

Saya tidak akan mengatakan bahwa GCC memancarkan data tipe keluaran dalam format khusus. Itu memancarkan data debug DWARF yang ditujukan untuk debugger, dan cgo membaca data itu menggunakan paket debug/dwarf. MSVC mungkin juga memiliki format debug. Jika format itu didokumentasikan di mana saja, kita bisa membacanya menggunakan cgo seperti yang kita lakukan pada data DWARF.

@ericlagergren @ianlancetaylor
Jadi kami membutuhkan data DWARF, yang merupakan bagian besar darinya. Namun, kami secara teoritis bisa mendapatkan informasi yang sama dari data PDB.

Apa yang saya maksudkan secara khusus, bukan hanya data DWARF yang dihasilkan GCC tetapi output dari gcc -E -dM yang menampilkan semua #define setelah prapemrosesan dilakukan. Ada kemungkinan bahwa PDB sendiri dapat memberikan informasi yang sama ... yang saya skeptis adalah apakah kami dapat memaksa MSVC untuk membuang informasi debug/informasi jenis dalam kapasitas apa pun tanpa perlu benar-benar dikompilasi Kode. Saat ini CGO melakukan hal itu dengan GCC .

Dari memori, /EP /d1PP harus memancarkan sesuatu yang mirip dengan -E -dM.

Dari memori, /EP /d1PP harus memancarkan sesuatu yang mirip dengan -E -dM.

Jika demikian, itu bagus, saya menganggap /d1PP adalah bendera yang tidak berdokumen? Aku belum pernah melihatnya sebelumnya. Itu hanya akan membuat informasi jenis yang setara keluar sebelumnya.

@cchamplin ya, itu tidak berdokumen. Banyak dari flag /dXXX, rupanya. Menggunakan flag yang tidak berdokumen sangat disayangkan, tetapi (IMO) tampaknya tidak terlalu buruk di Windows, setidaknya. Saya melihat pengembang MSVC STL membicarakannya di utas reddit, tetapi juga di seluruh Internet.

Dapatkah seseorang memberi saya ringkasan singkat tentang status dukungan MSVC saat ini? Saya tidak mengerti banyak tentang semua hal-hal-kompiler tingkat rendah ini. Hanya saja saya memiliki perpustakaan go yang ingin saya gunakan dari C#/UWP - dan itu sudah berfungsi dengan go build dan buildmode c-shared. TETAPI: aplikasi itu tidak akan pernah diterima oleh Windows Store karena DLL yang dihasilkan dari go melewatkan beberapa flag compiler/linker yang (saya berasumsi) hanya dapat diatur oleh MSVC-toolchain.

Jadi: bagaimana saya bisa menguji ini di sini? Setiap saran dihargai! Terima kasih!

aplikasi itu tidak akan pernah diterima oleh Windows Store karena DLL yang dihasilkan dari go melewatkan beberapa flag compiler/linker yang (saya berasumsi) hanya dapat diatur oleh MSVC-toolchain.

@TopperDEL apakah Windows Store memberi tahu Anda flag kompiler mana yang hilang? Jika mingw-64 mendukungnya, Anda selalu dapat menggunakan -extldflags dengan flag yang tepat saat membuat dll.

@qmuntal Ya, mereka melakukannya:
"Terapkan opsi tautan yang diperlukan - SAFESEH, DYNAMICBASE, NXCOMPAT, dan APPCONTAINER - saat Anda menautkan aplikasi."

Saya sudah mencoba
go build -ldflags="-s -w '-extldflags=-Wl,--dynamicbase,--high-entropy-va'" -o storj_uplink.dll -buildmode c-shared

Tapi itu tidak mengubah apa pun terkait pengiriman toko. Dan dari pemahaman saya setidaknya SAFESEH adalah hal khusus MSVC, bukan?

"Terapkan opsi tautan yang diperlukan - SAFESEH, DYNAMICBASE, NXCOMPAT, dan APPCONTAINER - saat Anda menautkan aplikasi."

Saya tidak tahu cara mudah untuk mengaktifkan flag SAFESEH atau APPCONTAINER di Mingw-w64, mungkin proyek ini https://github.com/status-im/mingw-windows10-uwp dapat memberi Anda beberapa panduan.

Di sisi lain DYNAMICBASE dan NXCOMPAT akan diaktifkan secara default di go 1.16 (lihat #41421) tetapi sudah dapat digunakan dengan -extldflags seperti yang disebutkan, sebenarnya saya melakukannya untuk beberapa proyek.

@qmuntal Terima kasih! Jadi setidaknya extldflags saya di atas seharusnya benar?
Saya akan melihat mingw untuk windows 10-uwp.