Go: cmd/link: msvc ऑब्जेक्ट फ़ाइलों का समर्थन करें

/सीसी @एलेक्सब्रेनमैन

@xoviat आपको क्या समस्या हो रही है? मुझे इसे यहां पुन: पेश करने में सक्षम होना चाहिए। तो, कृपया, इसे पुन: पेश करने के लिए मुझे सभी चरणों का पालन करने की आवश्यकता होगी।

शुक्रिया

एलेक्स

पुनश्च: मेरे पास जुलाई के अंत तक कंप्यूटर नहीं होगा। मैं तब इस पर एक नजर डालूंगा।

आपको क्या समस्या है?

मैंने अभी तक इसकी कोशिश नहीं की है, लेकिन मैं विशेष रूप से msvc ऑब्जेक्ट फ़ाइलों में c फ़ंक्शन को गो लिंकर के साथ .syso के रूप में जोड़कर कॉल करना चाहता हूं। मैंने जो कुछ भी पढ़ा है वह इंगित करता है कि यह संभव नहीं है लेकिन मैं होने वाली विशिष्ट त्रुटि को पुन: उत्पन्न करने के लिए एक प्रक्रिया तैयार करूंगा।

विशेष रूप से msvc ऑब्जेक्ट फ़ाइलों में c फ़ंक्शन को गो लिंकर के साथ .syso के रूप में जोड़कर कॉल करें

क्या आपने इन्हें डीएलएल में बनाने की कोशिश की है, और उन्हें डीएलएल के अंदर से इस्तेमाल किया है?

मैं होने वाली विशिष्ट त्रुटि को पुन: उत्पन्न करने के लिए एक प्रक्रिया तैयार करूंगा।

करने की कृपा करे। धन्यवाद।

एलेक्स

क्या आपने इन्हें डीएलएल में बनाने की कोशिश की है, और उन्हें डीएलएल के अंदर से इस्तेमाल किया है?

वह वास्तव में मेरी मूल योजना थी। मैं स्विग का उपयोग कर रहा हूं इसलिए जेनरेट किए गए सी कोड को अलग से संकलित करना और फिर डीएलएल निर्यात के रूप में कार्यों को फिर से लिखना इतना सुविधाजनक नहीं है। यह मुश्किल नहीं है, लेकिन यह कष्टप्रद है जब जीसीसी के साथ कार्यप्रवाह सिर्फ go generate; go build ।

ठीक है, मेरे पास एक प्रक्रिया है। इन फाइलों से शुरू करें:

हैलो.गो:

package main

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

func main() {
    C.hello()
}

नमस्ते सी:

#include <stdio.h>

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

फिर इन आदेशों को चलाएँ (पथ पर msvc के साथ):

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

नतीजा:
Warning: corrupt .drectve at end of def file

उत्पादित फ़ाइल चलाते समय:

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

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

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

मेरे पास मेरे पीसी पर सीएल कमांड स्थापित नहीं है। मैं एमएसवीसी कैसे स्थापित करूं?

धन्यवाद।

एलेक्स

आपको यहां "बिल्ड टूल्स 2017" की आवश्यकता है । माइक्रोसॉफ्ट वास्तव में अब किसी को भी विजुअल स्टूडियो का मुफ्त में उपयोग करने की अनुमति देता है जब तक कि यह व्यावसायिक विकास के लिए नहीं है। यदि यह बहुत अधिक परेशानी है, तो मैं आपको केवल ऑब्जेक्ट फ़ाइल दे सकता हूँ यदि आप चाहें।

अगर केवल सी ++ कोई चीज नहीं होती, तो मुझे इसके बारे में चिंता करने की ज़रूरत नहीं होती। लेकिन ऐसा है, तो दर्द जारी है...

आपको यहां "बिल्ड टूल्स 2017" की आवश्यकता है।

समझ गया। धन्यवाद।

यदि यह बहुत अधिक परेशानी है, तो मैं आपको केवल ऑब्जेक्ट फ़ाइल दे सकता हूँ यदि आप चाहें।

हाँ, कृपया, hello.obj कहीं पोस्ट करें।

इसके बारे में कुछ और सोच रहे हैं। आप वास्तव में एमएसवीसी कंपाइलर के साथ संकलित ऑब्जेक्ट फ़ाइल को लिंक करने के लिए जीसीसी का उपयोग कर रहे हैं। क्या आप कोशिश कर सकते हैं और अपना अभ्यास कर सकते हैं, लेकिन "गो बिल्ड" चरण को जीसीसी के साथ hello.obj को सी प्रोग्राम से जोड़ने के साथ बदल सकते हैं? शायद यह पहले किया गया है। मुझे संदेह है, अगर हम जानते हैं कि यह कैसे करना है, तो हम गो के साथ ऐसा करने में सक्षम हो सकते हैं।

एलेक्स

AFAIK lld https://github.com/llvm-mirror/lld msvc ऑब्जेक्ट फ़ाइलों का समर्थन करता है।

वस्तु फ़ाइल यहाँ है: https://github.com/xviat/msvcgo/blob/master/hello.syso

lld https://github.com/llvm-mirror/lld msvc ऑब्जेक्ट फ़ाइलों का समर्थन करता है

गो विंडोज़ पर जीसीसी लिंकर (एलएलडी नहीं) का उपयोग करता है।

वस्तु फ़ाइल यहाँ है: https://github.com/xviat/msvcgo/blob/master/hello.syso

अगस्त में घर आने पर मैं इसे आजमाउंगा। शुक्रिया।

एलेक्स

गो विंडोज़ पर जीसीसी लिंकर (एलएलडी नहीं) का उपयोग करता है।

मैं जानता हूँ। लेकिन lld msvc ऑब्जेक्ट फॉर्मेट का सबसे अच्छा ओपन सोर्स डॉक्यूमेंटेशन है।

मुझे वास्तव में एलडी से एक ही त्रुटि मिलती है इसलिए त्रुटि निश्चित रूप से एलडी से आ रही है।

मुझे वास्तव में एलडी से एक ही त्रुटि मिलती है इसलिए त्रुटि निश्चित रूप से एलडी से आ रही है।

हां। हमें एमएसवीसी के साथ भाग संकलित करके और जीसीसी से जोड़कर सी प्रोग्राम बनाने का तरीका जानने की जरूरत है।

एलेक्स

मेरी अज्ञानता को क्षमा करें, लेकिन वास्तव में जीसीसी लिंकिंग क्या है? क्या यह गो लिंकर के आउटपुट को जोड़ रहा है?

योगिनी में कनवर्ट करने के लिए ऑब्जेक्ट फ़ाइलों पर objconv चलाना:

objconv -felf hello.obj hello.syso

अब हमारे पास ये त्रुटियां हैं:

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

संभवतः stdio सीमा से बाहर है?

मेरी अज्ञानता को क्षमा करें, लेकिन वास्तव में जीसीसी लिंकिंग क्या है? क्या यह गो लिंकर के आउटपुट को जोड़ रहा है?

आप अपना गो प्रोग्राम बनाने के लिए 2 प्रोग्राम का उपयोग करते हैं:

• कंपाइलर आपकी .go फ़ाइलों (उस समय 1 पैकेज) को %GOPATH%/pkg निर्देशिका के अंतर्गत संग्रहीत ऑब्जेक्ट फ़ाइल में कनवर्ट करता है;
• लिंकर जो %GOPATH%/pkg के अंतर्गत ऑब्जेक्ट फ़ाइलों से अंतिम .exe फ़ाइल बनाता है।

कभी-कभी (जब आपका कोई पैकेज सीजीओ का उपयोग करता है), गो लिंकर बाहरी लिंकर को सी में लागू किए गए सभी बिट्स को खोजने के लिए कॉल करता है। कल्पना कीजिए कि आप अपने सी कोड से प्रिंटफ को कॉल करते हैं। सी प्रिंटफ संकलित कोड को गो निष्पादन योग्य का हिस्सा होना चाहिए, लेकिन गो लिंकर को यह नहीं पता कि इसे कहां प्राप्त करना है। तो गो लिंकर उस कोड को शामिल करने के लिए बाहरी लिंकर को कॉल करता है।

करेंट गो सी कोड को संकलित और लिंक करने के लिए जीसीसी कंपाइलर/लिंकर का उपयोग करता है (हम मिंगव जीसीसी का उपयोग करते हैं)। यदि आप अपने सी कोड को विभिन्न कंपाइलर (माइक्रोसॉफ्ट द्वारा) के साथ संकलित करने जा रहे हैं, तो आपको कंपाइलर द्वारा बनाए गए सभी बाहरी सी कोड को खोजने के लिए संवाददाता लिंकर (माइक्रोसॉफ्ट द्वारा) का उपयोग करना होगा।

तो, मुझे लगता है, मैं जीसीसी लिंकर का उपयोग करने का सुझाव देने में गलत था। सामान्य परिदृश्य के लिए, आपको माइक्रोसॉफ्ट कंपाइलर और लिंकर दोनों का उपयोग करना होगा। हमें यह पता लगाना होगा कि Microsoft लिंकर को इनपुट के रूप में क्या चाहिए और उसका मिलान करें।

यदि आपके सी कोड में कोई बाहरी कोड नहीं है, तो आप एमसी लिंकर के बिना दूर हो सकते हैं। कृपया कुछ सचमुच सरल सी प्रोग्राम आज़माएं (जैसे वह जो 2 पूर्णांक या कुछ जोड़ता है)। जैसा कि आपने ऊपर वर्णित किया है, यह ठीक काम कर सकता है।

एलेक्स

संभवतः stdio सीमा से बाहर है?

मुझे संदेह है कि आपको उस कोड को खोजने के लिए माइक्रोसॉफ्ट लिंकर को कॉल करने की आवश्यकता है।

एलेक्स

मुझे यकीन नहीं है लेकिन

objconv -felf hello.obj hello.syso

हो सकता है, आपको योगिनी के बजाय ताबूत या ओएमएफ करने की कोशिश करनी चाहिए?

हो सकता है, आपको योगिनी के बजाय ताबूत या ओएमएफ करने की कोशिश करनी चाहिए?

@xoviat हाँ, आपको .obj फ़ाइलों को योगिनी में नहीं बदलना चाहिए, gcc का Windows संस्करण किसी अन्य Windows कंपाइलर की तरह ही pe/coff फ़ाइलें उत्पन्न करता है।

एलेक्स

गो लिंकर सी में लागू सभी बिट्स को खोजने के लिए बाहरी लिंकर को कॉल करता है।

विशिष्ट कमांड का क्या उपयोग किया जाता है? अगर मुझे मिंगव कमांड पता है, तो शायद मैं एक फाइल तुलना पथ पर आगे बढ़ सकता हूं ताकि एमएसवीसी को मिंगव डालने से मेल खाने का प्रयास किया जा सके।

आप go build -ldflags=-v चलाकर सटीक टिप्पणी देख सकते हैं।

ठीक है, तो मैं क्या बता सकता हूँ:

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

ऐसा प्रतीत होता है कि गो इन फ़ाइलों के साथ एक अस्थायी निर्देशिका बनाता है। क्या अस्थायी निर्देशिका को संरक्षित करने का कोई तरीका है ताकि मैं इसकी सामग्री का निरीक्षण कर सकूं?

कोशिश करें go build -work

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

इस निर्देशिका में ऑब्जेक्ट फ़ाइलें शेष हैं।

-work विकल्प वास्तव में लिंकर द्वारा बनाई गई अस्थायी फ़ाइलों को संरक्षित नहीं करेगा। फिलहाल आपको निर्देशिका को न हटाने के लिए लिंकर स्रोतों को संपादित करना होगा। हमें शायद उसके लिए एक विकल्प जोड़ना चाहिए, एक तरह से या कोई अन्य।

फिलहाल आपको निर्देशिका को न हटाने के लिए लिंकर स्रोतों को संपादित करना होगा।

यदि आपको कोई आपत्ति नहीं है, तो मैं इसे HEAD में लागू होने तक प्रतीक्षा करने जा रहा हूँ ताकि मुझे दोहराए जाने वाले कार्य न करने पड़ें।

क्या अस्थायी निर्देशिका को संरक्षित करने का कोई तरीका है ताकि मैं इसकी सामग्री का निरीक्षण कर सकूं?

cmd/link प्रोग्राम में उसके लिए -tmpdir झंडा है। आप इसे इस तरह इस्तेमाल कर सकते हैं:

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

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

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

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

import "fmt"
import "C"

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

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

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

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

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

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

एलेक्स

यह सिर्फ मेरे अपने संदर्भ के लिए है, लेकिन इसे msvc पर पोर्ट करने की आवश्यकता है:

_cgo_sys_thread_start(ThreadStart *ts)
{
    uintptr_t thandle;

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

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

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

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

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

    crosscall_amd64(ts.fn);
}

मैं इस कार्य को पूरा करने में लगने वाले समय को कम नहीं आंकूंगा क्योंकि मैं असेंबली से बिल्कुल भी परिचित नहीं हूं।

• [x] समझें कि विधानसभा क्या करती है
• [x] पोर्ट टू MSVC असेंबली
• [x] _beginthread बनाम CreateThread को समझें
• [x] CreateThread पर स्विच करें

इसके अलावा, अपरिभाषित प्रतीक:

• [x] टाइमबीगिनपीरियड -> winmm.lib
• [x] समयशुरुआतअवधि
• [x] WSAGetOverlappedResult -> Ws2_32.lib
• [x] WSAGetOverlappedResult
• [एक्स] _cgo_18b6f6fc815b_Cfunc_hello
• [x] x_cgo_init -> msvc_windows_amd64.c
• [x] x_cgo_thread_start -> msvc_windows_amd64.c
• [x] x_cgo_sys_thread_create -> msvc_windows_amd64.c
• [x] x_cgo_notify_runtime_init_done -> gcc_libinit_windows.c
• [x] x_cgo_set_context_function -> gcc_libinit_windows.c

ठीक है, इसलिए अपेक्षा से अधिक तेज़ी से यहाँ आगे बढ़ रहा हूँ!

सभी: asm_amd64.s गो के असेंबलर (विषम असेंबली के साथ) या जीसीसी के असेंबलर द्वारा इकट्ठा किया गया है?

ऐसा लगता है कि जीसीसी इसे इकट्ठा नहीं करेगा, जिसका मतलब है कि यह शायद असेंबली है। और फिर सवाल बन जाता है: इसे गो असेंबलर के साथ किसी ऑब्जेक्ट में कैसे इकट्ठा किया जाए।

आशय यह है कि रनटाइम/cgo/asm_amd64.s एक गो ऑब्जेक्ट में असेंबल हो जाता है, फिर cmd/लिंक इसे अन्य सभी गो ऑब्जेक्ट्स के साथ एक सिंगल सिस्टम ऑब्जेक्ट में जोड़ता है, और फिर सिस्टम लिंकर उस सिंगल सिस्टम ऑब्जेक्ट को और सभी को लिंक करता है। अंतिम कार्यक्रम में cgo निर्भरता।

क्या परीक्षण उद्देश्यों के लिए उस वस्तु को अभी इकट्ठा करने का कोई तरीका है? जाने के अलावा gcc -c asm_amd64.s ?

आशय यह है कि रनटाइम/cgo/asm_amd64.s एक गो ऑब्जेक्ट में असेंबल हो जाता है, फिर cmd/लिंक इसे अन्य सभी गो ऑब्जेक्ट्स के साथ एक सिंगल सिस्टम ऑब्जेक्ट में जोड़ता है, और फिर सिस्टम लिंकर उस सिंगल सिस्टम ऑब्जेक्ट को और सभी को लिंक करता है। अंतिम कार्यक्रम में cgo निर्भरता।

अब तक मुझे ये वस्तुएं मिली हैं:

• go.o : जाहिर तौर पर गो टूलचैन से
• _cgo_.o : जीसीसी द्वारा उत्पन्न, अनुपयोगी
• 000000.o : जीसीसी द्वारा उत्पन्न, अनुपयोगी
• 000001.o : अद्यतन: वास्तव में गो लिंकर द्वारा उत्पन्न, लेकिन इसमें जीसीसी प्रतीक शामिल हैं। अनुपयोगी।

go.o सबसे बड़ी वस्तु है।

@ianlancetaylor

मुझे नहीं लगता कि आपने जो कहा वह सही है। crosscall_amd64 000001.o में स्थित है, लेकिन उस फ़ाइल में "ऑल गो ​​कोड" नहीं है:

000001.o:     file format pe-x86-64

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

यह फ़ाइल स्पष्ट रूप से जीसीसी द्वारा उत्पन्न की गई है, जो प्रक्रिया में बहुत देर हो चुकी है।

क्या परीक्षण उद्देश्यों के लिए उस वस्तु को अभी इकट्ठा करने का कोई तरीका है? gcc -c asm_amd64.s की तरह गो के अलावा?

asm_amd64.s रनटाइम पैकेज का हिस्सा है। आप देख सकते हैं कि कैसे "गो बिल्ड" कमांड asm_amd64.s फ़ाइल का उपयोग करता है, जैसे:

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

एलेक्स

धन्यवाद।

प्रतीक crosscall_amd64 फ़ाइल रनटाइम/cgo/gcc_amd64.s में परिभाषित किया गया है। वह फ़ाइल GCC द्वारा संकलित की गई है (जैसा कि सभी रनटाइम/cgo/gcc_* फ़ाइलें हैं)। इसलिए इसे एकल go.o फ़ाइल में संयोजित नहीं किया जाता है जिसमें सभी गो कोड होते हैं। जिस फ़ाइल के बारे में हम पहले बात कर रहे थे, वह रनटाइम/cgo/asm_amd64.s, प्रतीक को परिभाषित करती है crosscall2 । आपको वह चिन्ह go.o में मिलेगा।

धन्यवाद।

ठीक है, मैंने एक निष्पादन योग्य को लिंक करने में कामयाबी हासिल की है जो प्रवेश के उल्लंघन पर दुर्घटनाग्रस्त हो जाता है
go.runtime.rt0_go+5F -> go.__acrt_stdio_initializer.

मेरे पास अभी के लिए इतना ही समय है; मैं बाद में इस पर वापस आऊंगा।

@alexbrainman यह सही है।

@alexbrainman आगे बढ़ने के लिए आपको MSVC की आवश्यकता होगी। मुझे बताएं कि क्या आपको इसमें मदद की ज़रूरत है।

आगे बढ़ने के लिए आपको MSVC की आवश्यकता होगी।

मैं इसे https://www.visualstudio.com/downloads/#build -tools-for-visual-studio-2017 इंस्टॉल कर रहा हूं

एक बार स्थापित होने के बाद मुझे क्या करना चाहिए?

एलेक्स

एक बार जब आप इसे स्थापित कर लेते हैं, तो आपको "libgo" बनाने की आवश्यकता होती है, जो कि गो लाइब्रेरी है। निम्नलिखित फाइलों को cgo फोल्डर से कॉपी करें:

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

MSVC के साथ संगत होने के लिए हमें gcc_windows_amd64.c समायोजित करने की आवश्यकता है। फ़ंक्शन को निम्नानुसार संशोधित करें:

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

    ThreadStart ts;

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

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

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

    crosscall_amd64(ts.fn);
}

"build.bat" नामक इन सभी फाइलों के साथ फ़ोल्डर में एक नई फाइल बनाएं:

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

ren gcc_amd64.o gcc_amd64.obj

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

जब आपके पास अनुरोध के अनुसार फ़ोल्डर संरचित हो तो मुझे बताएं।

वैसे, इस पर काम करने और जाने के लिए धन्यवाद। आप लोगों ने सचमुच जादुई भाषा बनाई है।

जब आपके पास अनुरोध के अनुसार फ़ोल्डर संरचित हो तो मुझे बताएं।

जैसा कि आपने यहां बताया है, मैं libgo.lib बनाने में कामयाब रहा https://github.com/golang/go/issues/20982#issuecomment -327365063
मुझे आगे क्या करना चाहिये?

एलेक्स

ठीक है, तो अब हमें निम्नलिखित फाइलों की आवश्यकता है:

• libgo.lib
• चिपचिपा पदार्थ
• hello.cgo2.o
• नमस्ते सी

hello.c निम्नलिखित है:

#include <stdio.h>

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

hello.cgo2.o और go.o , आपको निम्न फ़ाइल से शुरुआत करनी होगी:

package main

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

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

"हैलो.गो" कहा जाता है

एक पॉवरशेल स्क्रिप्ट सेट करें जो लगातार फाइलों को $ env:TMP से कॉपी करती है:

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

फिर फोल्डर में go build साथ hello.c और hello.go चलाएं। आपको आवश्यक फ़ाइलों को उस स्थान से पुनर्प्राप्त करने में सक्षम होना चाहिए जहां उन्हें कॉपी किया गया था।

एक बार जब आपके पास ऊपर निर्दिष्ट फाइलें हों, तो आप इसके साथ निर्माण कर सकते हैं:

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

अगर आपका कोई प्रश्न हैं, तो मुझे से पूछें।

cl libgo.lib go.o hello.cgo2.o hello.c Ws2_32.lib Winmm.lib -लिंक / डीबग: पूर्ण

यह go.exe निष्पादन योग्य फ़ाइल बनाता है, लेकिन यह नहीं चलता है। मुझे वहां कोई समझदार एएसएम कोड नहीं दिख रहा है। पहला निर्देश बस कहीं नहीं कूदो। यह सिर्फ एक गड़बड़ है।

हो सकता है कि आपको कुछ वास्तविक सरल से शुरू करना चाहिए। एकल एएसएम फ़ंक्शन के साथ एक एएसएम फ़ाइल (गो एएसएम फ़ाइल) लिखें जो "आईएनटी $ 3" ​​निष्पादित करता है और उसके पास कुछ भी नहीं है। और इसमें से एक निष्पादन योग्य प्रोग्राम बनाने का प्रयास करें - प्रोग्राम को आपके कार्य को बहुत शुरुआत में चलाना चाहिए।

हो सकता है कि इसे पहले गो टूल्स का उपयोग करके बनाएं (और यदि आवश्यक हो तो जीसीसी का भी उपयोग करें), और फिर कोशिश करें और एमएसवीसी का उपयोग करके ऐसा ही करें।

एलेक्स

एलेक्स, आपकी मदद के लिए धन्यवाद। मैं उस पर काम करूंगा।

मैं इन दो लेखों को अपने संदर्भ के लिए यहाँ संलग्न करने जा रहा हूँ। अन्यथा, मेरे पास कोई और अपडेट नहीं है।

मुझे वास्तव में एक काफी जटिल गो प्रोग्राम काम कर रहा है जो केवल एमएसवीसी लाइब्रेरी का उपयोग करता है। यह पता चला है कि वैनिला msvc लिंकर और llvm-lld दोनों ने .bss सेक्शन को सही ढंग से हैंडल नहीं किया।

एक बार जब मैंने लिंकर को पैच कर दिया तो प्रोग्राम चल सकता है।

दुर्भाग्य से go build टूट जाता है जब यह _cgo_.o / _all.o उत्पन्न करता है। क्या सीजीओ में इन दो फाइलों को उत्पन्न करने के पीछे तर्कों पर कुछ प्रकाश डालना संभव है?

cgo को सीधे चलाने के लिए आप go tool cgo चला सकते हैं। स्रोत यहाँ हैं: https://github.com/golang/go/tree/master/src/cmd/cgo

इसके अलावा, यदि आप इसे चलाने के लिए प्राप्त कर सकते हैं, तो यह बहुत अच्छा होगा। मैंने अभी इसके लिए समय नहीं दिया है, इसलिए कोई प्रगति नहीं हुई है। उसके लिए माफ़ करना।

मेरे पास पहले से ही प्रोग्राम हैं जो हाथ से सिलाई की एक श्रृंखला के माध्यम से सही ढंग से चल सकते हैं - मैं यहां जो करने की कोशिश कर रहा हूं वह यह देखने के लिए है कि प्रक्रिया को कम दर्दनाक बनाने के लिए वापस एकीकृत किया जा सकता है या नहीं। :-)

यदि आप हाथ से सिलाई की प्रक्रिया का दस्तावेजीकरण कर सकते हैं, तो मैं मदद करने में सक्षम हो सकता हूं।

बस देखने से, _cgo_.o इस तरह (सरलीकृत) उत्पन्न होने लगता है:

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

यहां से: https://github.com/golang/go/blob/b4c84a1b010f012668b5e3ccaf63f609cd11c5fe/src/cmd/go/internal/work/exec.go#L1975

इसके अलावा, दस्तावेज़ीकरण के लिए यहां देखें:
https://github.com/golang/go/blob/840f2c167f1d5196559d8a1e77c370960e66d34e/src/cmd/cgo/doc.go#L607

आदर्श रूप से हम एक गो प्रोग्राम लिखेंगे जो ऑब्जेक्ट फाइलों को प्री-प्रोसेस करता है ताकि वे न्यूनतम घर्षण के लिए link.exe के साथ संगत हों, लेकिन यह एक तरह का खिंचाव लक्ष्य है।

सूचक के लिए धन्यवाद -- मैं शीघ्र ही इस प्रक्रिया को लिखने जा रहा हूँ।

दुर्भाग्य से मुझे नहीं लगता कि जोड़ने के माध्यम से किया जा सकता है link.exe जब तक कि हम में अप्रारंभीकृत डेटा फेंकना जीसीसी बदल .data के बजाय खंड .bss अनुभाग - लेकिन हम कर सकते हैं .bss अनुभाग (जो मैंने किया है) को पहचानने के लिए निश्चित रूप से llvm-lld को ठीक करें।

हमें अलग-अलग _cgo_.o और _all.o से निपटने की जरूरत है। मेरे पास उन पर कुछ प्रश्न हैं:

(1) ऐसा लगता है कि _cgo_.o अंतिम निष्पादन योग्य नहीं है क्योंकि इसमें गो रनटाइम शामिल नहीं है। ऐसा लगता है कि संकलक संरचना की परिभाषा को समझने के लिए अपने डीडब्ल्यूएआरएफ प्रतीकों को देखता है। समस्या यह है कि यदि आप बाहरी रूप से कई पुस्तकालयों से लिंक करने जा रहे हैं, विशेष रूप से एमएसवीसी द्वारा उत्पन्न किए गए हैं तो निष्पादन योग्य उत्पन्न करना मुश्किल है।

क्या इस कदम से बचना संभव है?

(2) जीसीसी में -Wl,-r पास करके सभी ऑब्जेक्ट फाइलों को _all.o में सिलाई करने के लिए जीएनयू ld का उपयोग करें। यह समस्याग्रस्त है क्योंकि (1) ऐसा नहीं लगता कि अन्य लिंकर में यह सुविधा है, और (2) कमांड CGO_LDFLAGS से प्रभावित है। उदाहरण के लिए, निम्न आदेश गलत परिणाम उत्पन्न करता है:

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

यह एक बंडल ऑब्जेक्ट फ़ाइल के बजाय एक निष्पादन योग्य उत्पन्न करता है।

क्या सभी ऑब्जेक्ट फ़ाइलों को सीधे जेनरेट किए गए .a में डालकर इस चरण से बचना संभव है?

@zooba इस पैच के साथ MSFT को link.exe अपडेट करने की क्या संभावना है?

दुर्भाग्य से मुझे नहीं लगता कि लिंकिंग link.exe के माध्यम से किया जा सकता है जब तक कि हम .bss सेक्शन के बजाय .data सेक्शन में uninitialized डेटा को उत्सर्जित करने के लिए gcc को नहीं बदलते - लेकिन हम .bss सेक्शन को पहचानने के लिए llvm-lld को निश्चित रूप से ठीक कर सकते हैं। (जो मैंने किया है)।

यह सोचते हैं कि MSFT अपडेट नहीं करता तो link.exe (जो संभव है), इसके साथ वस्तु फ़ाइलों को संकलित करने के अच्छा होगा cl.exe बजाय gcc ।

ऐसा लगता है कि _cgo_.o अंतिम निष्पादन योग्य नहीं है क्योंकि इसमें गो रनटाइम शामिल नहीं है।

यह सही है, मूल रूप से ऑब्जेक्ट फाइलों के दो सेट हैं (मुझे लगता है) जो अंत में एक साथ जुड़ जाते हैं। go.o फ़ाइल (IIRC) में सभी गो कोड + रनटाइम होते हैं, और अन्य ऑब्जेक्ट में C कोड होता है। वस्तुओं के दो सेटों के बीच कूदने के लिए असेंबली रूटीन हैं।

साथ ही, हमें यूनिक्स असेंबली फाइलों को संकलित करने के लिए clang है।

हमारे उद्देश्यों के लिए, -Wl,-r lib.exe [object files] /OUT:obj चलाने जैसा ही होगा। विकल्प का अर्थ है "वृद्धिशील रूप से लिंक," जिसका अर्थ है "कुछ इनपुट फ़ाइलें लें, कुछ काम करें, फिर दूसरी ऑब्जेक्ट फ़ाइल को थूक दें।" अगर हम अभी के लिए "कुछ काम करें" भाग के बारे में चिंता नहीं करते हैं, तो हम केवल आवश्यकता को "कुछ इनपुट फ़ाइलें और/या ऑब्जेक्ट फ़ाइलें ले सकते हैं और किसी अन्य ऑब्जेक्ट फ़ाइल को थूक सकते हैं" हमारे मामले को छोड़कर ऑब्जेक्ट फ़ाइल होगी एक पुस्तकालय।

आप -fno-zero-initialized-in-bss विकल्प का उपयोग करके जीसीसी को .bss अनुभाग के बजाय .data अनुभाग में चर डालने से बचने के लिए कह सकते हैं।

ध्यान दें कि टिप पर हम cgo कोड बनाते समय -Wl,-r उपयोग नहीं करते हैं।

MSVC ऑब्जेक्ट फ़ाइलों को .syso फ़ाइलों के रूप में उपयोग करने के लिए cmd/link के लिए यह आवश्यक नहीं होना चाहिए। वे फाइलें किसी भी तरह बाहरी लिंकर को पास कर दी जाती हैं। तो मुझे लगता है कि यहां एमएसवीसी लिंकर को बाहरी लिंकर के रूप में आमंत्रित करने की आवश्यकता है, जिसे आपको -extld विकल्प का उपयोग करके करने में सक्षम होना चाहिए। यदि आप पहले से ही ऐसा कर रहे हैं, तो मुझे क्षमा करें; उस मामले में, क्या विफल हो रहा है?

यदि आप पहले से ही ऐसा कर रहे हैं, तो मुझे क्षमा करें; उस मामले में, क्या विफल हो रहा है?

आईआईआरसी, link.exe जीसीसी उत्पन्न वस्तुओं पर बारफ्स।

सच है, आपको CC पर्यावरण चर को उचित रूप से सेट करके, एमएसवीसी सी के कंपाइलर का भी उपयोग करना होगा। मुझे नहीं लगता कि यह जीसीसी ऑब्जेक्ट्स और एमएसवीसी ऑब्जेक्ट्स को एक ही लिंक में संयोजित करने के लिए काम करने जा रहा है।

लेकिन फिर आप उस समस्या में भाग लेते हैं जहां रनटाइम सी पुस्तकालय पूर्व-संकलित होते हैं। और यदि आप उन्हें पुन: संकलित करने का प्रयास करते हैं, तो आप इस समस्या में भाग लेते हैं कि cl यूनिक्स असेंबली को संकलित नहीं कर सकता है। और इसलिए आप रनटाइम पुस्तकालयों के कुछ हिस्सों को पोर्ट करते हैं और उन्हें जोड़ने का प्रयास करते हैं, जो मैंने किया और असफल रहा।

कहीं न कहीं, cl कोड के एक महत्वपूर्ण भाग को गलत तरीके से संकलित करता है। फिक्सिंग के लिए मेरा विचार एमएसवीसी कोड को एक फ्लैट सी एपीआई के साथ एक डीएलएल में कारक बनाना होगा, और तब तक केवल रनटाइम पुस्तकालयों को तब तक संकलित करना होगा जब तक कि यह काम करना बंद न कर दे।

समस्या को ठीक करने के लिए @haohui का विचार अलग था। समस्या की जड़ को ठीक करने के बजाय, उन्होंने लिंकर को पैच करके इसके आसपास काम किया। जाहिर है कि उसे मुझसे ज्यादा सफलता मिली, लेकिन शायद ऐसा इसलिए है क्योंकि उसका दृष्टिकोण, मेरी तुलना में काम करने की अधिक संभावना है।

इस बिंदु पर मैं जो अनुशंसा करता हूं (आईएमएचओ) cl साथ रनटाइम लाइब्रेरी को अधिक से अधिक संकलित करना है जब तक कि यह काम करना बंद न कर दे या जब तक आपके पास कोई जीसीसी कोड न हो। तब आप ठीक से जानते हैं कि समस्या कहाँ है।

और लिंकर पैच के साथ, कोई डीएलएल की आवश्यकता नहीं है।

llvm-lld का पैच https://bugs.llvm.org/show_bug.cgi?id=35283 पर उपलब्ध है

मैं एक उदाहरण प्रदान करने के लिए कुछ समय बिताऊंगा।

+1 @haohui इसे आगे बढ़ाने के लिए बहुत बहुत धन्यवाद!

@haohui llvm के किस संस्करण पर आपका पैच लागू होता है? अपने पैच का उपयोग कैसे करें और एमएसवीसी फाइलों के खिलाफ कैसे लिंक करें, इस पर कोई निर्देश?

_cgo_.o और _all.o फ़ाइलों के संबंध में, मेरे पास एक ही समस्या थी, इसलिए शायद इस समस्या का समाधान अन्य समस्या के लिए भी ठीक हो सकता है: https://github.com/golang/go /मुद्दे/17014

इस पर सभी काम के लिए धन्यवाद। ऐसा लगता है कि अच्छी प्रगति हो रही है। नई सुविधाएं Go 1.11 तक रुकी हुई हैं, इसलिए मील का पत्थर बदल रहा है।

तो मैं कल रात इसमें कूद गया। एमएसवीसी के माध्यम से सब कुछ बनाना संभव है एमएसवीसी के माध्यम से सब कुछ

तो एमएसवीसी जैसी साधारण समस्याओं से परे msvc: लिंक .bss सेगमेंट को उड़ा देता है (मुझे लगता है कि यह सिर्फ इस डेटा को .data में फेंक सकता है) जो कि एक समस्या है क्योंकि ऐसा लगता है कि गो असेंबलर SB (छद्म reg) परिणाम को संबोधित करने में गलत है यदि .bss स्थानांतरित हो जाता है .

मेरा प्रारंभिक विचार यह होगा कि असेंबलर को उन चीजों को रखने की कोशिश करनी चाहिए जो क्रमशः .bss और .noptrbss में .data और .noptrdata में जाती हैं। मुझे यकीन भी नहीं है कि यह संभव है; इसके साथ मेरा झुकाव सफल नहीं रहा है और संबोधन पूरी तरह से बंद हो गया है।

मुझे नहीं लगता कि अभी के लिए link.exe का उपयोग करना संभव है। मुझे लगता है कि हमें lld-link.exe से शुरुआत करनी चाहिए

अगर इसके पीछे विचार यह है कि हम .bss डेटा के आसपास नहीं जाने के लिए lld-link को पैच कर सकते हैं, तो मैं अपील को समझता हूं। वास्तविक रूप से यदि लक्ष्य वास्तविक msvc उपकरण श्रृंखला का समर्थन करना है तो डेटा को .bss/.noptrbss में रखने के लिए आंतरिक संकलन पर जाएं, जिसे संबोधित करने की आवश्यकता होगी।

क्या हम lld-link.exe को गो के साथ पुनर्वितरित नहीं कर सकते? ऐसा लगता है कि जब तक एलटीसीजी सक्षम नहीं है, तब तक एमएसवीसी ऑब्जेक्ट फाइलों का समर्थन करने के लिए सबसे कम जोखिम वाला पथ है। मैं समझता हूं कि यह आदर्श नहीं है, लेकिन हमारे सामने संसाधन की कमी है।

यह वृद्धिशील प्रगति की भी अनुमति देता है जो सबसे अच्छी रणनीति है।

ठीक है, कुछ अच्छी अनुवर्ती खबरें, मैं दोपहर के भोजन पर इस पर काम करने में एक घंटा बिताने में सक्षम था।

फिलहाल मेरे पास काम करने वाले मुद्दे में पहले से उदाहरण है:

- 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

बाइनरी पूरी तरह से एमएसवीसी और गो टूलचेन (कोई जीसीसी या अन्य एलएलवीएम स्थापित नहीं) के साथ बनाया गया है।

जाँच - परिणाम:

• गो टूल्स/link.exe आउटपुट .bss डेटा को आंतरिक असेंबली के लिए .data में रखना अंततः काफी तुच्छ था
• msvc . के लिए कई ASM टुकड़ों को स्थगित करना पड़ा
• कुछ GCC #defs को शर्मसार किया गया
• कुछ cgo जनरेट की गई .c फ़ाइलों में कई छोटे समायोजन करने पड़े
• सम्मिश्र संख्याओं को चमकाने की आवश्यकता होगी, फिलहाल वे असमर्थित हैं
• यह संभावना है कि निर्माण के लिए सीधे अतिरिक्त झंडों को जोड़ने की आवश्यकता होगी या msvc समर्थन के लिए लिंक, ldflags आदि पर्याप्त नहीं होंगे

अगला कदम:
यदि मेरे पास इस सप्ताह के अंत में समय है तो मैं अपने परिवर्तनों को एक कांटा में लाने पर काम करूंगा, लेकिन निर्माण/लिंक में झंडे के पीछे की कार्यक्षमता। बाद में मैं समीक्षा के लिए एक पीआर प्राप्त करूंगा ताकि हम प्रकारों पर काम कर सकें। मुझे 100% विश्वास नहीं है कि .bss डेटा को इधर-उधर ले जाने से कहीं न कहीं किसी तरह का प्रभाव पड़ेगा।

एकमात्र ड्रा बैक जिसके बारे में मैं सोच सकता हूं कि यह बाइनरी के आकार को उड़ा देगा, लेकिन यह ठीक होना चाहिए।

ठीक!

क्षमा करें, इसे एक साथ रखने में मुझे कुछ अतिरिक्त दिन लगे। तो एक पैच पर पहला ड्राफ्ट यहां पाया जा सकता है: https://github.com/ccamplin/go/commit/69a5cfc1dd0106fd8a2928a83e4c7001e81e89b8 :: https://github.com/ccamplin/go/tree/msvc_toolchain_support

यह अभी भी मोटा है लेकिन मेरे पास एमएसवीसी के साथ सफलतापूर्वक कोड बना रहा है।

अगर लोग अभी इसका परीक्षण शुरू कर सकते हैं और मुझे बग की रिपोर्ट कर सकते हैं तो यह बहुत बढ़िया होगा ताकि मैं इसे अपस्ट्रीम के लिए बेहतर स्थान पर प्राप्त कर सकूं। इसके अलावा अगर कोई लिखित परीक्षा में भाग लेना चाहता है तो यह आश्चर्यजनक होगा!

उपयोग:

go build -compiler msvc [path]

• सम्मिश्र संख्याएँ वर्तमान में तब तक असमर्थित हैं जब तक मुझे यह पता नहीं चल जाता कि क्या हम उन्हें काम में ला सकते हैं।
• मुझे नहीं पता कि यदि आप msvc कंपाइलर के साथ गो रनटाइम बनाने का प्रयास करते हैं तो क्या होता है।
• जीसीसी की अभी भी आवश्यकता है और इसका उपयोग जीसीओ द्वारा परिभाषित करने और डेटा टाइप करने के लिए किया जाता है जब इसे संकलित कुछ भी बनाने के लिए उपयोग नहीं किया जाता है )। मुझे नहीं पता कि क्या हम इसके आसपास हो सकते हैं, एमएसवीसी के पास ऐसा कुछ भी नहीं है जो एक ही बौना और कोड के # परिभाषित डंप कर सकता है ... अगर किसी के पास इस पर विचार है तो यह बहुत अच्छा होगा

जुड़ा हुआ पैच बूटस्ट्रैपिंग समस्या पैदा करता है।

@alexbrainman यह कैसे और कहाँ निर्धारित किया जाता है कि toolchain1 बूस्टरैपिंग चरण के दौरान कौन सी फ़ाइलों को pkg/boostrap/src/bootstrap में कॉपी किया जाएगा?

cc @alexbrainman

जुड़ा हुआ पैच बूटस्ट्रैपिंग समस्या पैदा करता है।

मुझे नहीं पता कि बूटस्ट्रैपिंग आजकल कैसे काम करती है। लेकिन मुझे यकीन है कि अन्य ( @rsc और @ianlancetaylor) मदद कर सकते हैं।

मुझे आश्चर्य है कि अगर बूटस्ट्रैपिंग काम नहीं करती है तो @ccamplin कैसे

एलेक्स

@xoviat मुझे नहीं पता कि समस्या क्या है, लेकिन बूटस्ट्रैप निर्देशिकाओं की सूची cmd/dist/buildtool.go में है।

अरे @alexbrainman , @ianlancetaylor , @xoviat इसके बारे में खेद है कि मुझे लगता है कि मुझे और अच्छी तरह से सत्यापित करना चाहिए था।

मैंने यहां शाखा को अद्यतन किया है https://github.com/ccamplin/go/commit/69a5cfc1dd0106fd8a2928a83e4c7001e81e89b8 बूटस्ट्रैपिंग समस्या के समाधान के साथ, मुझे लगता है कि इसे अब सही ढंग से बूटस्ट्रैप करना चाहिए।

मुझे कुछ/src/आंतरिक/syscall निर्देशिकाओं को cmd/आंतरिक/msvc में कॉपी करना पड़ा। क्या यह बहुत बड़ी समस्या होगी? मुझे यकीन नहीं है कि स्रोत/आंतरिक का उपयोग किए बिना रजिस्ट्री तक पहुंच कैसे प्राप्त करें।

मुझे कुछ/src/आंतरिक/syscall निर्देशिकाओं को cmd/आंतरिक/msvc में कॉपी करना पड़ा। क्या यह बहुत बड़ी समस्या होगी? मुझे यकीन नहीं है कि स्रोत/आंतरिक का उपयोग किए बिना रजिस्ट्री तक पहुंच कैसे प्राप्त करें।

मुझे नहीं पता कि यह आजकल कैसे किया जाता है, लेकिन मुझे संदेह है कि cmd/dist ऐसा कर सकता है बिना आप मैन्युअल रूप से स्रोत फ़ाइलों की प्रतिलिपि बना सकते हैं। मुझे यकीन है कि जब आप कोड जमा करने के लिए तैयार होंगे तो Russ या Ian आपकी मदद करेंगे।

मुझे लगता है कि यह @bradfitz और @ianlancetaylor के लिए यह तय करने का समय है कि यहां कैसे आगे बढ़ना है। क्या हम चाहते हैं कि गो माइक्रोसॉफ्ट बिल्ड टूल्स के साथ-साथ जीसीसी का भी समर्थन करे? हमें अपने बिल्डरों पर कॉरेस्पोंडेंट माइक्रोसॉफ्ट टूल्स इंस्टॉल करना होगा (सीएल स्वीकार करना शुरू करने से पहले हमें ऐसा करना होगा)। हमें, शायद, नए पर्यावरण चर पेश करने होंगे। नया दस्तावेज।

यदि उत्तर हाँ है, तो @ccamplin को https://golang.org/doc/contribute.html के अनुसार अपने कोड परिवर्तन सबमिट करने होंगे क्या आप ऐसा करने के इच्छुक होंगे? परिवर्तन काफी बड़ा है, इसलिए इसे छोटे CL में विभाजित करने की आवश्यकता है, ताकि उनकी समीक्षा की जा सके और अलग से सबमिट किया जा सके। सबमिट किए जाने से पहले प्रत्येक परिवर्तन में all.bat पास होना आवश्यक है। यह अच्छा होगा यदि हम पहला CL सबमिट करने से पहले सभी CL देख सकें।

धन्यवाद।

एलेक्स

क्या हम चाहते हैं कि गो माइक्रोसॉफ्ट बिल्ड टूल्स के साथ-साथ जीसीसी का भी समर्थन करे?

बस एक नोट यह पैच # 17014 की सुविधा भी देता है जिसके लिए मेरे पास पहले से ही एक पैच प्रक्रिया में है।

यदि उत्तर हाँ है, तो @ccamplin को https://golang.org/doc/contribute.html के अनुसार अपने कोड परिवर्तन सबमिट करने होंगे क्या आप ऐसा करने के इच्छुक होंगे? परिवर्तन काफी बड़ा है, इसलिए इसे छोटे CL में विभाजित करने की आवश्यकता है, ताकि उनकी समीक्षा की जा सके और अलग से सबमिट किया जा सके।

हां, और इसे तोड़ना कोई बड़ी बात नहीं होनी चाहिए। मुझे सिर्फ यह जानने की जरूरत है कि क्या यह ऐसा कुछ है जो सभी कोड को साफ करने, दस्तावेज लिखे जाने, परीक्षण किए जाने आदि के प्रयास से पहले जाने की संभावना है।

क्या हम चाहते हैं कि गो माइक्रोसॉफ्ट बिल्ड टूल्स के साथ-साथ जीसीसी का भी समर्थन करे?

मेरे दिमाग में इसका जवाब हां है। कंपाइलर्स स्वयं वीएस कम्युनिटी से मुक्त हैं, और पूर्ण विंडोज़ समर्थन नहीं होने से वास्तव में निराशा होती है। मुझे github.com/Microsoft/hcsshim (उदाहरण के लिए) संकलित करने के लिए एक लिनक्स बॉक्स खड़ा नहीं करना चाहिए, क्योंकि एक विंडोज़ टूलचेन समर्थित नहीं है।

विंडोज टूलचेन का समर्थन न करने का क्या कारण होगा?

मुझे लगता है कि एमएसवीसी ऑब्जेक्ट फाइलों का समर्थन करने के लिए सिद्धांत रूप में यह ठीक है। हमें एक बिल्डर की आवश्यकता होगी।

मेरी मुख्य चिंता यह है कि विंडोज या एमएसवीसी रिलीज के बीच प्रारूप कितना बदल सकता है। अधिकांश अन्य प्लेटफार्मों पर उपयोग किया जाने वाला ईएलएफ प्रारूप बहुत स्थिर है; नए प्रोसेसर के लिए समर्थन जोड़ने के अलावा हमें किसी भी तरह से ईएलएफ समर्थन को बहुत कम करना पड़ता है। क्या MSVC फ़ाइल स्वरूप समान रूप से स्थिर है?

MSVC टूलचेन से जुड़े प्रारूप काफी स्थिर हैं। सबसे बड़ा मुद्दा स्वयं टूल का समर्थन करने वाला है। माइक्रोसॉफ्ट में विजुअल स्टूडियो के रिलीज के बीच चीजों को इधर-उधर करने की प्रवृत्ति है (फाइलें और रजिस्ट्री प्रविष्टियां)। इनमें से अधिकांश विन्यास योग्य है (कम से कम पैच में मैंने लिखा था) लेकिन संभावना अभी भी मौजूद है कि जब विजुअल स्टूडियो का एक नया प्रमुख संस्करण जारी किया जाता है तो यह गो में बदलाव किए बिना बिल्ड टूलचेन के रूप में संगत नहीं हो सकता है। हालांकि विजुअल स्टूडियो के सभी समर्थित पूर्व संस्करण काम करना जारी रखेंगे।

जहां तक ​​​​मुझे पता है, सीओएफएफ प्रारूप में उचित स्थिरता है यदि आप स्वयं को केवल सी एबीआई (सी ++ नहीं) के सामने उजागर करते हैं। यह भी व्यापक रूप से प्रलेखित है और एलएलवीएम एक संदर्भ कार्यान्वयन प्रदान करता है।

@ccamplin मैं अनुशंसा

हमें एक बिल्डर की आवश्यकता होगी।

@ianlancetaylor एक बार MSVC ऑब्जेक्ट्स इरादे के अनुसार काम करने के लिए सिद्ध हो गए हैं, क्या आप मानते हैं कि msys/cygwin बिल्डर और MSVC बिल्डर दोनों की आवश्यकता होगी, या केवल MSVC बिल्डर होगा?

मुझे यकीन है कि कुछ लोग साइबरविन टूल का उपयोग करना पसंद करेंगे, और वे पहले से ही काम कर रहे हैं और हम चाहते हैं कि वे काम करना जारी रखें, इसलिए मुझे लगता है कि हमें दो बिल्डरों की जरूरत है।

अरे यह इस धागे के नीचे से दिखता है कि आपने अपने एमएसवीसी मुद्दों को सुलझा लिया है। लेकिन अगर आपको कोई समस्या आती है, तो मैं एमएसवीसी टीम में हूं। बेझिझक मुझे जीथब या ईमेल पर पिंग करें ([email protected])

हमें एक बिल्डर की आवश्यकता होगी।

हां। और हमें संभावित रूप से अपने मौजूदा बिल्डरों को एमएस बिल्ड टूल्स स्थापित करने के लिए बदलने के साथ शुरू करना चाहिए। इसलिए हम उनका उपयोग कर सकते हैं क्योंकि हम इस मुद्दे के लिए सीएल स्वीकार करते हैं।

हम अपने सभी बिल्डरों पर gcc टूल और Microsoft टूल दोनों इंस्टॉल कर सकते हैं। क्या हम all.bat चला सकते हैं जो एक ही बार में gcc और microsoft दोनों टूल का परीक्षण करता है? यदि नहीं, तो हमें अलग-अलग टूल के लिए अलग-अलग बिल्डरों को कॉन्फ़िगर करने की आवश्यकता होगी। ऐसे कौन से पैरामीटर हैं जो नियंत्रित करते हैं कि बाहरी कंपाइलर और लिंकर्स का क्या उपयोग किया जाता है?

मेरी मुख्य चिंता यह है कि विंडोज या एमएसवीसी रिलीज के बीच प्रारूप कितना बदल सकता है।

आपको विंडोज़ के साथ एक कंपाइलर स्थापित नहीं मिलता है। आपको इसे स्वयं स्थापित करना होगा। जैसे हम जीसीसी के साथ करते हैं। हम जो भी संस्करण पसंद करते हैं उसे स्थापित करते हैं। हम विभिन्न बिल्डरों पर अलग-अलग जीसीसी संस्करण भी चला सकते हैं।

क्या MSVC फ़ाइल स्वरूप समान रूप से स्थिर है?

मुझे इसके बारे में कुछ नहीं पता। मुझे संदेह है कि आप केवल प्रदान किए गए टूल का उपयोग करते हैं।

एलेक्स

मेरी मुख्य चिंता यह है कि विंडोज या एमएसवीसी रिलीज के बीच प्रारूप कितना बदल सकता है। अधिकांश अन्य प्लेटफार्मों पर उपयोग किया जाने वाला ईएलएफ प्रारूप बहुत स्थिर है; नए प्रोसेसर के लिए समर्थन जोड़ने के अलावा हमें किसी भी तरह से ईएलएफ समर्थन को बहुत कम करना पड़ता है। क्या MSVC फ़ाइल स्वरूप समान रूप से स्थिर है?

हां, सीओएफएफ बहुत स्थिर है।

@bradfitz और @ianlancetaylor इस मुद्दे के लिए परिवर्तनों का परीक्षण करने के लिए विंडोज़ बिल्डर उपलब्ध कराने के लिए हमें क्या चाहिए? मेरे प्रश्न https://github.com/golang/go/issues/20982#issuecomment -370719472 पर

शुक्रिया

एलेक्स

गो अब एमएसवीसी ऑब्जेक्ट का समर्थन कर रहा है?

बदलें https://golang.org/cl/110555 इस मुद्दे का उल्लेख करता है: debug/pe: parse the import directory correctly

@alexbrainman @bradfitz @ianlancetaylor :

मुझे लगता है कि पैच को साफ करने और अधिक सुपाच्य टुकड़ों में तोड़ने के लिए मैंने अधिकांश आवश्यक कार्य किए हैं। मेरा मानना ​​है कि मैं परियोजना को वास्तविक रूप से प्रस्तुत करने के लिए तैयार होने के करीब हूं। मुझे लगता है कि मुझे यह जानने की जरूरत है कि क्या मुझे कोड जमा करने से पहले बिल्डर की स्थिति पर शब्द की प्रतीक्षा करनी चाहिए या बस इसे जल्द से जल्द करना चाहिए?

आप किसी भी समय सीएल भेज सकते हैं, लेकिन किसी को एक बिल्डर स्थापित करने की आवश्यकता होती है। अन्यथा हमारे पास उनका परीक्षण करने का कोई तरीका नहीं है।

@johnsonj , क्या आप हमारी विंडोज़ छवियों में एमएसवीसी कंपाइलर टूल्स जोड़ सकते हैं?

मैं आदर्श रूप से एक नया होस्ट प्रकार नहीं जोड़ना चाहता हूं और हमारे मौजूदा विंडोज़ होस्ट प्रकारों में से केवल 1-3 को साइगविन के अतिरिक्त एमएसवीसी टूल्स बनाना चाहता हूं। और फिर हम उन संशोधित होस्ट प्रकारों के शीर्ष पर अधिक बिल्डर कॉन्फ़िगरेशन जोड़ सकते हैं।

/cc @andybons @bcmills FYI के रूप में (विंडोज सामान कैसे होता है ... हम जेफ से मदद की भीख माँगते हैं :))

@johnsonj , क्या आप हमारी विंडोज़ छवियों में एमएसवीसी कंपाइलर टूल्स जोड़ सकते हैं?

@ccamplin मेरा सुझाव है कि आप स्वयं बिल्डर के लिए जो भी उपकरण आवश्यक हैं उन्हें जोड़ने का प्रयास करें। कोई और नहीं, लेकिन आप जानते हैं कि क्या आवश्यक है। पूर्ण निर्देशों के लिए आप golang.org/x/build/env/windows निर्देशिका में देख सकते हैं। विशेष रूप से आप, शायद, स्टार्टअप.ps1 में और लाइनें जोड़ना चाहते हैं। एक बार जब आप जान जाते हैं कि उस निदेशक में क्या परिवर्तन करने की आवश्यकता है, तो परिवर्तन करें और अपने परिवर्तन को समीक्षा के लिए https://golang.org/doc/contribute.html के माध्यम से भेजें।

मैं आदर्श रूप से एक नया होस्ट प्रकार नहीं जोड़ना चाहता हूं और हमारे मौजूदा विंडोज़ होस्ट प्रकारों में से केवल 1-3 को साइगविन के अतिरिक्त एमएसवीसी टूल्स बनाना चाहता हूं। और फिर हम उन संशोधित होस्ट प्रकारों के शीर्ष पर अधिक बिल्डर कॉन्फ़िगरेशन जोड़ सकते हैं।

विंडोज़ पर हमारे पास हमेशा मिंगव (जीसीसी) सी कंपाइलर और लिंकर था। हमारे पास कभी भी सी बिल्ड टूल्स के अलग-अलग सेट नहीं होते हैं। एक बार जब हम माइक्रोसॉफ्ट सी कंपाइलर के लिए समर्थन जोड़ते हैं, तो क्या यह संभव होगा कि सभी के एक रन के साथ मिंगव और माइक्रोसॉफ्ट सी दोनों कार्यों का परीक्षण किया जा सके। या क्या मिंगव या माइक्रोसॉफ्ट सी एक दूसरे को बाहर करते हैं? क्या हमें मिंगव या माइक्रोसॉफ्ट को इंगित करने के लिए कुछ पर्यावरण चर सेट करना होगा, लेकिन दोनों को कभी नहीं? मुझे लगता है कि मैं यह समझने की कोशिश कर रहा हूं कि कोड को कैसे संरचित और परीक्षण किया जाना चाहिए। साथ ही यह तय करेगा कि हमें कितने अलग-अलग बिल्डरों की जरूरत है।

एलेक्स

मैं छवि में बायनेरिज़ को बेक करने पर ध्यान दूंगा

बदलें https://golang.org/cl/112036 इस मुद्दे का उल्लेख करता है: env/windows: add visual studio tools to image

@johnsonj @bradfitz: हो रही है कि बिल्डर में के लिए धन्यवाद।

@alexbrainman @bradfitz @ianlancetaylor : तो जहां तक ​​इसके लिए परीक्षण रणनीति की बात है, मुझे यकीन नहीं है कि वास्तव में क्या करना है। हम खिड़की पर दोनों टूलचेन के लिए डिस्ट टेस्ट चलाने का रास्ता अपना सकते हैं और हर टेस्ट दो बार कर सकते हैं, या क्या हमें केवल दो बार सीजीओ टेस्ट का परीक्षण करना चाहिए (एक बार जीसीसी के लिए, एक बार एमएसवीसी के लिए)?

तो इसके लिए परीक्षण रणनीति के रूप में मुझे यकीन नहीं है कि वास्तव में क्या करना है। हम खिड़की पर दोनों टूलचेन के लिए डिस्ट टेस्ट चलाने का रास्ता अपना सकते हैं और हर टेस्ट दो बार कर सकते हैं, या क्या हमें केवल दो बार सीजीओ टेस्ट का परीक्षण करना चाहिए (एक बार जीसीसी के लिए, एक बार एमएसवीसी के लिए)?

@ccamplin मेरे पास आपके प्रश्न का उत्तर नहीं है। मुझे संदेह है कि इयान जवाब जानता है।

एलेक्स

केवल cgo के बजाय सभी परीक्षणों को दो बार चलाने की लागत क्या है?

@mxplusb , हम सिर्फ विंडोज के लिए एक नया बिल्ड कॉन्फ़िगरेशन चला सकते हैं और यह हमारे मौजूदा 3 के समानांतर चलेगा। एक नया बिल्डर कॉन्फिगरेशन ठीक है। हम उन्हें नियमित रूप से जोड़ते हैं।

बस मुझे बताएं कि इसे अलग कैसे बनाया जाए: एक अलग/नया पर्यावरण चर सेट करें और फिर उस पर कुछ उठाएगा, मुझे लगता है?

इसे काम करने के लिए शायद कुछ चीजें लेनी होंगी।

या तो हमें एक शेल/वातावरण के अंदर चलाने की जरूरत है, जहां उपयुक्त vsvars.bat को चलाने/कॉल किए जाने के बाद डिस्ट टेस्ट निष्पादित करने वाले गो टेस्ट को अंदर चलाया जाएगा

या हम उपयुक्त vsvars को निष्पादित कर सकते हैं और इसके लिए आवश्यक पर्यावरण चर निकाल सकते हैं और फिर परीक्षण के लिए उन्हें सेट/पास कर सकते हैं।

हम शायद कुछ पर्यावरण चर भी चाहते हैं जो dist या make.bat को बताए कि हम -compiler msvc सेट के साथ परीक्षण चलाना चाहते हैं।

या तो हमें एक शेल/वातावरण के अंदर चलाने की जरूरत है, जहां उपयुक्त vsvars.bat को चलाने/कॉल किए जाने के बाद डिस्ट टेस्ट निष्पादित करने वाले गो टेस्ट को अंदर चलाया जाएगा

या हम उपयुक्त vsvars को निष्पादित कर सकते हैं और इसके लिए आवश्यक पर्यावरण चर निकाल सकते हैं और फिर परीक्षण के लिए उन्हें सेट/पास कर सकते हैं।

मैं पसंद करूंगा यदि हम dist.exe या go.exe से बैच फ़ाइलें नहीं चलाते हैं। बैच फ़ाइलों से निपटने में परेशानी होती है।

हम शायद कुछ पर्यावरण चर भी चाहते हैं जो dist या make.bat को बताए कि हम -compiler msvc सेट के साथ परीक्षण चलाना चाहते हैं।

मैं उम्मीद कर रहा था कि इयान को पता होगा कि यहां सबसे अच्छा तरीका क्या है। मैं जो जानता हूं उससे हम यूनिक्स पर भी विभिन्न सी कंपाइलरों का समर्थन करते हैं (जीसीसी या क्लैंग)। निश्चित रूप से हमारी निर्माण प्रक्रिया हमें विभिन्न सी कंपाइलरों के लिए परीक्षण करने की अनुमति देती है।

एलेक्स

मैंने पहले ध्यान नहीं दिया कि आप go build -compiler msvc का उपयोग करने की योजना बना रहे हैं। इसका कोई मतलब नहीं है। go build -compiler विकल्प एक गो कंपाइलर (वर्तमान में या तो gc या gccgo) का नाम लेता है। यह सी कंपाइलर का नाम नहीं लेता है। सी कंपाइलर CC पर्यावरण चर में पारित किया गया है। मेक.बैट चलाते समय डिफ़ॉल्ट सी कंपाइलर CC_FOR_TARGET पर्यावरण चर सेट करके सेट किया जाता है, जैसा कि make.bat में टिप्पणियों में प्रलेखित है।

मुझे उम्मीद है कि हमारे पास एक बिल्डर होगा जिसके लिए हम all.bat चलाने से पहले CC_FOR_TARGET पर्यावरण चर को msvc पर सेट करने की व्यवस्था करते हैं। मैं नहीं देखता कि हमें कुछ और क्यों करना होगा।

सी कंपाइलर सीसी पर्यावरण चर में पारित किया जाता है। मेक.बैट चलाते समय डिफ़ॉल्ट सी कंपाइलर CC_FOR_TARGET पर्यावरण चर सेट करके सेट किया जाता है, जैसा कि make.bat में टिप्पणियों में प्रलेखित है।

समझाने के लिए धन्यवाद इयान।

@ccamplin मुझे आशा है कि आप मौजूदा मॉडल में फिट होने के लिए अपने परिवर्तनों को समायोजित कर सकते हैं। कोई परेशानी हो तो हमें बताएं। धन्यवाद।

मुझे उम्मीद है कि हमारे पास एक निर्माता होगा जिसके लिए हम all.bat चलाने से पहले CC_FOR_TARGET पर्यावरण चर को msvc पर सेट करने की व्यवस्था करते हैं।

हमारे पास https://build.golang.org पर 3 amd64 विंडोज़ निर्माता हैं

एलेक्स

@ianlancetaylor @alexbrainman -कंपाइलर ध्वज के बारे में समझ गया। मुझे नहीं लगता कि काम करने के लिए बस CC="msvc" (या वास्तव में CC="cl.exe" ) सेट करने का कोई आसान तरीका है। MSVC के काम करने के लिए CC को अभी भी GCC स्थान को इंगित करने की आवश्यकता है। एमएसवीसी कंपाइलर टूलसेट में सीजीओ को आत्मनिरीक्षण करने की अनुमति देने के लिए टूलिंग उपलब्ध नहीं है (परिभाषा लुकअप, टाइप रिज़ॉल्यूशन) इसलिए जीसीसी अभी भी एमएसवीसी बिल्ड पर आवश्यक है, जीसीसी का उपयोग वास्तविक संकलन/लिंकिंग चरण में नहीं किया जाता है।

क्या बिल्ड एट जाने के लिए एक नया झंडा जोड़ना स्वीकार्य होगा (टूलचेन या कुछ और)? मुझे विश्वास है कि मुझे पहले से ही सीजीओ में टूलचेन ध्वज जोड़ना पड़ा है।

साथ ही CC_FOR_TARGET को all.bat से पहले सेट करना ऐसा लगता है कि इसके नकारात्मक परिणाम हो सकते हैं क्योंकि यह बूटस्ट्रैपिंग में उपयोग किए गए कंपाइलर को प्रभावित करेगा। मुझे विश्वास नहीं है कि बूटस्ट्रैपिंग प्रक्रिया के दौरान एमएसवीसी का उपयोग किया जा सकता है (मैं इस पर 100% नहीं हूं, मैंने वास्तव में कोशिश नहीं की है लेकिन मुझे अत्यधिक संदेह है कि यह काम करेगा)

मैं देखता हूं, एमएसवीसी के लिए हमें जीसीसी और एमएसवीसी दोनों की आवश्यकता है? जहाँ GCC का उपयोग केवल cgo टूल द्वारा किया जाता है? यह कुछ हद तक दुर्भाग्यपूर्ण लगता है, क्योंकि इसका मतलब है कि हम बिल्कुल उसी एबीआई को लागू करने वाले जीसीसी और एमएसवीसी पर निर्भर होंगे, लेकिन मुझे लगता है कि इसकी काफी संभावना है।

मुझे लगता है कि हम एक और पर्यावरण चर CC_FOR_CGO जोड़ सकते हैं, जिसे जीसीसी पर सेट किया जा सकता है।

Make.bat द्वारा उपयोग किए गए CC_FOR_TARGET उपयोग रनटाइम/cgo बनाने के लिए किया जाएगा। यह मेरे लिए स्पष्ट नहीं है कि यदि आपके द्वारा उपयोग किए जा रहे सी कंपाइलर द्वारा रनटाइम/सीजीओ नहीं बनाया गया है तो सीजीओ कैसे काम कर सकता है।

CC_FOR_TARGET से cl और CGO_ENABLED से 0 सेटिंग करते समय शायद हमें चीजों को काम में लाना शुरू करना चाहिए।

धन्यवाद @ianlancetaylor :

मैं देखता हूं, एमएसवीसी के लिए हमें जीसीसी और एमएसवीसी दोनों की आवश्यकता है? जहाँ GCC का उपयोग केवल cgo टूल द्वारा किया जाता है? यह कुछ हद तक दुर्भाग्यपूर्ण लगता है, क्योंकि इसका मतलब है कि हम बिल्कुल उसी एबीआई को लागू करने वाले जीसीसी और एमएसवीसी पर निर्भर होंगे, लेकिन मुझे लगता है कि इसकी काफी संभावना है।

मैं मानता हूं कि यह दुर्भाग्यपूर्ण है, और कुछ विकल्प के बारे में जानकर खुशी होगी, मुझे अभी तक एक नहीं मिला है। इस तरह से निश्चित रूप से जोखिम निर्माण होता है (उदाहरण के लिए बनाए जा रहे सीजीओ कोड में अलग-अलग प्रकार के डीफ़ होते हैं या परिभाषित करते हैं कि यह किस कंपाइलर द्वारा बनाया जा रहा है)। तो बिल्ड हमेशा सफल नहीं हो सकता है या बिना किसी बदलाव के सही ढंग से काम कर सकता है (मेरे कार्यान्वयन में इसे संभालने के लिए एक तंत्र है, लेकिन यह एक मैन्युअल प्रक्रिया का एक सा है)। अफसोस की बात है कि मुझे लगता है कि यह एक जोखिम है जिसे लोगों को लेना होगा यदि वे एमएसवीसी टूलचेन का उपयोग करना चाहते हैं और हम केवल इसे अभी के लिए दस्तावेज कर सकते हैं।

इसी तरह के नोट पर अभी भी MSVC निर्मित cgo प्रोग्रामों में complex64 और complex128 समर्थन प्रदान करने के लिए कोई वास्तविक रास्ता नहीं है, क्योंकि MSVC कंपाइलर c99 अनुरूप नहीं है।

मुझे लगता है कि हम एक और पर्यावरण चर CC_FOR_CGO जोड़ सकते हैं, जिसे जीसीसी पर सेट किया जा सकता है।

तो मेरे पास वर्तमान में कार्यान्वयन यह है कि यदि निर्माण को एमएसवीसी के साथ बनाने का निर्देश दिया जाता है तो यह डिफ़ॉल्ट रूप से पथ पर cl.exe की तलाश करेगा लेकिन इसे पर्यावरण परिवर्तनीय एमएससीसी के साथ ओवरराइड किया जा सकता है। सीजीओ सीसी पर्यावरण चर का उपयोग करना जारी रखेगा जो जीसीसी में वापस आ रहा है/जो भी उत्पन्न zdefaultcc.go में बैठा है

Make.bat द्वारा उपयोग किए गए CC_FOR_TARGET उपयोग रनटाइम/cgo बनाने के लिए किया जाएगा। यह मेरे लिए स्पष्ट नहीं है कि यदि आपके द्वारा उपयोग किए जा रहे सी कंपाइलर द्वारा रनटाइम/सीजीओ नहीं बनाया गया है तो सीजीओ कैसे काम कर सकता है।

वर्तमान कार्यान्वयन में cgo खुशी से msvc बायनेरिज़ के लिए काम करेगा, भले ही संपूर्ण गो टूलचेन gcc द्वारा बनाया गया हो। जैसे MSVC कोड go/src में जोड़ा जाता है। all.bat जीसीसी का उपयोग करके गो पर्यावरण का निर्माण कर रहा है। उसके बाद go/bin/go.exe का उपयोग msvc टूलचेन के साथ बनाने के लिए किया जा सकता है (यह मानते हुए कि झंडे की आपूर्ति की जाती है)। हालाँकि आप यहाँ जो कह रहे हैं उसे मैं गलत समझ रहा हूँ।

इसके आस-पास की जटिलता क्योंकि यह बताना कि हम msvc के साथ निर्माण करना चाहते हैं, अधिक जटिल है तो बस कंपाइलर को cl पर स्विच करना। MSVC टूलचेन gcc टूलचेन से बहुत अलग है। MSVC में एक वातावरण को vcvars.bat के अंदर चलाने के माध्यम से सेटअप करने की आवश्यकता होती है (या उदाहरण के लिए v8 क्या करता है जो vcvars.bat चला रहा है और इसे स्थापित करने वाले पर्यावरण चर से सभी जानकारी निकालने और फिर अपने निर्माण में इसका उपयोग कर रहा है) प्रक्रिया)। जब हम एक MSVC वातावरण में होते हैं, तो मुख्य अंतर स्वयं उपकरण बन जाता है cl.exe का उपयोग C और C ++ फ़ाइलों को संकलित करने के लिए किया जाता है, ml.exe और ml64.exe का उपयोग फ़ाइलों को इकट्ठा करने के लिए किया जाता है, और अंत में link.exe (ms) का उपयोग किया जाता है। सब कुछ एक साथ जोड़ना। तो यह सिर्फ CC=cl.exe और इसे सही झंडे देने से कहीं अधिक है। क्या यह समझ में आता है/चीजों को स्पष्ट करने में मदद करता है?

आगे स्पष्ट करने के लिए

Make.bat द्वारा उपयोग किया जाने वाला CC_FOR_TARGET रनटाइम/cgo बनाने के लिए उपयोग किया जाएगा। यह मेरे लिए स्पष्ट नहीं है कि यदि आपके द्वारा उपयोग किए जा रहे सी कंपाइलर द्वारा रनटाइम/सीजीओ नहीं बनाया गया है तो सीजीओ कैसे काम कर सकता है।

go build निर्माण प्रक्रिया के दौरान क्रम / सीजीओ से उपयुक्त फ़ाइलों का चयन किया जाता है (उदाहरण के लिए go build / go test / go run - नहीं बिल्डर प्रक्रिया) जब msvc टूलचेन का चयन किया गया है।

मैं सुझावों के लिए खुला हूं कि यह कैसे काम करना चाहिए, लेकिन इसे गो टूल के लिए एक नए कमांड लाइन विकल्प की आवश्यकता नहीं होनी चाहिए। क्या हम एक शुद्ध गो प्रोग्राम लिख सकते हैं जो गो टूल के संबंध में जीसीसी की तरह काम करता है लेकिन वास्तव में एमएसवीसी चलाता है?

क्या हम एक शुद्ध गो प्रोग्राम लिख सकते हैं जो गो टूल के संबंध में जीसीसी की तरह काम करता है लेकिन वास्तव में एमएसवीसी चलाता है?

मुझे विश्वास है कि यह काम करने योग्य हो सकता है, मुझे देखने दो कि क्या मुझे उस रास्ते पर कुछ मिल सकता है।

इसके अतिरिक्त मुझे लगता है कि मुझे यह स्पष्ट करने की आवश्यकता है कि क्या अन्य उपकरणों में कमांड लाइन के झंडे जोड़ना भी एक मुद्दा है। फिलहाल इसके लिए व्यापक पैच विभिन्न उपकरणों में कई नए कमांड लाइन झंडे बना रहा है

• सीएमडी/सीजीओ
  
  
  
  • -टूलचेन [जीसीसी, एमएसवीसी] (जीसीसी के लिए डिफ़ॉल्ट) सीजीओ आउटपुट फाइल बनाते समय टूलचैन का उपयोग करने के लिए
  
  
• सीएमडी/लिंक
  
  
  
  • -rlocbss (गलत के लिए डिफ़ॉल्ट) .bss को .data में स्थानांतरित करें
  
  
  • -टूलचेन [जीसीसी, एमएसवीसी] (जीसीसी के लिए डिफ़ॉल्ट) बाहरी लिंकिंग के लिए टूलचैन का उपयोग किया जाना है
  
  

हम निम्नलिखित बिल्ड विकल्प/cgo पर्यावरण चर भी बनाते हैं:

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

कुछ मिनटों के विचार के बाद कुछ बाधाएं हैं जिन्हें दूर करना मुश्किल हो सकता है अगर हम सिर्फ प्रॉक्सी करते हैं तो कंपाइलर कमांड ने एक अलग प्रोग्राम को एक साथ सोचा

1. go build को यह जानने की जरूरत है कि कौन सी रनटाइम/सीजीओ फाइलों का निर्माण करना है, यह निर्धारित करने के लिए बाहरी टूलचेन क्या है, अन्यथा यह हमारे प्रॉक्सी कमांड में असंगत जीसीसी संस्करणों को पास कर देगा। हम प्रॉक्सी के अंदर ही इसके चारों ओर हैक करने में सक्षम हो सकते हैं लेकिन यह भंगुर होगा और अगर अतिरिक्त फाइलें कभी भी रनटाइम/सीजीओ में जोड़ दी जाती हैं तो टूटने की संभावना है।
2. cmd/cgo को यह जानने की जरूरत है कि आउटपुट सी कोड के किस संस्करण का उपयोग करने के लिए किस प्रकार के बाहरी टूलचेन का उपयोग किया जा रहा है
3. प्रॉक्सी प्रोग्राम को यह जानने के लिए कुछ तंत्र की आवश्यकता होगी कि उसे जीसीसी निष्पादित करना चाहिए या नहीं (जैसा कि सीएमडी/सीजीओ द्वारा बुलाया जाता है) या cl.exe निष्पादित करने के लिए जिसे पारित किया जा सकता है लेकिन इसका मतलब है कि कॉलर को यह जानना होगा कि टूलचेन क्या है है या हम cmd/cgo जीसीसी को गैर-मौजूद झंडे पास कर रहे हैं।
4. go build cmd/link को कॉल करता है, जिसे यह जानने की भी आवश्यकता है कि टूलचेन क्या है ताकि वह .bss से .data स्थानांतरण कर सके और ताकि यह लिंकर को विशिष्ट फ़्लैग पास कर सके (हम इसे बाद में संभालने में सक्षम हो सकते हैं) हालांकि प्रॉक्सी में ही हिस्सा)

msvc बिल्ड कार्य को निर्धारित करने के लिए go build उपयोग करने के लिए एक पर्यावरण चर निर्दिष्ट करना होगा? हालांकि मुझे लगता है कि यह किसी ऐसे व्यक्ति के लिए बार उच्च सेट करता है जो सिर्फ एमएसवीसी के साथ एक प्रोग्राम बनाना चाहता है, क्योंकि अब उन्हें vsvars.bat के अंदर चलने के अलावा कई पर्यावरण चर सेट करना होगा (न्यूनतम CC और UNDECIDED_TURN_ON_MSVC_BUILD_VAR )

एक अन्य विकल्प यह होगा कि go build निर्दिष्ट CC पर एक फर्जी noop कमांड चलाएं और फिर लोगो/हेडर को पार्स करें ताकि यह पता लगाया जा सके कि यह msvc या gcc है और उस बिंदु पर उपयुक्त टूलचेन समायोजन के साथ आगे बढ़ें। ... सुनिश्चित नहीं है कि यह कितना भंगुर है या यह क्लैंग जैसे एमएसवीसी संगत टूलचेन के साथ कैसे काम करेगा।

हाल ही में इस जीथब मुद्दे की खोज की, और यह काम मेरे लिए बहुत रोमांचक है। मैं उम्मीद कर रहा हूं कि यह निकट भविष्य में कहीं जमीन पर आ जाए।

मेरा इरादा विंडोज़ पर सीजीओ को कुछ तृतीय-पक्ष कोड के रैपर के रूप में उपयोग करना है जिसे एमएसवीसी का उपयोग करके बनाया गया है, कि मैं mingw-w64 का उपयोग कर स्रोतों से पुनर्निर्माण नहीं कर सकता। मेरे पास इसे चलाने के लिए कुछ अपेक्षाकृत गंभीर परीक्षण-मामले हैं, इसलिए इसे बहुत अच्छी तरह से मान्य कर सकते हैं।

किसी भी तरह, @ccamplin को धन्यवाद और जो कोई भी इस पर काम कर रहा है, और कृपया मुझे बताएं कि मैं मदद कर सकता हूं।

@ccamplin मैं विंडोज़ और सीजीओ में कंपाइलर टूलचेन के बारे में खतरनाक होने के लिए पर्याप्त जानता हूं कि मैं सहायता करने में सक्षम हो सकता हूं। क्या आप मुझे कुछ पर पकड़ पाएंगे जो आप काम कर रहे हैं? मैं देखूंगा कि सहायता के लिए मैं क्या कर सकता हूं। मुझे पता है कि उपयोग के मामले @deadprogram में है इसलिए जब हम परीक्षण के लिए तैयार होते हैं तो मेरे पास एक अच्छा उन्नत परीक्षण बिस्तर होता है।

अरे @mxplusb , पैच वास्तव में कमोबेश जाने के लिए तैयार है। अगर मुझे समय मिल जाता है तो मैं आज रात या कल गेरिट में परिवर्तन सबमिट कर दूंगा जो हमें हर चीज की समीक्षा, अद्यतन और स्वीकृत करने के लिए प्रेरित करेगा।

बदलें https://golang.org/cl/133937 इस मुद्दे का उल्लेख करता है: cmd/link: Add flag rlocbss to relocate .bss data to .data

बदलें https://golang.org/cl/133938 में इस मुद्दे का उल्लेख है: runtime/cgo: MSVC toolchain support in cgo native code

बदलें https://golang.org/cl/133939 में इस मुद्दे का उल्लेख है: cmd/cgo: Add toolchain flag to cgo command for MSVC support

बदलें https://golang.org/cl/133946 इस मुद्दे का उल्लेख करता है: cmd/compile: Add support for MSVC toolchain to go build

ऐसा लगता है कि मैंने कुछ कामों में इस मुद्दे को टाइप किया है। मैं समीक्षा प्रक्रिया को चलने दूंगा और ठीक करने का सबसे अच्छा तरीका निर्धारित करूंगा।

बदलें https://golang.org/cl/133943 इस मुद्दे का उल्लेख करता है: cmd/cgo: Add support for CC_FOR_CGO environment variable

बदलें https://golang.org/cl/133942 में इस मुद्दे का उल्लेख है: tests: Update various tests to prepare for MSVC compiler toolchain

बदलें https://golang.org/cl/133940 में इस मुद्दे का उल्लेख है: misc/cgo: Adjust tests to be compatible with MSVC toolchain support

बदलें https://golang.org/cl/133941 में इस मुद्दे का उल्लेख है: runtime: Add runtime.CompilerType to denote between host compiler type

बदलें https://golang.org/cl/133945 इस मुद्दे का उल्लेख करता है: cmd/link: Add external toolchain support for MSVC

बदलें https://golang.org/cl/133944 इस मुद्दे का उल्लेख करता है: cmd/compile, cgo: Add support for MSVC flags

@ccamplin क्या आप

इसके अलावा, हम इस पैच को कैसे आजमा सकते हैं? मुझे रेपो पर आपके काम नहीं मिले।

@rasky यह अभी भी थोड़ा प्रवाह में है क्योंकि परिवर्तन समीक्षा के माध्यम से जाते हैं। संभावित रूप से कोई विशिष्ट कमांड लाइन झंडे नहीं होंगे जिन्हें सेट करने की आवश्यकता है, केवल सीजीओ अनुप्रयोगों का निर्माण जहां सीसी पर्यावरण चर एमएसवीसी को इंगित किया गया है या कोई सीसी सेट नहीं है, एक cl.exe पथ पर है लेकिन जीसीसी नहीं है।

@blizzardplus उपरोक्त चीजों के समान अभी समीक्षा के साथ बहुत अधिक प्रवाह में है, इसलिए इसे

@ccamplin या तो gcc या clang का उपयोग करके क्रॉस संकलन के लिए समर्थन है? यदि हां, तो क्या उनका परीक्षण किया जाता है ?

@ccamplin मुझे 9/11 के बाद से

@ccamplin इसके लिए

साथ ही, इसके लिए निर्यात किए जाने वाले कार्यों को सी-साझा करने के लिए काम करने के लिए __declspec (dllexport) सजाया जाना चाहिए, लेकिन मुझे यह नहीं लगता कि//निर्यात का यह विस्तार कहां होता है।

@blizzardplus क्लैंग -

@kshelton दुर्भाग्य से यह मेरे लिए वर्ष का एक बहुत व्यस्त समय है क्योंकि मेरे पास उन कार्यों और सम्मेलनों में अन्य परियोजनाएं हैं जिन्हें मैं प्रस्तुत कर रहा हूं। मैं दिसंबर तक पैच में आवश्यक रिफैक्टरिंग प्राप्त करने में वापस कूदने में सक्षम नहीं हो सकता।

@kshelton धन्यवाद। मैंने पैच की दोबारा जांच नहीं की है, मुझे लगता है कि मैंने इसे इस धारणा के साथ विकसित किया है कि सी-संग्रह एमएसवीसी पर काम नहीं करेगा, या विशेष रूप से इसे अक्षम कर देगा? जब मैं विंडोज़ पर प्लगइन/साझा करने की कोशिश कर रहा था तो मैं निर्यात को ठीक से सजाने की कोशिश करने के रास्ते पर चला गया। मुझे विश्वास है कि अन्य मुद्दे भी हैं, लेकिन मैं दो मुद्दों का सामना कर सकता हूं। ईएलएफ बनाम विंडोज़ .edata, idata और EAT के लिए पीएलटी/जीओटी में अपने साझा कोड के साथ वास्तविक समस्याएं हैं। मेरा मानना ​​​​है कि जिन मुद्दों का मैंने सामना किया उनमें से अधिकांश स्थानांतरण के आसपास थे और उन्हें काम पर लाने में असमर्थ थे। अगर किसी के पास इसमें अंतर्दृष्टि है तो यह अद्भुत होगा। #19282 देखें

@ccamplin मैंने देखने की कोशिश की, क्या मैं आपके CL . के शीर्ष पर गो बना सकता हूं

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

मैंने अपना वातावरण सेट करने के लिए इस बैच फ़ाइल का उपयोग किया है

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

और जब मैं make.bat चलाता हूं तो मुझे यह त्रुटि मिलती है

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

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

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

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

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

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

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

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

Command output:

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

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

The system cannot find the batch label specified - fail

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

मुझे यहां क्या समझ नहीं आ रहा है?

धन्यवाद।

एलेक्स

@alexbrainman

मुझे यहां क्या समझ नहीं आ रहा है?

आपको कम से कम CC_FOR_CGO=gcc सेट करने की आवश्यकता हो सकती है। मैंने कभी भी व्यक्तिगत रूप से MSVC के साथ स्वयं निर्माण करने की कोशिश नहीं की है। मुझे यकीन नहीं है कि यह काम करेगा/समर्थन किया जाना चाहिए।

-सी

आपको कम से कम CC_FOR_CGO=gcc सेट करने की आवश्यकता हो सकती है।

आपके https://go-review.googlesource.com/c/go/+/133940 में कुछ परीक्षण हैं। मैं परीक्षण पास कैसे सत्यापित करूं? सटीक कदम क्या हैं?

सभी परीक्षणों को सत्यापित करने के लिए बिल्डरों पर जाएं https://build.golang.org %GOROOT%\src\all.bat चलाएं (https://go-review.googlesource.com/c/go/+/ में सूचीबद्ध परीक्षणों सहित) 133940) पास। आप कैसे प्रस्तावित करते हैं कि हम %GOROOT%\src\all.bat को https://go-review.googlesource.com/c/go/+/133940 से अपने समायोजित परीक्षण चलाने के लिए गो कोड को संशोधित

मैंने कभी भी व्यक्तिगत रूप से MSVC के साथ स्वयं निर्माण करने की कोशिश नहीं की है। मुझे यकीन नहीं है कि यह काम करेगा/समर्थन किया जाना चाहिए।

आप बिना gcc इंस्टॉल किए all.bat को सफलतापूर्वक पूरा करने के लिए चला सकते हैं। गो के वर्तमान संस्करण को बनाने के लिए केवल गो के दूसरे संस्करण (कम से कम go1.4) की आवश्यकता है। केवल सीजीओ को सी कंपाइलर की जरूरत है, मैं इस धारणा में था कि आपके परिवर्तन एमएसवीसी द्वारा बनाए गए सीजीओ संस्करण को लागू करते हैं। लेकिन, शायद, मुझसे गलती हुई है। अगर मैं गलत हूं कृपया मुझे सही।

धन्यवाद।

एलेक्स

@alexbrainman

आपके https://go-review.googlesource.com/c/go/+/133940 में कुछ परीक्षण हैं। मैं परीक्षण पास कैसे सत्यापित करूं? सटीक कदम क्या हैं?

शायद all.bat परीक्षण के gcc और msvc दोनों संस्करणों का परीक्षण कर सकता है। शायद हम कुछ पर्यावरण चर का उपयोग कर सकते हैं जो सभी को बताता है कि परीक्षण का कौन सा संस्करण चलाना है - विज्ञापन तब हम दो अलग-अलग बिल्डरों को परीक्षणों के विभिन्न संस्करण चला सकते हैं। क्या आपने यह सब सोचा?

हां, इस सटीक तंत्र का उपयोग https://go-review.googlesource.com/c/go/+/133946/ में किया जाता है

आप बिना gcc इंस्टॉल किए all.bat को सफलतापूर्वक पूरा करने के लिए चला सकते हैं। गो के वर्तमान संस्करण को बनाने के लिए केवल गो के दूसरे संस्करण (कम से कम go1.4) की आवश्यकता है। केवल सीजीओ को सी कंपाइलर की जरूरत है, मैं इस धारणा में था कि आपके परिवर्तन एमएसवीसी द्वारा बनाए गए सीजीओ संस्करण को लागू करते हैं। लेकिन, शायद, मुझसे गलती हुई है। अगर मैं गलत हूं कृपया मुझे सही।

ठीक कह रहे हैं आप। जाओ ही ठीक निर्माण करना चाहिए। परीक्षण में आने पर समस्याएँ हो सकती हैं, क्योंकि GOTESTMSVC = 1 पर कुछ पर्यावरण चर सेट करने के लिए run.bat को संशोधित किया गया था। हम शायद यह पता लगाने की कोशिश कर सकते हैं कि क्या एमएसवीसी के साथ बस बनाया जा रहा है, और उसके बाद उपयुक्त दूरस्थ पर्यावरण चर सेट करें ताकि परीक्षण विफल न हों।

फिर आप GOTESTMSVC=1 और GOVSVARSPATH=some vsvars.bat पथ सेट करेंगे। उसके बाद all.bat के साथ भवन को gcc और msvc cgo दोनों परीक्षणों के माध्यम से चलाना चाहिए।

मैंने वह कोशिश की।

मैंनें इस्तेमाल किया

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

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

    Allows building with MSVC as an external compiler/linker.

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

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

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

मैं पहले इस बैच फ़ाइल को चलाता हूं:

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

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

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

और फिर all.bat चलाएँ। all.bat साथ विफल रहता है

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

साथ ही GOTESTMSVC और GOVSVARSPATH को सेट करना उन लोगों के लिए काम कर सकता है जो all.bat को क्रियान्वित कर रहे हैं। लेकिन आपके परिवर्तन के अन्य उपयोगकर्ता क्या करेंगे जब उन्हें Cgo के लिए MSVC का उपयोग करने की आवश्यकता होगी? इसके लिए आपकी क्या योजना है?

एलेक्स

@alexbrainman
मुझे यकीन नहीं है कि क्या हो रहा है। मास्टर पर मेरे लिए वह परीक्षा विफल हो रही है

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

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

help.go में https://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/internal/help/help.go#L37
यह आधार के माध्यम से पुनरावृति करता है।जाओ।आदेश। जिसे main.go में इनिशियलाइज़ किया गया है https://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/main.go#L43
लेकिन मुझे यकीन नहीं है कि परीक्षण निष्पादन योग्य में उस init फ़ंक्शन को कभी भी कैसे बुलाया जाएगा, इसलिए मुझे नहीं पता कि मास्टर अभी परीक्षण कैसे पास कर रहा है, क्योंकि मुझे लगता है कि यह पूरे बोर्ड में विफल होना चाहिए।

साथ ही GOTESTMSVC और GOVSVARSPATH को सेट करना उन लोगों के लिए काम कर सकता है जो all.bat को क्रियान्वित कर रहे हैं। लेकिन आपके परिवर्तन के अन्य उपयोगकर्ता क्या करेंगे जब उन्हें Cgo के लिए MSVC का उपयोग करने की आवश्यकता होगी? इसके लिए आपकी क्या योजना है?

तो ऐसी स्थिति में जहां आप एमएसवीसी के साथ कुछ सीजीओ कोड बनाना चाहते हैं

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

मुझे लगता है कि आपको बस इतना ही चाहिए

मुझे यकीन नहीं है कि परीक्षण निष्पादन योग्य में उस init फ़ंक्शन को कभी भी कैसे बुलाया जाएगा, इसलिए मुझे नहीं पता कि मास्टर अभी परीक्षण कैसे पास कर रहा है, क्योंकि मुझे लगता है कि यह पूरे बोर्ड में विफल होना चाहिए।

cmd/go में फ़ाइल के साथ go test का उपयोग करते समय, go टूल cmd/go पैकेज बनाएगा और फिर परीक्षण बनाएगा, परीक्षण ड्राइवर उत्पन्न करेगा, उसे बनाएगा, और सब कुछ एक साथ एक नए मुख्य पैकेज में लिंक करेगा। ऐसा तब भी होता है जब cmd/go अपने आप में एक मुख्य पैकेज होता है। अर्थात्, cmd/go/*.go में मुख्य पैकेज को परीक्षण के प्रयोजनों के लिए गैर-मुख्य पैकेज माना जाएगा। यह परीक्षण को मुख्य पैकेज में परिभाषित कार्यों को कॉल करने में सक्षम बनाता है यदि उपयुक्त हो।

क्षमा करें, मैं उत्तर देने में धीमा हूँ। लेकिन मेरे पास इस पर दोबारा गौर करने के लिए खाली समय नहीं था।

मुझे यकीन नहीं है कि क्या हो रहा है। मास्टर पर मेरे लिए वह परीक्षा विफल हो रही है

मैंने मास्टर का उपयोग नहीं किया। मैंने आपके e56d52f66b95b87001867a2487a11bd961f40d4d कमिट का उपयोग किया। क्या आपने समीक्षा के लिए भेजने से पहले उस प्रतिबद्धता पर all.bat नहीं चलाया? क्या all.bat सफल हुआ? क्या आप उस कमिट पर all.bat को फिर से चलाने की कोशिश कर सकते हैं, यह देखने के लिए कि क्या यह मेरे सिस्टम कॉन्फ़िगरेशन के साथ कुछ करना है। धन्यवाद।

तो ऐसी स्थिति में जहां आप एमएसवीसी के साथ कुछ सीजीओ कोड बनाना चाहते हैं

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

मुझे लगता है कि आपको बस इतना ही चाहिए

2 पर्यावरण चर, शायद, औसत उपयोगकर्ता के लिए बहुत जटिल हैं। और CC_FOR_CGO=gcc मुझे अजीब लग रहा है - हम MSVC के साथ कोड बनाने के लिए gcc का उपयोग क्यों करते हैं?

एलेक्स

@alexbrainman

मैंने मास्टर का उपयोग नहीं किया। मैंने आपके e56d52f66b95b87001867a2487a11bd961f40d4d कमिट का उपयोग किया। क्या आपने समीक्षा के लिए भेजने से पहले उस प्रतिबद्धता पर all.bat नहीं चलाया? क्या all.bat सफल हुआ? क्या आप उस कमिट पर all.bat को फिर से चलाने की कोशिश कर सकते हैं, यह देखने के लिए कि क्या यह मेरे सिस्टम कॉन्फ़िगरेशन के साथ कुछ करना है। धन्यवाद।

मुझे लगता है कि यह मेरे सिस्टम कॉन्फ़िगरेशन के साथ कुछ करने के लिए था जो परीक्षण चलाते समय मुझे अजीब परिणाम दे रहा था। मुझे लगता है कि मैंने इस मुद्दे को ठीक कर लिया है और कुछ अपडेट को परिवर्तन सेट में धकेल दिया है।

2 पर्यावरण चर, शायद, औसत उपयोगकर्ता के लिए बहुत जटिल हैं। और CC_FOR_CGO=gcc मुझे अजीब लगता है - हम MSVC के साथ कोड बनाने के लिए gcc का उपयोग क्यों करते हैं?

यह वास्तव में शायद CC_FOR_CGO=gcc.exe होना चाहिए, मेरी गलती। लेकिन आपके प्रश्न का उत्तर देने के लिए; गेरिट से:

PS1, लाइन 1324:
cgo को अभी भी टाइप विश्लेषण के लिए उपलब्ध gcc की आवश्यकता है। यदि CC को MSVC कंपाइलर पर सेट किया गया है तो cgo को GCC को कॉल करने के लिए एक साधन की आवश्यकता होती है जो CC_FOR_CGO द्वारा प्रदान किया जाता है। दुर्भाग्य से MSVC टूलचेन में उसी प्रकार की जानकारी प्रदान करने के लिए कोई तंत्र नहीं है जो gcc से एकत्र की जा रही है। सैद्धांतिक रूप से सीजीओ द्वारा उपयोग की जाने वाली प्रकार की जानकारी एकत्र करने के लिए एक विशिष्ट उपकरण बनाया जा सकता है लेकिन यह गुंजाइश से बाहर हो सकता है और संभवतः काफी प्रयास (मैंने व्यक्तिगत रूप से सी/सी ++ कोड के स्थिर प्रकार विश्लेषण करने के लिए कुछ भी नहीं लिखा है)।

मुझे लगता है कि जीसीसी बनाम एमएसवीसी के लिए रनों के बीच स्पष्ट कैश के साथ कुछ टूट गया है, मुझे यकीन नहीं है कि क्यों कुछ परीक्षण अभी भी काम कर रहे हैं जैसे कि वे कैश किए गए हैं।

मुझे लगता है कि मैंने इस मुद्दे को ठीक कर लिया है और कुछ अपडेट को परिवर्तन सेट में धकेल दिया है।

यह सेटअप https://github.com/golang/go/issues/20982#issuecomment -447618566 पर

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

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

    Allows building with MSVC as an external compiler/linker.

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

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

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

मुझे और आगे ले जाता है, लेकिन फिर भी विफल रहता है

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

ALL TESTS PASSED

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

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

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

यह वास्तव में शायद CC_FOR_CGO=gcc.exe होना चाहिए, मेरी गलती।

मैं gcc.exe में .exe के बारे में चिंतित नहीं हूं। मेरे मुद्दे हैं

• MSVC का उपयोग करने के लिए आपको gcc और MSVC दोनों उपकरणों की आवश्यकता है (इसे हमारे उपयोगकर्ताओं को समझाना कठिन होगा), लेकिन मैं समझता हूँ कि इसके बारे में कुछ भी नहीं किया जा सकता है;

• मुझे दोनों पर्यावरण चर CC_FOR_CGO=gcc और CC=cl.exe सेट की आवश्यकता थी - शायद हम मान सकते हैं कि CC_FOR_CGO हमेशा जीसीसी पर सेट है?

लेकिन आपके प्रश्न का उत्तर देने के लिए; गेरिट से:

समझाने के लिए धन्यवाद।

एलेक्स

@alexbrainman

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

मुझे यकीन नहीं है कि यह चेतावनी कैसे होगी जब तक कि आपके पास msvc_libinit_windows.c की एक अलग/पुरानी प्रति न हो। क्या आप पुष्टि कर सकते हैं कि इसमें यह पंक्ति है:

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

C4710 को stdio शामिल करने के लिए दबाया जाना चाहिए। मैं देखता हूं कि एमएसवीसी का आपका संस्करण मेरे से थोड़ा अलग है, जो एक अपराधी भी हो सकता है। मुझे यकीन नहीं है कि वे एक अलग संस्करण में उस दमन को सक्रिय रूप से अनदेखा क्यों करेंगे।

आप वैश्विक स्तर पर दमन को शामिल करने के लिए बदलाव करने का प्रयास भी कर सकते हैं, चाहे कुछ भी हो

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

मुझे दोनों पर्यावरण चर CC_FOR_CGO=gcc और CC=cl.exe सेट की आवश्यकता थी - शायद हम मान सकते हैं कि CC_FOR_CGO हमेशा जीसीसी पर सेट है?

मुझे लगता है कि अगर CC_FOR_CGO सेट नहीं है तो gcc मौजूद है या नहीं, यह ठीक होगा। CC_FOR_CGO मेरे जैसे लोगों के लिए अधिक है जिनके पथ में gcc नहीं है। मेरा CC_FOR_CGO इस तरह दिखता है CC_FOR_CGO=I:\Development\tmd-gcc\bingcc.exe। अगर हम जीसीसी के उपयोग के मामले का समर्थन नहीं करना चाहते हैं जो एमएसवीसी के निर्माण के रास्ते पर नहीं है तो मुझे बताएं और मैं पर्यावरण चर से एक साथ छुटकारा पा सकता हूं।

मैंने इस संस्करण को फिर से कोशिश की

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

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

    Allows building with MSVC as an external compiler/linker.

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

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

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

और मुझे वही त्रुटि मिलती है

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

ALL TESTS PASSED

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

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

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

क्या आप पुष्टि कर सकते हैं कि इसमें यह पंक्ति है:

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

यह मेरी src/runtime/cgo/msvc_libinit_windows.c फ़ाइल की शुरुआत है

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

// +build cgo

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

आप वैश्विक स्तर पर दमन को शामिल करने के लिए बदलाव करने का प्रयास भी कर सकते हैं, चाहे कुछ भी हो

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

मैंने यह परिवर्तन किया है:

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

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

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

लेकिन मुझे वही त्रुटि दिखाई दे रही है

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

ALL TESTS PASSED

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

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

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

एलेक्स

मैं कल रात इसे पुन: पेश करने की कोशिश कर रहा था और मैं असमर्थ था। मैं सोच रहा हूं कि क्या आप इसका अनुभव कर रहे हैं: https://developercommunity.visualstudio.com/content/problem/35734/c-cannot-disable-specific-warnings-with-pragmas-wh.html

क्या आपके लिए नवीनतम एसडीके और बिल्ड टूल्स में अपडेट करना संभव है? मैं एसडीके 10.0.17763.0 पर हूं। और बिल्ड टूल्स/डेवेनव का संस्करण 15.9.28307.222

मैं एमएसवीसी के साथ एक विंडोज डीएलएल बनाने की कोशिश कर रहा हूं, लेकिन ऐसा लगता है कि गो 65535 (या संख्या नहीं) से अधिक संख्या के साथ कुछ चेतावनी को अक्षम करने का प्रयास करता है, जिससे एमएसवीसी बंद हो जाता है।

नहीं. Werror हर चेतावनी को एक त्रुटि मानने के लिए एक GCC विकल्प है.

एमएसवीसी के लिए आपको WX उपयोग करना चाहिए।

@pravic अच्छा बिंदु, मैं यह कैसे करूँगा? मैं इसे सेट नहीं कर रहा हूं, मैं बस इतना कर रहा हूं:

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

@galich दुर्भाग्य से, मैं मदद नहीं कर सकता क्योंकि मैं

उदाहरण के लिए, इस धागे से संबंधित पैच कहां हैं? गुरु में या कहीं और?

@pravic आप यहां बदलाव देख सकते हैं: https://go-review.googlesource.com/c/go/+/133946/5

@mxplusb लिंक के लिए धन्यवाद, ऐसा लगता है कि/Werror के साथ मेरा विशेष मुद्दा वहां हल हो गया है।
क्या आप जानते हैं कि यह बीटा/रात/स्थिर में कब आ रहा है?

क्या आपके लिए नवीनतम एसडीके और बिल्ड टूल्स में अपडेट करना संभव है? मैं एसडीके 10.0.17763.0 पर हूं। और बिल्ड टूल्स/डेवेनव का संस्करण 15.9.28307.222

@ccamplin अंत में मैं अपने MSVC को अपडेट करने में कामयाब रहा। अब मेरे पास है

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

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

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

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

मैंने इस संस्करण को फिर से कोशिश की

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

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

    Allows building with MSVC as an external compiler/linker.

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

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

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

और all.bat सफलतापूर्वक पूरा होता है। लेकिन मुझे ये चेतावनियां मिलती हैं।

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

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

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

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

##### ../test

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

ALL TESTS PASSED

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

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

और मैंने यह भी देखा कि आप सभी परीक्षणों को दो बार निष्पादित करते हैं।

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

ALL TESTS PASSED

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


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

क्यों?

एलेक्स

@alexbrainman इन परीक्षणों के लिए चेतावनियों को दबाया जा सकता है, खासकर इस मामले में स्पेक्टर चेतावनियां।

दो बार निष्पादित परीक्षणों के लिए, मेरा मानना ​​​​है कि यह बिल्डर के लिए इस तरह से किया गया था, एक बार जीसीसी संकलन के साथ परीक्षणों के माध्यम से चलाएं, फिर दोनों टूलचेन कार्यों के साथ संकलन सुनिश्चित करने के लिए एमएसवीसी (जब सक्षम हो) के साथ फिर से चलाएं। मुझे यकीन नहीं है कि यहां क्या वांछित है, इसलिए मैं इसे बदल सकता हूं ताकि जब एमएसवीसी सक्षम के साथ all.bat को कॉल किया जाए तो हम केवल एमएसवीसी के साथ परीक्षण चलाते हैं, मुझे बताएं। उस स्थिति में मुझे लगता है कि अतिरिक्त बिल्डरों को केवल एमएसवीसी के लिए जोड़ने की आवश्यकता होगी, क्योंकि कुछ बिल्डर्स एमएसवीसी के साथ भी निर्माण कर रहे हैं?

सहमत हैं कि विंडोज़ पर दोनों परिदृश्यों का परीक्षण करने के लिए एक निर्माता को मिनीजीडब्ल्यू-डब्ल्यू 64 टूलचेन का उपयोग करके और दूसरे को एमएसवीसी टूलचेन के साथ चलाने की आवश्यकता होगी।

मेरा मानना ​​​​है कि यह बिल्डर के लिए किया गया था, एक बार जीसीसी संकलन के साथ परीक्षणों के माध्यम से चलाएं, फिर दोनों टूलचेन कार्यों के साथ संकलन सुनिश्चित करने के लिए एमएसवीसी (जब सक्षम हो) के साथ फिर से चलाएं।

मैं मानता हूं कि यह पसंदीदा व्यवहार होना चाहिए, इसलिए इस बात की गारंटी है कि यह मौजूदा वर्कलोड को नहीं तोड़ता है यदि दोनों टूलचेन मौजूद हैं।

इन परीक्षणों के लिए चेतावनियों को दबाया जा सकता है, खासकर इस मामले में स्पेक्टर चेतावनियां।

गो कमांड चेतावनियां प्रदर्शित नहीं करता है, इसलिए चेतावनियां प्रदर्शित नहीं की जानी चाहिए।

साथ ही मैंने देखा कि go env कमांड CC_FOR_CGO चर प्रदर्शित नहीं करता है। यदि CC_FOR_CGO गो बिल्ड के काम करने के तरीके को प्रभावित करता है, तो CC_FOR_CGO को अन्य के साथ प्रदर्शित किया जाना चाहिए। क्या हमें वास्तव में CC_FOR_CGO चर की आवश्यकता है? CC_FOR_CGO=gcc के अलावा और क्या हो सकता है?

दो बार निष्पादित परीक्षणों के लिए, मेरा मानना ​​​​है कि यह बिल्डर के लिए इस तरह से किया गया था, एक बार जीसीसी संकलन के साथ परीक्षणों के माध्यम से चलाएं, फिर दोनों टूलचेन कार्यों के साथ संकलन सुनिश्चित करने के लिए एमएसवीसी (जब सक्षम हो) के साथ फिर से चलाएं।

बहुत सारे परीक्षण gcc का उपयोग नहीं करते हैं। यह लोगों/कंप्यूटर के समय की बर्बादी है जब बिना किसी कारण के पैकेज परीक्षण दो बार चलते हैं। जैसा कि आप https://github.com/golang/go/issues/20982#issuecomment से देख सकते हैं -480569880 archive/zip पैकेज परीक्षण दो बार चलाए गए - मुझे दूसरे रन की आवश्यकता नहीं दिख रही है।

मुझे यकीन नहीं है कि इसे कैसे व्यवस्थित किया जाए, लेकिन शायद आपको MSVC बिल्ड का परीक्षण करने के लिए आवश्यक परीक्षणों का चयन करने के लिए run.bat में अपनी go tool dist test की कॉल को प्रतिस्थापित करना चाहिए। उदाहरण के लिए, go tool dist test -h देखें कि आप कुछ विशिष्ट परीक्षणों का चयन कैसे कर सकते हैं। @bradfitz शायद हम कुछ ध्वज या पर्यावरण चर बना सकते हैं जो

लेकिन सामान्य तौर पर आपका https://go-review.googlesource.com/c/go/+/133946/5 मेरे लिए निष्पादन योग्य बना रहा है। उदाहरण के लिए, मैं जीसीसी के साथ निष्पादन योग्य बना सकता हूं:

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>

और फिर मैं एमएसवीसी के साथ निष्पादन योग्य बना सकता हूं

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>

तो एमएसवीसी के साथ निर्माण के लिए उपयोगकर्ताओं को सभी पर्यावरण चर सेट करने के लिए एमएस बैच फ़ाइल चलाने की आवश्यकता होगी (मेरे आउटपुट में GOVSVARSPATH देखें) - और, मुझे लगता है, मानक और इसका गो से कोई लेना-देना नहीं है। और set CC=cl । काफी सरल।

इस दृष्टिकोण के साथ मुझे जो एकमात्र समस्या दिखाई दे रही है वह यह है कि एमएसवीसी उपयोगकर्ताओं को अभी भी जीसीसी स्थापित करने की आवश्यकता होगी। सभी सी इंटरफेस को खोजने के लिए सीएमडी/सीजीओ द्वारा जीसीसी का उपयोग किया जाता है - यह हिस्सा एमएसवीसी का उपयोग करके कार्यान्वित नहीं किया जाता है। उन लोगों के लिए असामान्य लगता है जो नहीं जानते कि cmd/cgo कैसे काम करता है, लेकिन यह वही है जो यह है।

@ianlancetaylor और @bradfitz क्या इसे आगे बढ़ाने के लिए यह सब उचित लगता है? क्या हमें इसे go1.13 में उपलब्ध कराने का प्रयास करना चाहिए?

जिन बिल्डर्स के पास MSVC पहले से इंस्टॉल है, वे सभी नए कोड का परीक्षण कर सकते हैं। अन्य बिल्डर्स सिर्फ परीक्षण छोड़ देंगे।

एलेक्स

सभी सी इंटरफेस को खोजने के लिए सीएमडी/सीजीओ द्वारा जीसीसी का उपयोग किया जाता है - यह हिस्सा एमएसवीसी का उपयोग करके कार्यान्वित नहीं किया जाता है।

उस पर कैसे काबू पाया जा सकता है? आदर्श रूप से यह बहुत अच्छा होगा यदि जीसीसी की कोई आवश्यकता नहीं है, केवल एमएसवीसी।

उस पर कैसे काबू पाया जा सकता है?

cmd/cgo के भाग जो gcc का उपयोग करते हैं उन्हें MSVC का उपयोग करने के लिए फिर से लिखना होगा। अगर ये सम्भव हो।

एलेक्स

मैं सोच रहा था कि क्या यह सुविधा इसे उत्पादन में लाने के करीब है? मैं देखता हूं कि इसे 1.13 के लिए टैग किया गया था, और वह अभी निकला। मैं गो सी-आर्काइव बिल्ड का उपयोग करके पायथन एक्सटेंशन बनाने की कोशिश कर रहा हूं जो एक्सटेंशन कोड से जुड़ा हुआ है, लेकिन पायथन को एमएसवीसी की आवश्यकता है।

मुझे नहीं पता कि इस मुद्दे की स्थिति क्या है। इसे रिलीज से रिलीज करने के लिए आगे बढ़ाया गया है, इसलिए मैं इसे अनियोजित करने जा रहा हूं। अगर यह 1.14 में आता है, तो बढ़िया।

डबल-कंपाइलर आवश्यकता के साथ भी, मुझे वर्तमान कार्यान्वयन को अगली रिलीज में देखना अच्छा लगेगा। यह कम से कम एमएसवीसी का उपयोग करके निष्पादन योग्य/पुस्तकालयों को संकलित करना संभव बनाता है, जो कुछ भी नहीं से बेहतर है।

डबल-कंपाइलर आवश्यकता के साथ भी, मुझे वर्तमान कार्यान्वयन को अगली रिलीज में देखना अच्छा लगेगा।

मुझे लगता है कि यह एक अच्छा "बीटा" कार्यान्वयन होगा। यह बग को बाहर निकालने और कार्यान्वयन को परिपक्व होने की अनुमति देगा। गंभीर समीक्षा से गुजरने से पहले और क्या किया जाना बाकी है?

इसलिए मेरे दृष्टिकोण से और पिछली बार जब मैंने इसे देखा था (~ 6 महीने पहले) से मैं क्या याद कर सकता हूं, वहां एक दर्जन या इतने ही सफाई आइटम थे जिन्हें कोड समीक्षा प्रक्रिया के लिए पूरा करने की आवश्यकता थी। कुछ परीक्षणों को कम करने के लिए अतिरिक्त काम की भी आवश्यकता हो सकती है जिन्हें मूल रूप से एक अलग टूलचेन के साथ काम करने के लिए बहुत मामूली संशोधनों के साथ कॉपी किया गया था। कुछ एमएसवीसी चेतावनियों की समीक्षा करने और उन्हें बंद करने की भी आवश्यकता है।

प्रमुख बकाया मुद्दों में शामिल हैं:

हम जीसीसी के बिना टाइप विश्लेषण नहीं कर सकते हैं, इसका कोई आसान या तत्काल समाधान नहीं है।

सेटअप को अंतिम रूप देना और बिल्डरों के लिए सब कुछ कैसे काम करने वाला है।

मेरा मानना ​​​​है कि पिछले 6 महीनों में कंपाइलर और लिंकर में कुछ महत्वपूर्ण बदलाव हुए हैं जो इसके लिए किए गए वर्तमान कार्य को गंभीर रूप से प्रभावित कर सकते हैं, लेकिन मैं इसकी पुष्टि नहीं कर पाया हूं। गो के कंपाइलर/लिंकर/टूलचेन को नेविगेट करने के आसपास की जटिलता और उच्च सीखने की अवस्था के कारण मुझे इस काम के शरीर पर किसी भी बदलाव के प्रभाव को समझने के लिए पर्याप्त गति प्राप्त करने में काफी समय लग सकता है।

जटिल संख्यात्मक प्रकारों के लिए कोई समर्थन नहीं है। MSCVs C lib बस असंगत है। मेरा मानना ​​​​है कि सी ++ के साथ इसे कम करने का एक तरीका है, लेकिन मैं अनिश्चित हूं, शायद एमएसवीसी टूल चेन से परिचित एमएस से कोई व्यक्ति इसमें शामिल हो सकता है।

दुर्भाग्य से जीवन और अन्य परियोजनाओं ने मुझे इसके लिए अधिक समय देने के रास्ते में बहुत भारी पड़ गया है, लेकिन मैं आने वाले हफ्तों में इस पर कुछ समय बिताने की कोशिश करूंगा।

@manbearian यह मुद्दा

@kesmit13 और @mxplusb

इस

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

@ccamplin नवीनतम कोड है जो काम करता है।

कोड के साथ मेरी वर्तमान चिंता, कि यह स्पष्ट नहीं है कि इसका उपयोग कैसे किया जाए। आप क्या आदेश चलाते हैं? मेरे परिवेश को कैसे सेटअप करने की आवश्यकता है?

मुझे लगता है कि अगला कदम किसी के लिए उस कोड को आज़माना और उसका उपयोग करना है, और देखें कि क्या वे वास्तव में इसका उपयोग कर सकते हैं। यदि यह काम करता है, तो चरणों को प्रलेखित करने की आवश्यकता है, ताकि अन्य लोग भी कोड का उपयोग कर सकें। शायद यह बहुत जटिल है, या काम नहीं करता है। हमें तदनुसार कोड को समायोजित करने की आवश्यकता है।

एक बार जब हम कोड की वर्तमान स्थिति से खुश हो जाते हैं, तो हमें इसे मास्टर पर रीबेस करना चाहिए। वहाँ कई अलग-अलग फ़ाइलों को समायोजित किया गया है, इसलिए इसे रीबेस करना आसान नहीं होगा। हो सकता है कि हम कम परिवर्तन करने के लिए परिवर्तन को समायोजित कर सकें, इसलिए इसे पुन: आधार बनाना आसान है।

एलेक्स

@mxplusb @ kesmit13 वर्तमान कार्यान्वयन को मास्टर के विरुद्ध पुन: आधारित किया गया है और इसे यहां पाया जा सकता है: https://go-review.googlesource.com/c/go/+/133946/6

@alexbrainman

कोड के साथ मेरी वर्तमान चिंता, कि यह स्पष्ट नहीं है कि इसका उपयोग कैसे किया जाए। आप क्या आदेश चलाते हैं? मेरे परिवेश को कैसे सेटअप करने की आवश्यकता है?

मैं सहमत हूं कि इसका उपयोग करने के तरीके पर दस्तावेज़ीकरण को जोड़ने की आवश्यकता है। मुझे पूरी तरह से यकीन नहीं है कि इसे कहां रखा जाए, अगर आपके पास विचार हैं तो मुझे बताएं। आईडीके अगर इसे एमएसवीसी के माध्यम से निर्माण/चलाने के लिए सीएमडी/गो दस्तावेज के तहत जाना चाहिए, या यदि इसे सीजीओ दस्तावेज के तहत रहना चाहिए, या शायद कहीं और पूरी तरह से?

बहुत सारे परीक्षण gcc का उपयोग नहीं करते हैं। यह लोगों/कंप्यूटर के समय की बर्बादी है जब बिना किसी कारण के पैकेज परीक्षण दो बार चलते हैं। जैसा कि आप #20982 से देख सकते हैं (टिप्पणी) संग्रह/ज़िप पैकेज परीक्षण दो बार चलाए गए थे - मुझे दूसरे रन की आवश्यकता नहीं दिख रही है।

मुझे यकीन नहीं है कि इसे कैसे व्यवस्थित किया जाए, लेकिन हो सकता है कि आपको MSVC बिल्ड का परीक्षण करने के लिए आवश्यक परीक्षणों का चयन करने के लिए run.bat में गो टूल डिस्ट टेस्ट की अपनी कॉल को प्रतिस्थापित करना चाहिए। उदाहरण के लिए, देखें कि आप केवल कुछ विशिष्ट परीक्षणों का चयन कैसे कर सकते हैं। @bradfitz शायद हम कुछ ध्वज या पर्यावरण चर बना सकते हैं जो

परिवर्तन में पहले से ही एक पर्यावरण चर शामिल है जो यह बताता है कि हम एमएसवीसी चीजें "GO_TEST_TESTINGMSVC" कर रहे हैं, मुझे विश्वास है। मैं इस बारे में निश्चित नहीं हूं कि हम उन चीजों के लिए परीक्षणों को कैसे फ़िल्टर करेंगे जिन्हें केवल एमएसवीसी प्रभावित कर सकता है यदि हम दो बार सभी परीक्षण नहीं चला रहे हैं। संभावित रूप से इसे केवल सीजीओ से संबंधित परीक्षणों तक सीमित कर दिया गया है, लेकिन मेरा मानना ​​​​है कि सभी जगह सीजीओ परीक्षण हैं और मुझे नहीं पता कि डिस्ट में उनको फ़िल्टर करने के लिए कोई तंत्र है या नहीं?

मुझे पूरी तरह से यकीन नहीं है कि इसे कहां रखा जाए, अगर आपके पास विचार हैं तो मुझे बताएं।

मुझे लगता है कि किसी भी दस्तावेज को अद्यतन करने से पहले, आपको केवल एमएसवीसी के साथ सीजीओ कोड बनाने का वर्णन करना चाहिए। @mxplusb और @ kesmit13 के लिए ताकि वे आपके परिवर्तनों को आज़मा सकें।

उदाहरण के लिए, सीजीओ कोड बनाने के लिए जीसीसी का उपयोग करने के लिए, I

1. gcc.exe शामिल करने के लिए मेरा% PATH% समायोजित करें
2. %GOROOT%\src निर्देशिका से make.bat चलाकर पहले जाएं का निर्माण करें
3. मानक go build और go install कमांड का उपयोग करें

मैं एमएसवीसी के साथ ऐसा कैसे करूं?

मैं इस बारे में निश्चित नहीं हूं कि हम उन चीजों के लिए परीक्षणों को कैसे फ़िल्टर करेंगे जिन्हें केवल एमएसवीसी प्रभावित कर सकता है यदि हम दो बार सभी परीक्षण नहीं चला रहे हैं। संभावित रूप से इसे केवल सीजीओ से संबंधित परीक्षणों तक सीमित कर दिया गया है, लेकिन मेरा मानना ​​​​है कि सभी जगह सीजीओ परीक्षण हैं और मुझे नहीं पता कि डिस्ट में उनको फ़िल्टर करने के लिए कोई तंत्र है या नहीं?

मैं %GOROOT%\misc\cgo निर्देशिका से शुरू करूंगा। आप वहां जो भी स्रोत बना सकते हैं, आपको उसका निर्माण करना चाहिए। इससे ऊपर कुछ भी आप पर निर्भर है।

एलेक्स

@ccamplin इस पर देरी के लिए खेद है, मैं इस सप्ताह इसका परीक्षण करने की पूरी कोशिश करूंगा और आपको

नमस्ते, दोस्तों पार्टी में देर से आने के लिए खेद है... मैं कोशिश कर सकता हूं और एमएसवीसी कार्यक्षमता के बारे में सवालों के जवाब दे सकता हूं या आपको उन लोगों तक पहुंचा सकता हूं जो कर सकते हैं। मैंने बातचीत को पढ़ा, लेकिन दुर्भाग्य से, मैं जीसीसी की आवश्यक कार्यक्षमता को समझने के लिए पर्याप्त रूप से परिचित नहीं हूं जो एमएसवीसी से गायब हो भी सकती है और नहीं भी।

हाय दोस्तों,
क्या यह सुविधा गो 1.14 में जारी की गई है?
यदि जारी किया जाता है तो कृपया इसका उपयोग करने के लिए कोई भी उपलब्ध दस्तावेज साझा करें।
यदि अभी तक रिलीज़ नहीं हुई है, तो क्या कोई विचार है कि इसे कब रिलीज़ किया जाएगा?
MSVC के समर्थन का बेसब्री से इंतजार है।
अग्रिम में धन्यवाद :)

नमस्ते, किसी ने भी अधिक जानकारी के लिए मेरे अनुरोध का जवाब कभी नहीं दिया, इसलिए मुझे यकीन नहीं है कि क्या आवश्यक है। क्या कोई मुझे कृपया भर सकता है?

दुर्भाग्य से, मुझे नहीं पता कि कोई इस मुद्दे पर सक्रिय रूप से काम कर रहा है या नहीं।

नमस्ते, अधिक जानकारी के लिए मेरे अनुरोध का कभी किसी ने जवाब नहीं दिया,...

नमस्ते @manbearian

वह कौन सा अनुरोध है? आपको किस जानकारी की ज़रूरत है?

एलेक्स

मुझे पहले इस थ्रेड में जानकारी के लिए टैग किया गया था, लेकिन मुझे नहीं पता कि लोग क्या ढूंढ रहे हैं और मदद करने में असमर्थ रहे हैं। अगर कोई मदद की जरूरत नहीं है, तो बहुत अच्छा है। बस कृपया मुझे बताएं।

बस कृपया मुझे बताएं।

@मनबेरियन

आपके प्रस्ताव के लिए धन्यवाद। मुझे नहीं पता कि आपको किसने टैग किया है। अगर उन्हें फिर भी मदद की ज़रूरत होगी, तो वे आपको फिर से टैग करेंगे.

एलेक्स

यदि अभी तक रिलीज़ नहीं हुई है, तो क्या कोई विचार है कि इसे कब रिलीज़ किया जाएगा?
MSVC के समर्थन का बेसब्री से इंतजार है।

@dinesherode91

कोड वहां है और पूरा हो गया है; मेरा मानना ​​​​है कि वास्तव में इसे वापस रखने वाली एकमात्र चीज है जो लोग परिवर्तनों का परीक्षण कर रहे हैं और प्रतिक्रिया प्रदान कर रहे हैं ताकि उनकी उचित समीक्षा और अनुमोदन किया जा सके। हालांकि मैं वर्तमान मास्टर के शीर्ष पर परिवर्तनों को दोबारा करने में संकोच कर रहा हूं। मैंने इसे 5-6 बार किया है और इसमें बहुत समय लगता है, और फिर मुझे कोई परीक्षण/प्रतिक्रिया नहीं मिलती है। जब तक अतिरिक्त पक्ष इसके परीक्षण में भाग लेने के लिए तैयार नहीं होते, तब तक समस्या पानी में मृत हो सकती है।

जब तक अतिरिक्त पक्ष इसके परीक्षण में भाग लेने के लिए तैयार नहीं होते, तब तक समस्या पानी में मृत हो सकती है।

@ccamplin आपके परिवर्तनों का परीक्षण/डीबगिंग करने के लिए मुझ पर भरोसा करता है। मुझे टूलचेन जाने का अनुभव नहीं है, लेकिन मैंने आपके कमिट की समीक्षा की है और वे बहुत अच्छी तरह से संरचित और प्रलेखित प्रतीत होते हैं।

@ccamplin यह सुनकर बहुत अच्छा लगा कि कार्यान्वयन भाग पूरा हो गया है।
मुझे परीक्षण भाग में शामिल होने में दिलचस्पी है, लेकिन मैं गोलांग में एक नौसिखिया हूं और विंडोज़ एपिस में भी एक अच्छा शिक्षार्थी हूं (कुछ हफ्ते पहले शुरू हुआ)। मैं एमएस सी ++ में विंडोज एपीआई के साथ काम करने की योजना बना रहा था क्योंकि ऐसा लगता है कि इसके लिए बहुत से आधिकारिक संसाधन उपलब्ध हैं। लेकिन फिर मैंने एक ऐसी भाषा (अपने सिस्टम प्रोग्रामिंग के लिए) की तलाश शुरू की, जहां मैं इसे अपने मल्टी प्लेटफॉर्म सिस्टम प्रोग्रामिंग के लिए इस्तेमाल कर सकूं और मैं GoLang से प्रभावित हूं। मेरी ओर से योगदान के लिए हमेशा तैयार और मार्गदर्शन की बहुत जरूरत है।

@ccamplin अगर आप रिबेस करते हैं तो मैं इसके ऊपर निर्माण करने की कोशिश करूंगा। मैं काम पर अपनी कुछ परियोजनाओं से mingw64 आवश्यकता को छोड़ना पसंद करूंगा। मेरी बिल्ड टूलिंग MSVC के लिए पूरी तरह से स्थापित है, इसलिए मुझे आपके पैच का उपयोग करने के अलावा और कुछ नहीं करना होगा।

@ccamplin भी, मैंने आपके

@ericlagergren

@ccamplin भी, मैंने आपके

सुनिश्चित नहीं है कि अगर मैं समझता हूं, तो https://go-review.googlesource.com/c/go/+/133946/6 पर कई संबंधित कमिट सीधे कुछ क्षमता में गो के सीजीओ हिस्से को छूते हैं।

@ccahoon ठीक है, मैंने उन्हें याद किया होगा। अगर cgo टूल को अपडेट नहीं किया गया होता तो मैं ऐसा करने की पेशकश करने जा रहा था।

@ericlagergren

मैं काम पर अपनी कुछ परियोजनाओं से mingw64 आवश्यकता को छोड़ना पसंद करूंगा

सिर्फ आपकी जानकारी के लिए। NS

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

परिवर्तन को अभी भी काम करने के लिए मिंगव की जरूरत है। @ccamplin परिवर्तन का उपयोग करने के लिए आपको Mingw और MSVC दोनों टूल इंस्टॉल करने

एलेक्स

@ccamplin ,

@alexbrainman मैं कि शानदार होगा। लेकिन जैसे @cglong ने कहा, मुझे यकीन नहीं है कि इसके लिए mingw64 की भी आवश्यकता क्यों होगी।

@ericlagergren @cglong CGO को उस सी कोड के बारे में जानकारी उपलब्ध कराने और उपलब्ध कराने की आवश्यकता है जिसके साथ इसे संकलित किया जा रहा है। GCC में एक फ़्लैग होता है जो आसानी से पार्स करने योग्य प्रारूप में प्रकार के डेटा को आउटपुट करेगा। जहाँ तक मुझे पता है MSVC में समान जानकारी प्रदान करने की कार्यक्षमता नहीं है। टूलिंग इन गो में न केवल लेक्स/पार्स सी और सी ++ कोड के लिए कोड की आवश्यकता होगी बल्कि प्री-प्रोसेसर निर्देशों को समझने और मूल्यांकन करने की भी आवश्यकता होगी। गो में इस तरह का निर्माण करना काफी बड़ा उपक्रम होगा। शायद एक पुस्तकालय पहले से ही कहीं उपलब्ध है, हालांकि हम यह पता लगा सकते हैं कि इसे कैसे अपनाया जाए?

@ccamplin गोचा , मैंने यही पाया। मैं तीसरे पक्ष के पुस्तकालयों जैसे libclang और cznic/cc के बारे में जानता हूं। लेकिन दुर्भाग्य से libclang विशाल है और cznic/cc का परीक्षण Windows या macOS पर नहीं किया गया है। क्या पीडीबी पर्याप्त जानकारी प्रदान नहीं करता है?

सीजीओ को जिस सी कोड के साथ संकलित किया जा रहा है उसके बारे में जानकारी इकट्ठा करने और उपलब्ध होने की जरूरत है। GCC में एक फ़्लैग होता है जो आसानी से पार्स करने योग्य प्रारूप में प्रकार के डेटा को आउटपुट करेगा। जहाँ तक मुझे पता है MSVC में समान जानकारी प्रदान करने की कार्यक्षमता नहीं है।

शायद @manbearian यहां कुछ संकेत प्रदान करने में सक्षम हो सकता है?

मैं यह नहीं कहूंगा कि जीसीसी एक विशेष प्रारूप में आउटपुट प्रकार डेटा उत्सर्जित करता है। यह डिबगर्स के लिए लक्षित DWARF डिबगिंग डेटा का उत्सर्जन करता है, और cgo डीबग/बौना पैकेज का उपयोग करके उस डेटा को पढ़ता है। MSVC में संभवतः एक डिबग प्रारूप भी है। यदि वह प्रारूप कहीं भी प्रलेखित है, तो हम इसे सीजीओ का उपयोग करके पढ़ सकते हैं जैसे हम डीडब्ल्यूएआरएफ डेटा करते हैं।

@ianlancetaylor MSVC PDB फ़ाइलों का उत्सर्जन कर सकता है। देखें https://github.com/Microsoft/microsoft-pdb

एफडब्ल्यूआईडब्ल्यू, एमएसवीसी के डिबग आउटपुट को पढ़ना वह है जिसके बारे में मैं बात कर रहा था जब मैंने https://github.com/golang/go/issues/20982#issuecomment -648462003 में cgo टूल का उल्लेख किया था।

मैं यह नहीं कहूंगा कि जीसीसी एक विशेष प्रारूप में आउटपुट प्रकार डेटा उत्सर्जित करता है। यह डिबगर्स के लिए लक्षित DWARF डिबगिंग डेटा का उत्सर्जन करता है, और cgo डीबग/बौना पैकेज का उपयोग करके उस डेटा को पढ़ता है। MSVC में संभवतः एक डिबग प्रारूप भी है। यदि वह प्रारूप कहीं भी प्रलेखित है, तो हम इसे सीजीओ का उपयोग करके पढ़ सकते हैं जैसे हम डीडब्ल्यूएआरएफ डेटा करते हैं।

@ericlagergren @ianlancetaylor
इसलिए हमें DWARF डेटा की जरूरत है, जो इसका एक बड़ा हिस्सा है। हालाँकि, हम सैद्धांतिक रूप से वही जानकारी पीडीबी डेटा से प्राप्त कर सकते हैं।

हालाँकि, मैं विशेष रूप से जिस DWARF डेटा का उल्लेख कर रहा था, वह केवल GCC द्वारा उत्पादित DWARF डेटा नहीं था, बल्कि gcc -E -dM का आउटपुट था, जो प्रीप्रोसेसिंग के बाद सभी # डिफाइन को आउटपुट करता है। यह संभव है कि पीडीबी स्वयं ही वही जानकारी प्रदान कर सके ... मुझे संदेह है कि हम एमएसवीसी को किसी भी क्षमता में डीबग जानकारी/प्रकार की जानकारी डंप करने में सक्षम होंगे या नहीं, वास्तव में इसे संकलित करने की आवश्यकता के बिना कोड। अभी सीजीओ जीसीसी के साथ ऐसा ही कर रहा है।

स्मृति से, /EP /d1PP -E -dM के समान कुछ उत्सर्जित करना चाहिए।

स्मृति से, /EP /d1PP -E -dM के समान कुछ उत्सर्जित करना चाहिए।

यदि ऐसा है तो यह उत्कृष्ट होगा, मुझे लगता है कि/d1PP एक अनियंत्रित ध्वज है? मैंने इसे पहले कभी नहीं देखा। वह समय से पहले समान प्रकार की जानकारी प्राप्त करना छोड़ देगा।

@ccamplin हाँ, यह

क्या कोई मुझे एमएसवीसी-समर्थन की वर्तमान स्थिति का संक्षिप्त सारांश दे सकता है? मुझे यह सब निम्न-स्तर-संकलक-सामान बहुत समझ में नहीं आता है। यह सिर्फ इतना है कि मेरे पास एक गो लाइब्रेरी है जिसे मैं सी #/यूडब्ल्यूपी से उपयोग करना चाहता हूं - और वह पहले से ही गो बिल्ड और बिल्डमोड सी-साझा के साथ काम कर रहा है। लेकिन: उस ऐप को कभी भी विंडोज स्टोर द्वारा स्वीकार नहीं किया जाएगा क्योंकि जेनरेट डीएलएल जाने से कुछ कंपाइलर/लिंकर-फ्लैग याद आती है (मुझे लगता है) केवल एमएसवीसी-टूलचैन द्वारा सेट किया जा सकता है।

तो: मैं यहां इसका परीक्षण कैसे कर सकता हूं? किसी भी सलाह की सराहना की जाती है! शुक्रिया!

वह ऐप कभी भी विंडोज़ स्टोर द्वारा स्वीकार नहीं किया जाएगा क्योंकि जेनरेट डीएलएल जाने से कुछ कंपाइलर/लिंकर-फ्लैग याद आती है (मुझे लगता है) केवल एमएसवीसी-टूलचैन द्वारा सेट किया जा सकता है।

@TopperDEL क्या विंडोज स्टोर आपको बताता है कि कौन से कंपाइलर झंडे गायब हैं? यदि mingw-64 उनका समर्थन करता है तो आप डीएलएल बनाते समय हमेशा सही झंडे के साथ -extldflags का उपयोग कर सकते हैं।

@qmuntal हाँ, वे करते हैं:
"जब आप ऐप को लिंक करते हैं तो आवश्यक लिंकर विकल्प - SAFESEH, DYNAMICBASE, NXCOMPAT, और APPCONTAINER - लागू करें।"

मैंने पहले ही कोशिश कर ली है
go build -ldflags="-s -w '-extldflags=-Wl,--dynamicbase,--high-entropy-va'" -o storj_uplink.dll -buildmode c-shared

लेकिन इससे स्टोर-सबमिशन के संबंध में कुछ भी नहीं बदला। और मेरी समझ से कम से कम सुरक्षित एक एमएसवीसी-विशिष्ट-चीज है, है ना?

"जब आप ऐप को लिंक करते हैं तो आवश्यक लिंकर विकल्प - SAFESEH, DYNAMICBASE, NXCOMPAT, और APPCONTAINER - लागू करें।"

मुझे सुरक्षित करने का कोई आसान तरीका नहीं पता है और न ही APPCONTAINER Mingw-w64 में झंडे, शायद यह प्रोजेक्ट https://github.com/status-im/mingw-windows10-uwp आपको कुछ मार्गदर्शन दे सकता है।

दूसरी ओर DYNAMICBASE और NXCOMPAT को डिफ़ॉल्ट रूप से 1.16 (# 41421 देखें) में सक्षम किया जाएगा, लेकिन जैसा कि उल्लेख किया गया है, पहले से ही -extldflags साथ उपयोग किया जा सकता है, वास्तव में मैं कुछ परियोजनाओं के लिए ऐसा कर रहा हूं।

@qmuntal धन्यवाद! तो कम से कम ऊपर मेरे extldflags सही होना चाहिए?
मैं विंडोज़ 10-यूडब्ल्यूपी के लिए मिंगव पर एक नज़र डालूंगा।