Go: cmd / link: دعم ملفات كائن msvc

@ ccalexbrainman

xoviat ما هي المشكلة التي تواجهها؟ أحتاج أن أكون قادرًا على إعادة إنتاجه هنا. لذا ، يُرجى تقديم جميع الخطوات التي سأحتاج إلى اتباعها لإعادة إنتاج هذا.

شكرا لك

اليكس

ملاحظة: لن أمتلك جهاز كمبيوتر حتى نهاية يوليو. سوف ألقي نظرة على هذا بعد ذلك.

ما هي المشكلة التي تواجهها

لم أجربها بعد ، لكني أرغب في استدعاء وظائف c على وجه التحديد في ملفات كائن msvc عن طريق ربطها كـ .syso مع رابط go. كل ما قرأته يشير إلى أن هذا غير ممكن ولكنني سأقوم بإنشاء إجراء لإعادة إنتاج الخطأ المحدد الذي يحدث.

قم باستدعاء وظائف c تحديدًا في ملفات كائن msvc عن طريق ربطها كـ syso مع go linker

هل حاولت بناء هذه في DLL ، واستخدامها من داخل DLL؟

سوف أقوم بإنشاء إجراء لإعادة إنتاج الخطأ المحدد الذي يحدث.

افعل من فضلك. شكرا لك.

اليكس

هل حاولت بناء هذه في DLL ، واستخدامها من داخل DLL؟

كانت هذه في الواقع خطتي الأصلية. أنا أستخدم swig لذا ليس من الملائم تجميع كود c الذي تم إنشاؤه بشكل منفصل ثم إعادة كتابة الوظائف مثل تصدير DLL. هذا ليس بالأمر الصعب ، لكنه مزعج عندما يكون سير العمل مع دول مجلس التعاون الخليجي go generate; go build .

حسنًا ، لدي إجراء. ابدأ بهذه الملفات:

hello.go:

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

ليس لدي أمر cl مثبتًا على جهاز الكمبيوتر الخاص بي. كيف أقوم بتثبيت msvc؟

شكرا لك.

اليكس

أنت بحاجة إلى "أدوات البناء 2017" هنا . تسمح Microsoft الآن لأي شخص باستخدام الاستوديو المرئي مجانًا طالما أنه ليس للتطوير التجاري. إذا كان هناك الكثير من المتاعب ، يمكنني فقط أن أعطيك ملف الكائن إذا كنت تريد.

إذا لم يكن c ++ فقط شيئًا ، فلا داعي للقلق بشأن هذا. لكنها كذلك ، لذلك يستمر الألم ...

أنت بحاجة إلى "أدوات البناء 2017" هنا.

فهمتك. شكرا لك.

إذا كان هناك الكثير من المتاعب ، يمكنني فقط أن أعطيك ملف الكائن إذا كنت تريد.

نعم ، من فضلك ، انشر hello.obj في مكان ما.

التفكير في هذا أكثر. إنك تستخدم بالفعل gcc لربط ملف كائن تم تجميعه مع مترجم msvc. هل يمكنك أن تجرب وتمرينك ، لكن مع استبدال خطوة "go build" بربط hello.obj ببرنامج C في مجلس التعاون الخليجي؟ ربما تم القيام به من قبل. أظن ، إذا عرفنا كيفية القيام بذلك ، فقد نتمكن من فعل الشيء نفسه مع Go.

اليكس

يدعم AFAIK lld https://github.com/llvm-mirror/lld ملفات كائن msvc.

ملف الكائن موجود هنا: https://github.com/xoviat/msvcgo/blob/master/hello.syso

lld https://github.com/llvm-mirror/lld يدعم ملفات كائن msvc

Go يستخدم gcc linker (وليس lld) على نظام التشغيل Windows.

ملف الكائن موجود هنا: https://github.com/xoviat/msvcgo/blob/master/hello.syso

سأحاول عندما أعود إلى المنزل في أغسطس. اشكرك.

اليكس

Go يستخدم gcc linker (وليس lld) على نظام التشغيل Windows.

أنا أعرف. لكن lld هو أفضل توثيق مفتوح المصدر لتنسيق كائن msvc.

لقد حصلت بالفعل على نفس الخطأ من ld لذا فإن الخطأ يأتي بالتأكيد من ld.

لقد حصلت بالفعل على نفس الخطأ من ld لذا فإن الخطأ يأتي بالتأكيد من ld.

نعم فعلا. نحن بحاجة إلى معرفة كيفية بناء برنامج C من خلال تجميع الجزء باستخدام msvc والربط مع gcc.

اليكس

اغفر جهلي ، ولكن ما الرابط الخليجي بالضبط؟ هل هو ربط إخراج رابط الذهاب؟

تشغيل objconv على ملفات الكائن لتحويلها إلى elf:

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 خارج الحدود؟

اغفر جهلي ، ولكن ما الرابط الخليجي بالضبط؟ هل هو ربط إخراج رابط الذهاب؟

تستخدم برنامجين لإنشاء برنامج Go الخاص بك:

• يحول المترجم ملفات .go (حزمة واحدة في ذلك الوقت) إلى ملف كائن مخزّن ضمن دليل٪ GOPATH٪ / pkg ؛
• linker الذي ينشئ ملف exe نهائيًا من ملفات الكائن ضمن٪ GOPATH٪ / pkg.

في بعض الأحيان (عندما تستخدم إحدى الحزم الخاصة بك Cgo) ، يقوم رابط Go باستدعاء الرابط الخارجي للعثور على جميع البتات التي تم تنفيذها في C. تخيل أنك تستدعي printf من كود C الخاص بك. يجب أن تكون التعليمات البرمجية المترجمة لـ C printf جزءًا من Go القابل للتنفيذ ، لكن Go linker لا تعرف من أين تحصل عليها. لذا Go linker يستدعي الرابط الخارجي لتضمين هذا الرمز.

يستخدم Current Go مترجم / رابط مجلس التعاون الخليجي لتجميع وربط كود C (نستخدم mingw gcc). إذا كنت ستقوم بترجمة كود C الخاص بك باستخدام مترجم مختلف (بواسطة Microsoft) ، فسيتعين عليك استخدام رابط المراسل (بواسطة Microsoft) للعثور على جميع رموز C الخارجية التي أنشأها المترجم.

لذا أعتقد أنني كنت مخطئًا بشأن اقتراح استخدام رابط gcc. بالنسبة للسيناريو العام ، يجب عليك استخدام كل من مترجم Microsoft و linker. سيتعين علينا معرفة ما يتطلبه رابط Microsoft كمدخلات ومطابقة ذلك.

قد تفلت بدون رابط MC ، إذا لم يكن كود C الخاص بك يحتوي على أي كود خارجي. يرجى تجربة برنامج C بسيط جدًا (مثل البرنامج الذي يضيف عددين صحيحين أو شيء من هذا القبيل). قد يعمل هذا فقط كما وصفت أعلاه.

اليكس

ربما stdio خارج الحدود؟

أظن أنك بحاجة إلى الاتصال بـ Microsoft linker للعثور على هذا الرمز.

اليكس

أنا لا أتأكد ولكن

objconv -felf hello.obj hello.syso

ربما ، يجب أن تحاول أن تفعل coff أو omf بدلاً من elf؟

ربما ، يجب أن تحاول أن تفعل coff أو omf بدلاً من elf؟

xoviat نعم ، لا يجب تحويل ملفات .obj إلى elf ، حيث يقوم إصدار Windows من مجلس التعاون الخليجي بإنشاء ملفات pe / coff تمامًا مثل أي مترجم Windows آخر.

اليكس

يستدعي رابط Go الرابط الخارجي للعثور على جميع وحدات البت التي تم تنفيذها في C.

ما هو الأمر المحدد المستخدم؟ إذا كنت أعرف أمر mingw ، فربما يمكنني المضي قدمًا في مسار مقارنة الملفات لمحاولة الحصول على msvc لمطابقة ما يقوم mingw بإخراجه.

يمكنك مشاهدة التعليق بالضبط عن طريق تشغيل go build -ldflags=-v .

حسنًا ، مما يمكنني قوله:

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

يبدو أن Go لإنشاء دليل مؤقت بهذه الملفات. هل هناك طريقة للاحتفاظ بالدليل المؤقت حتى أتمكن من فحص محتوياته؟

جرب go build -work

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

ملفات الكائن المتبقية في هذا الدليل.

لن يحافظ الخيار -work الواقع على الملفات المؤقتة التي ينشئها الرابط. في الوقت الحالي ، عليك فقط تحرير مصادر الرابط لعدم إزالة الدليل. ربما ينبغي أن نضيف خيارًا لذلك ، بطريقة أو بأخرى.

في الوقت الحالي ، عليك فقط تحرير مصادر الرابط لعدم إزالة الدليل.

إذا كنت لا تمانع ، فسأنتظر حتى يتم تنفيذ ذلك في HEAD حتى لا أضطر إلى القيام بعمل متكرر.

هل هناك طريقة للاحتفاظ بالدليل المؤقت حتى أتمكن من فحص محتوياته؟

يحتوي برنامج cmd / link على علم -tmpdir لذلك. يمكنك استخدامه على النحو التالي:

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

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

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

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

import "fmt"
import "C"

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

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

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

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

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

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

اليكس

هذا فقط للإشارة الخاصة بي ، ولكن هذا يحتاج إلى النقل إلى msvc:

_cgo_sys_thread_start(ThreadStart *ts)
{
    uintptr_t thandle;

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

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

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

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

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

    crosscall_amd64(ts.fn);
}

لن أستخف بالوقت الذي سأستغرقه لإكمال هذه المهمة لأنني لست على دراية بالتجميع على الإطلاق.

• [x] فهم ما يفعله التجمع
• [x] منفذ لتجميع MSVC
• [x] فهم _beginthread مقابل CreateThread
• [x] قم بالتبديل إلى CreateThread

أيضًا ، رموز غير محددة:

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

حسنًا ، التحرك هنا أسرع من المتوقع!

الكل: هل تم تجميع

يبدو أن دول مجلس التعاون الخليجي لن تقوم بتجميعه ، مما يعني أنه من المحتمل أن يتم تجميعه. وبعد ذلك يصبح السؤال: كيفية تجميعه باستخدام أداة التجميع go في كائن.

الهدف من ذلك هو تجميع وقت التشغيل / cgo / asm_amd64.s في كائن Go ، ثم يقوم cmd / link بربطه مع جميع كائنات Go الأخرى في كائن نظام واحد ، ثم يقوم رابط النظام بربط كائنات النظام الفردية بالإضافة إلى كل تبعيات cgo في البرنامج النهائي.

هل هناك طريقة لتجميع هذا الكائن في الوقت الحالي لأغراض الاختبار؟ مثل gcc -c asm_amd64.s إلا مع الذهاب؟

الهدف من ذلك هو تجميع وقت التشغيل / cgo / asm_amd64.s في كائن Go ، ثم يقوم cmd / link بربطه مع جميع كائنات Go الأخرى في كائن نظام واحد ، ثم يقوم رابط النظام بربط كائنات النظام الفردية بالإضافة إلى كل تبعيات cgo في البرنامج النهائي.

حتى الآن وجدت هذه الأشياء:

• go.o: من الواضح أنه من سلسلة أدوات go
• _cgo_.o : تم إنشاؤه بواسطة دول مجلس التعاون الخليجي ، غير قابل للاستخدام
• 000000.o: مولدة من دول مجلس التعاون الخليجي ، غير صالحة للاستعمال
• 000001.o: تحديث: تم إنشاؤه بالفعل بواسطة go linker ، ولكنه يحتوي على رموز دول مجلس التعاون الخليجي. غير صالح للإستعمال.

go.o هو أكبر كائن.

تضمين التغريدة

لا أعتقد أن ما قلته صحيح. crosscall_amd64 موجود في 000001.o ، لكن هذا الملف لا يحتوي على "كل كود go":

000001.o:     file format pe-x86-64

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

من الواضح أن هذا الملف تم إنشاؤه من قبل دول مجلس التعاون الخليجي ، والذي فات الأوان في العملية.

هل هناك طريقة لتجميع هذا الكائن في الوقت الحالي لأغراض الاختبار؟ مثل gcc -c asm_amd64.s ماعدا go؟

asm_amd64.s جزء من حزمة وقت التشغيل. يمكنك معرفة كيفية استخدام الأمر "go build" لملف asm_amd64.s ، مثل:

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

اليكس

شكرا.

تم تعريف الرمز crosscall_amd64 في ملف runtime / cgo / gcc_amd64.s. يتم تجميع هذا الملف بواسطة GCC (مثل جميع ملفات runtime / cgo / gcc_ *). لذلك لا يتم دمجه في ملف go.o الفردي الذي يحتوي على كل كود Go. الملف الذي كنا نتحدث عنه من قبل ، runtime / cgo / asm_amd64.s ، يحدد الرمز crosscall2 . ستجد هذا الرمز في go.o.

شكرا.

حسنًا ، لقد تمكنت من ربط ملف تنفيذي يتعطل عند انتهاك الوصول أثناء وجوده
go.runtime.rt0_go + 5F -> اذهب .___ acrt_stdio_initializer.

هذا كل الوقت لدي الآن ؛ سأعود إلى هذا لاحقًا.

alexbrainman هذا صحيح.

alexbrainman ، ستحتاج إلى MSVC للمتابعة. اسمحوا لي أن أعرف ما إذا كنت بحاجة إلى مساعدة في هذا.

ستحتاج MSVC للمتابعة.

أقوم بتثبيت هذا https://www.visualstudio.com/downloads/#build -tools-for-visual-studio-2017

ماذا علي أن أفعل بمجرد التثبيت؟

اليكس

بمجرد تثبيت ذلك ، ستحتاج إلى إنشاء "libgo" ، وهي مكتبة go. انسخ الملفات التالية من مجلد cgo :

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

نحتاج إلى ضبط gcc_windows_amd64.c ليكون متوافقًا مع MSVC. قم بتعديل الوظيفة كما يلي:

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

تسمى "hello.go"

قم بإعداد برنامج نصي بوويرشيل ينسخ الملفات باستمرار من $ 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 -link / DEBUG: FULL

يؤدي ذلك إلى إنشاء ملف go.exe القابل للتنفيذ ، لكنه لا يعمل. لا أرى أي كود ASM معقول هناك. التعليمات الأولى تقفز إلى اللامكان. إنها مجرد فوضى.

ربما يجب أن تبدأ بشيء حقيقي بسيط. اكتب ملف asm (Go asm file) بوظيفة asm واحدة تنفذ "INT $ 3" ​​ولا تحتوي على أي شيء آخر. وحاول إنشاء برنامج قابل للتنفيذ منه - يجب أن يقوم البرنامج بتشغيل وظيفتك في البداية.

ربما قم ببنائه باستخدام أدوات Go أولاً (وأيضًا باستخدام gcc إذا لزم الأمر) ، ثم حاول القيام بنفس الشيء باستخدام MSVC.

اليكس

أليكس ، شكرًا لك على مساعدتك. وسأعمل على ذلك.

انا ذاهب الى إرفاق هذه اثنين من المواد هنا كمرجع الخاصة. خلاف ذلك ، ليس لدي أي تحديث آخر.

لقد حصلت بالفعل على برنامج go معقد إلى حد ما يعمل فقط باستخدام مكتبة msvc. اتضح أن رابط Vanilla msvc و llvm-lld لم يتعامل بشكل صحيح مع القسم .bss .

بمجرد أن أقوم بتصحيح الرابط يمكن تشغيل البرنامج.

لسوء الحظ ، ينكسر go build عندما يولد _cgo_.o / _all.o . هل من الممكن إلقاء بعض الضوء على الأسباب المنطقية وراء إنشاء هذين الملفين في cgo؟

يمكنك تشغيل go tool cgo لتشغيل 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

من الناحية المثالية ، سنكتب برنامج go الذي يعالج ملفات الكائن مسبقًا بحيث تكون متوافقة مع link.exe للحد الأدنى من الاحتكاك ، ولكن هذا نوع من الهدف الممتد.

شكرًا للمؤشر - سأقوم بتدوين العملية قريبًا.

لسوء الحظ ، لا أعتقد أنه يمكن إجراء الربط عبر link.exe ما لم نغير دول مجلس التعاون الخليجي لإرسال بيانات غير مهيأة في قسم .data بدلاً من قسم .bss - لكن يمكننا ذلك بالتأكيد إصلاح llvm-lld للتعرف على قسم .bss (وهو ما فعلته).

نحتاج إلى معالجة _cgo_.o و _all.o بشكل منفصل. لدي بعض الأسئلة عنهم:

(1) يبدو أن _cgo_.o ليس الملف القابل للتنفيذ النهائي لأنه لا يحتوي على وقت التشغيل go. يبدو أن المترجم ينظر إلى رموز DWARF لمعرفة تعريف البنية. تكمن المشكلة في أنه من الصعب إنشاء ملف تنفيذي إذا كنت سترتبط بعدد من المكتبات خارجيًا ، خاصة تلك التي تم إنشاؤها بواسطة msvc.

هل من الممكن تجنب هذه الخطوة؟

(2) استخدم الانتقال الحالي GNU ld لربط كل ملفات الكائن في _all.o عبر تمرير -Wl,-r في دول مجلس التعاون الخليجي. هذا يمثل مشكلة لأنه (1) لا يبدو أن رابط آخر لديه هذه الميزة ، و (2) يتأثر الأمر بـ CGO_LDFLAGS . على سبيل المثال ، يُنشئ الأمر التالي نتائج غير صحيحة:

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

يقوم بإنشاء ملف قابل للتنفيذ بدلاً من ملف كائن مجمع.

هل من الممكن تجنب هذه الخطوة على الإطلاق بمجرد وضع كل ملفات الكائن في .a إنشاؤه مباشرة؟

zooba ما هي فرص الحصول على MSFT لتحديث link.exe بهذا التصحيح؟

لسوء الحظ ، لا أعتقد أنه يمكن إجراء الربط عبر link.exe إلا إذا قمنا بتغيير مجلس التعاون الخليجي لإرسال بيانات غير مهيأة في قسم البيانات بدلاً من قسم .bss - ولكن يمكننا بالتأكيد إصلاح llvm-lld للتعرف على قسم .bss (وهو ما فعلته).

لذا ، بافتراض أن MSFT لا تقوم بتحديث link.exe (وهو أمر محتمل) ، سيكون من الجيد تجميع ملفات الكائن باستخدام cl.exe بدلاً من gcc .

يبدو أن _cgo_.o ليس الملف التنفيذي النهائي لأنه لا يحتوي على وقت التشغيل go.

هذا صحيح ، هناك مجموعتان أساسيتان من ملفات الكائنات (على ما أعتقد) يتم ربطهما معًا في النهاية. يحتوي الملف go.o (IIRC) على كود go + وقت التشغيل ، وتحتوي الكائنات الأخرى على كود C. هناك إجراءات تجميع للقفز بين مجموعتي الكائنات.

نحتاج أيضًا إلى clang لتجميع ملفات تجميع Unix.

لأغراضنا ، سيكون -Wl,-r هو نفسه تشغيل lib.exe [object files] /OUT:obj . يعني الخيار "ارتباط متزايد" ، مما يعني "أخذ بعض ملفات الإدخال ، والقيام ببعض الأعمال ، ثم إخراج ملف كائن آخر." إذا لم نقلق بشأن جزء "القيام ببعض الأعمال" في الوقت الحالي ، فيمكننا فقط أن نتعامل مع المطلب على أنه "أخذ بعض ملفات الإدخال و / أو ملفات الكائن وقذف ملف كائن آخر" إلا في حالتنا سيكون ملف الكائن مكتبة.

يمكنك إخبار GCC بتجنب وضع المتغيرات في قسم البيانات بدلاً من قسم .bss باستخدام الخيار -fno-zero-initialized-in-bss .

لاحظ أننا لم نعد نستخدم -Wl,-r عند إنشاء كود cgo.

لا ينبغي أن يكون من الضروري أن يفهم cmd / link ملفات كائن MSVC لاستخدامها كملفات .syso . يتم تمرير هذه الملفات إلى الرابط الخارجي على أي حال. لذلك أعتقد أن المطلوب هنا هو استدعاء رابط MSVC باعتباره الرابط الخارجي ، والذي يجب أن تكون قادرًا على القيام به باستخدام الخيار -extld . إذا كنت تفعل ذلك بالفعل ، أعتذر ؛ في هذه الحالة ، ما هو الفشل؟

إذا كنت تفعل ذلك بالفعل ، أعتذر ؛ في هذه الحالة ، ما هو الفشل؟

IIRC، link.exe barfs على الكائنات التي تم إنشاؤها في دول مجلس التعاون الخليجي.

صحيح ، سيكون عليك أيضًا استخدام مترجم MSVC C ، عن طريق تعيين متغير البيئة CC مناسب. لا أعتقد أنه سينجح في الجمع بين كائنات GCC وكائنات MSVC في رابط واحد.

ولكن بعد ذلك تواجه مشكلة حيث يتم تجميع مكتبات وقت التشغيل C مسبقًا. وإذا حاولت إعادة تجميعها ، فستواجه مشكلة أن cl لا يمكنه تجميع تجميع unix. وهكذا تقوم بنقل أجزاء من مكتبات وقت التشغيل وتحاول ربطها ، وهو ما فعلته وفشلت.

في مكان ما على طول الطريق ، يخطئ cl تكوين جزء أساسي من الكود. فكرتي لإصلاح ذلك هي إخراج رمز MSVC إلى ملف DLL بواجهة برمجة تطبيقات C مسطحة ، ثم تجميع المزيد من مكتبات وقت التشغيل بشكل تدريجي حتى يتوقف عن العمل.

كانت فكرة

ما أوصي به في هذه المرحلة (IMHO) هو تجميع المزيد من مكتبة وقت التشغيل بشكل تدريجي باستخدام cl حتى تتوقف عن العمل أو حتى لا يتبقى لديك رمز خليجي. ثم تعرف بالضبط أين تكمن المشكلة.

ومع التصحيح رابط ، لا حاجة إلى DLL.

يتوفر تصحيح llvm-lld على https://bugs.llvm.org/show_bug.cgi؟

سأقضي بعض الوقت لتقديم مثال.

+ 1haohui شكرًا جزيلاً للمضي قدمًا في هذا الأمر!

haohui ما هو إصدار llvm الذي ينطبق عليه التصحيح الخاص بك؟ هل من تعليمات حول كيفية استخدام التصحيح الخاص بك وكيفية الارتباط بملفات MSVC؟

فيما يتعلق بملفات _cgo_.o و _all.o ، فقد واجهت نفس المشكلة ، لذلك ربما يمكن أن يكون إصلاح هذه المشكلة حلاً للمشكلة الأخرى أيضًا: https://github.com/golang/go / قضايا / 17014

شكرا لكل العمل على هذا. يبدو أنه يتم إحراز تقدم جيد. يتم تجميد الميزات الجديدة حتى Go 1.11 ، وبالتالي تغيير المعلم.

لذلك قفزت إلى هذا الليلة الماضية. من الممكن بناء كل شيء عبر msvc: cl ثم ربط كل شيء من خلال الرابط msvc: link. القضايا ، ومع ذلك ، وفيرة.

إذن بخلاف المشكلات البسيطة مثل msvc: cl لا يدعم C99 بالكامل (في الوقت الحالي لا يمكننا التعامل مع النوع _Complex). هناك المزيد من المشكلات المنهجية المتعلقة بتمشيط أدوات PE libs التي تم إنشاؤها بواسطة go internals وتلك التي تم إنشاؤها بواسطة msvc. على وجه التحديد msvc: الارتباط ينفخ مقاطع .bss (أعتقد أنه قد يرمي هذه البيانات فقط إلى بيانات.) وهي مشكلة نظرًا لأنها تبدو أن مجمّع go SB (ريج زائف) ينتج عن معالجة غير صحيحة إذا تم نقل .bss .

كان تفكيري الأولي هو محاولة جعل المُجمِّع يضع الأشياء التي يمكن أن تدخل في .bss و. noptrbss في .data و. noptrdata على التوالي. لست متأكدًا حتى مما إذا كان هذا ممكنًا ؛ لم يكن العبث به ناجحًا وتم غمر العنونة تمامًا.

لا أعتقد أنه من الممكن استخدام link.exe في الوقت الحالي. أعتقد أننا يجب أن نبدأ بـ lld-link.exe

إذا كان الفكر وراء ذلك هو أنه يمكننا تصحيح الرابط lld حتى لا نتحرك حول بيانات .bss ، فأنا أفهم الاستئناف. من الناحية الواقعية ، إذا كان الهدف هو دعم سلسلة أدوات msvc الفعلية ، فستحتاج إلى معالجة تجميع البيانات الداخلية ووضع البيانات في .bss / .noptrbss من أجل.

ألا يمكننا إعادة توزيع lld-link.exe مع go؟ يبدو أن هذا هو المسار الأقل خطورة لدعم ملفات كائن MSVC طالما لم يتم تمكين LTCG. أدرك أنها ليست مثالية ولكننا نواجه قيودًا على الموارد.

كما أنه يسمح بإحراز تقدم تدريجي وهو أفضل استراتيجية.

حسنًا ، بعض أخبار المتابعة الجيدة ، لقد تمكنت من قضاء ساعة في العمل على هذا على الغداء.

في الوقت الحالي ، لدي مثال من وقت سابق في المشكلة يعمل:

- hello.go:
package main

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

func main() {
    C.hello()
}

- extern.c
#include <stdio.h>

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

>ac.out.exe
Hello World from C

تم إنشاء الثنائي بالكامل باستخدام سلسلة أدوات MSVC و Go (لم يتم تثبيت GCC أو LLVM آخر).

الموجودات:

• كان وجود أدوات Go / link.exe إخراج البيانات .bss للتجميعات الداخلية إلى. البيانات أمرًا بسيطًا إلى حد ما في النهاية
• كان لا بد من تعديل عدة قطع ASM لـ msvc
• تم تلميع عدد قليل من #defs دول مجلس التعاون الخليجي
• كان لابد من إجراء العديد من التعديلات الصغيرة على بعض ملفات cgo التي تم إنشاؤها
• ستحتاج الأرقام المركبة إلى وميضها ، في الوقت الحالي فهي غير مدعومة
• من المحتمل أن تحتاج إلى إضافة علامات إضافية مباشرة لإنشاء أو ارتباط لدعم msvc ، ولن تكون ldflags وما إلى ذلك كافية

الخطوات التالية:
إذا كان لديّ وقت في نهاية هذا الأسبوع ، فسأعمل على إدخال تغييراتي في مفترق طرق ولكن الوظيفة وراء العلامات في الإنشاء / الارتباط. بعد ذلك سأحضر العلاقات العامة للمراجعة حتى نتمكن من تحديد الأنواع. لست واثقًا بنسبة 100٪ من أن نقل بيانات .bss لن يكون له نوع من التأثير في مكان ما.

العيب الوحيد الذي يمكنني التفكير فيه هو أنه سيؤدي إلى تفجير حجم الثنائي ، لكن يجب أن يكون على ما يرام.

تمام!

آسف ، لقد استغرق الأمر يومين إضافيين لتجميع هذا. لذلك يمكن العثور على المسودة الأولى في التصحيح هنا: https://github.com/cchamplin/go/commit/69a5cfc1dd0106fd8a2928a83e4c7001e81e89b8 :: https://github.com/cchamplin/go/tree/msvc_toolchain_support

هذا لا يزال تقريبيًا ولكن لديّ بنجاح إنشاء كود باستخدام msvc.

إذا كان من الرائع أن يبدأ الأشخاص في اختبار هذا الآن وإبلاغ الأخطاء إليّ حتى أتمكن من الحصول عليها في مكان أفضل من المنبع. وأيضًا إذا أراد أي شخص إجراء اختبارات كتابية ، فسيكون ذلك رائعًا!

استعمال:

go build -compiler msvc [path]

• الأرقام المركبة غير مدعومة حاليًا حتى أكتشف ما إذا كان بإمكاننا جعلها تعمل.
• ليس لدي أي فكرة عما يحدث إذا حاولت إنشاء وقت تشغيل go مع مترجم msvc.
• لا تزال هناك حاجة إلى دول مجلس التعاون الخليجي واستخدامها من قبل gco للحصول على تعريفات وكتابة البيانات عند تجميعها ولا يتم استخدامها لبناء أي شيء ). لا أعرف ما إذا كان بإمكاننا الالتفاف حول هذا الأمر ، فليس لدى msvc شيء يمكنه فعل نفس القزم و # تعريف تفريغ التعليمات البرمجية ... إذا كان لدى أي شخص أفكار حول هذا ، فسيكون ذلك رائعًا

يخلق التصحيح المرتبط مشكلة تمهيدية.

alexbrainman كيف وأين يتم تحديد الملفات التي سيتم نسخها إلى pkg/boostrap/src/bootstrap أثناء مرحلة التعزيز toolchain1 ؟

ccalexbrainman

يخلق التصحيح المرتبط مشكلة تمهيدية.

أنا لا أعرف كيف يعمل bootstrapping الآن. لكنني متأكد من أن الآخرين ( rsc وianlancetaylor) يمكنهم المساعدة.

أتساءل كيف يقوم cchamplin بتشغيل make.bat إذا كان التمهيد لا يعمل.

اليكس

xoviat لا أعرف ما هي المشكلة ، لكن قائمة أدلة التمهيد موجودة في cmd / dist / buildtool.go.

مرحبًا alexbrainman ، ianlancetaylor ، xoviat آسف لذلك أعتقد أنه كان يجب علي التحقق بشكل أكثر شمولاً.

لقد قمت بتحديث الفرع هنا https://github.com/cchamplin/go/commit/69a5cfc1dd0106fd8a2928a83e4c7001e81e89b8 مع إصلاح لمشكلة bootstrapping ، وأعتقد أنه يجب التمهيد بشكل صحيح الآن.

كان علي نسخ بعض الدلائل / src / internal / syscall إلى cmd / internal / msvc. هل ستكون مشكلة كبيرة؟ لست متأكدًا من كيفية الوصول إلى التسجيل دون استخدام src / Internal.

كان علي نسخ بعض الدلائل / src / internal / syscall إلى cmd / internal / msvc. هل ستكون مشكلة كبيرة؟ لست متأكدًا من كيفية الوصول إلى التسجيل دون استخدام src / Internal.

لا أعرف كيف يتم ذلك في الوقت الحاضر ، لكنني أظن أن cmd / dist يمكنه فعل ذلك بدون نسخ الملفات المصدر يدويًا. أنا متأكد من أن روس أو إيان سيساعدك عندما تكون مستعدًا لإرسال الكود.

أعتقد أن الوقت قد حان لكي يقررbradfitz و ianlancetaylor كيفية المضي قدمًا هنا. هل نريد Go لدعم أدوات Microsoft build وكذلك دول مجلس التعاون الخليجي؟ سيتعين علينا تثبيت أدوات Microsoft المراسلة على أدوات الإنشاء لدينا (سيتعين علينا القيام بذلك قبل أن نبدأ في قبول CLs). ربما يتعين علينا إدخال متغيرات بيئية جديدة. وثائق جديدة.

إذا كانت الإجابة بنعم ، فسيتعين علىcchamplin إرسال تغييرات الكود الخاصة به وفقًا لـ https://golang.org/doc/contribute.html هل أنت على استعداد للقيام بذلك؟ التغيير كبير جدًا ، لذا يجب تقسيمه إلى CLs أصغر ، حتى يمكن مراجعتها وإرسالها بشكل منفصل. يجب أن يحتوي كل تغيير على all.bat PASS قبل تقديمه. سيكون من الرائع لو تمكنا من رؤية جميع CLs قبل أن نبدأ في تقديم CL الأول.

شكرا لك.

اليكس

هل نريد Go لدعم أدوات Microsoft build وكذلك دول مجلس التعاون الخليجي؟

مجرد ملاحظة ، هذا التصحيح يسهل أيضًا # 17014 الذي لدي بالفعل تصحيح قيد المعالجة له.

إذا كانت الإجابة بنعم ، فسيتعين علىcchamplin إرسال تغييرات الكود الخاصة به وفقًا لـ https://golang.org/doc/contribute.html هل أنت على استعداد للقيام بذلك؟ التغيير كبير جدًا ، لذا يجب تقسيمه إلى CLs أصغر ، حتى يمكن مراجعتها وإرسالها بشكل منفصل.

نعم ، وتقسيمها لا ينبغي أن يكون صفقة ضخمة. أحتاج فقط إلى معرفة ما إذا كان هذا أمرًا من المحتمل أن يتم إدخاله أم لا قبل أن أبذل قصارى جهدي لتنظيف جميع التعليمات البرمجية ، وكتابة الوثائق ، وإنشاء الاختبارات وما إلى ذلك.

هل نريد Go لدعم أدوات Microsoft build وكذلك دول مجلس التعاون الخليجي؟

في رأيي ، الجواب هو نعم. المترجمون أنفسهم أحرار مع مجتمع VS ، وعدم وجود دعم كامل لنظام Windows أمر محبط حقًا. لا يجب أن أقوم بالوقوف على مربع Linux لتجميع github.com/Microsoft/hcsshim (على سبيل المثال) ، لأن سلسلة أدوات Windows غير مدعومة.

ما سبب عدم دعم سلسلة أدوات Windows؟

أعتقد أنه من الجيد من حيث المبدأ دعم ملفات كائن MSVC. سنحتاج أن يكون لدينا منشئ.

شاغلي الرئيسي هو إلى أي مدى قد يتغير التنسيق بين إصدارات Windows أو MSVC. تنسيق ELF المستخدم في معظم الأنظمة الأساسية الأخرى مستقر للغاية ؛ نادرًا ما نضطر إلى تعديل دعم ELF بأي طريقة بخلاف إضافة دعم للمعالجات الجديدة. هل تنسيق ملف MSVC مستقر بالمثل؟

التنسيقات المرتبطة بسلسلة أدوات MSVC مستقرة إلى حد ما. ستكون أكبر مشكلة هي دعم الأدوات نفسها. تميل Microsoft إلى نقل الأشياء (الملفات وإدخالات التسجيل) بين إصدارات Visual studio. معظم هذا قابل للتكوين (على الأقل في التصحيح الذي كتبته) ولكن لا يزال هناك احتمال أنه عند إصدار إصدار رئيسي جديد من الاستوديو المرئي ، قد لا يكون متوافقًا كسلسلة أدوات بناء بدون تغييرات على Go. ومع ذلك ، ستستمر جميع الإصدارات السابقة المدعومة من الاستوديو المرئي في العمل.

على حد علمي ، يتمتع تنسيق COFF باستقرار معقول إذا عرّضت نفسك لـ C ABI فقط (وليس C ++). كما أنها موثقة على نطاق واسع وتوفر LLVM تنفيذًا مرجعيًا.

cchamplin أوصي

سنحتاج أن يكون لدينا منشئ.

ianlancetaylor بمجرد إثبات أن كائنات MSVC تعمل على النحو المنشود ، هل تعتقد أنه ستكون هناك حاجة لكل من مُنشئ msys / cygwin ومنشئ MSVC ، أم أنه سيكون هناك مُنشئ MSVC فقط؟

أنا متأكد من أن بعض الأشخاص سيفضلون استخدام أدوات cygwin ، وهم يعملون بالفعل ونريدهم أن يستمروا في العمل ، لذلك أعتقد أننا بحاجة إلى بنائين.

مرحبًا ، يبدو من الجزء السفلي من هذا الموضوع أنك قد تم حل مشكلات MSVC. ولكن إذا واجهت أي مشاكل ، فأنا عضو في فريق MSVC. لا تتردد في الاتصال بي على github أو البريد الإلكتروني ([email protected])

سنحتاج أن يكون لدينا منشئ.

نعم فعلا. ويجب أن نبدأ على الأرجح بتغيير البناة الحاليين لدينا لتثبيت أدوات بناء MS. لذا يمكننا استخدامها لأننا نقبل CLs لهذه المشكلة.

يمكننا تثبيت أدوات دول مجلس التعاون الخليجي وأدوات Microsoft على جميع أدوات الإنشاء لدينا. هل يمكننا تشغيل all.bat الذي يختبر أدوات دول مجلس التعاون الخليجي ومايكروسوفت دفعة واحدة؟ إذا لم يكن الأمر كذلك ، فسنحتاج إلى إنشاء بنائين مختلفين لأدوات مختلفة. ما هي المعلمات التي تتحكم في استخدام المترجمات الخارجية والرابطات؟

شاغلي الرئيسي هو إلى أي مدى قد يتغير التنسيق بين إصدارات Windows أو MSVC.

لا تحصل على مترجم مثبت مع Windows. عليك تثبيته بنفسك. تمامًا كما نفعل مع دول مجلس التعاون الخليجي. نقوم بتثبيت أي إصدار نحب. يمكننا حتى تشغيل إصدارات مختلفة من دول مجلس التعاون الخليجي على أدوات إنشاء مختلفة.

هل تنسيق ملف MSVC مستقر بالمثل؟

لا اعلم شيئا عن ذلك. أظن أنك تستخدم فقط الأدوات المتوفرة.

اليكس

شاغلي الرئيسي هو إلى أي مدى قد يتغير التنسيق بين إصدارات Windows أو MSVC. تنسيق ELF المستخدم في معظم الأنظمة الأساسية الأخرى مستقر للغاية ؛ نادرًا ما نضطر إلى تعديل دعم ELF بأي طريقة بخلاف إضافة دعم للمعالجات الجديدة. هل تنسيق ملف MSVC مستقر بالمثل؟

نعم ، COFF مستقر للغاية.

bradfitz و ianlancetaylor ما الذي نحتاجه لإتاحة مُنشئ Windows لاختبار التغييرات الخاصة بهذه المشكلة؟ راجع أسئلتي على https://github.com/golang/go/issues/20982#issuecomment -370719472

شكرا لك

اليكس

هل اذهب لدعم كائن msvc الآن؟

تغيير https://golang.org/cl/110555 يذكر هذه المشكلة: debug/pe: parse the import directory correctly

alexbrainmanbradfitzianlancetaylor:

لقد قمت بمعظم العمل المطلوب على ما أعتقد لتنظيف الرقعة وتقسيمها إلى قطع أكثر قابلية للهضم. أعتقد أنني على وشك الاستعداد للتقديم الفعلي للمشروع. أعتقد أنني بحاجة إلى معرفة ما إذا كان ينبغي علي انتظار كلمة بشأن موقف المنشئ قبل إرسال الكود أو القيام بذلك في أسرع وقت ممكن؟

يمكنك إرسال CLs في أي وقت ، لكن شخصًا ما يحتاج إلى إعداد منشئ. خلاف ذلك ليس لدينا طريقة لاختبارها.

johnsonj ، هل يمكنك إضافة أدوات مترجم MSVC إلى صور Windows الخاصة بنا؟

من الناحية المثالية ، لا أرغب في إضافة نوع مضيف جديد وجعل 1-3 من أنواع مضيفات Windows الحالية لديها أدوات MSVC بالإضافة إلى Cygwin. وبعد ذلك يمكننا إضافة المزيد من تكوينات المنشئ فوق نوع (أنواع) المضيف المعدلة.

/andybons سم مكعبbcmills كما FYI (لكيفية حدوث يندوز الاشياء ... نرجو جيف لمساعدة :))

johnsonj ، هل يمكنك إضافة أدوات مترجم MSVC إلى صور Windows الخاصة بنا؟

cchamplin أقترح عليك محاولة إضافة أي أدوات مطلوبة إلى المنشئ بنفسك. لا أحد غيرك ، لكنك تعلم ما هو المطلوب. يمكنك البحث في دليل golang.org/x/build/env/windows للحصول على التعليمات الكاملة. على وجه الخصوص ، ربما تريد إضافة المزيد من السطور إلى startup.ps1. بمجرد أن تعرف ما الذي يجب تغييره في هذا المدير ، قم بإجراء التغييرات وإرسال التغيير الخاص بك للمراجعة عبر https://golang.org/doc/contribute.html بمجرد قبوله ، يمكننا تحديث المنشئين باستخدام هذه التعليمات.

من الناحية المثالية ، لا أرغب في إضافة نوع مضيف جديد وجعل 1-3 من أنواع مضيفات Windows الحالية لديها أدوات MSVC بالإضافة إلى Cygwin. وبعد ذلك يمكننا إضافة المزيد من تكوينات المنشئ فوق نوع (أنواع) المضيف المعدلة.

كان لدينا دائمًا مترجم Mingw (gcc) C و linker على windows. ليس لدينا مجموعة مختلفة من أدوات بناء سي. بمجرد أن نضيف دعمًا لمترجم Microsoft C ، هل سيكون من الممكن اختبار وظائف كل من Mingw و Microsoft C مع تشغيل واحد من all.bat؟ أم أن Mingw أو Microsoft C يستبعدان بعضهما البعض؟ هل سيتعين علينا تعيين بعض متغيرات البيئة للإشارة إلى Mingw أو إلى Microsoft ، ولكن ليس كلاهما مطلقًا؟ أفترض أنني أحاول فهم كيفية هيكلة الكود واختباره. سيحدد هذا أيضًا عدد البناة المختلفين الذين نحتاجهم.

اليكس

سأبحث في خبز الثنائيات في الصورة

تغيير https://golang.org/cl/112036 يشير إلى هذه المشكلة: env/windows: add visual studio tools to image

johnsonj @ برادفيتز : شكرًا لإدخال ذلك في المنشئ.

alexbrainmanbradfitzianlancetaylor: حتى الآن مثل اختبار استراتيجية لهذا لست متأكدا بالضبط ما للذهاب ل. يمكننا اتخاذ مسار تشغيل اختبار التوزيع لكلا سلسلتي الأدوات في النافذة وإجراء كل اختبار مرتين ، أو هل ينبغي علينا اختبار اختبارات cgo مرتين فقط (مرة في مجلس التعاون الخليجي ، ومرة ​​واحدة لـ MSVC)؟

وبقدر ما يتعلق الأمر باختبار إستراتيجية هذا ، فأنا لست متأكدًا بالضبط ما الذي يجب أن أذهب إليه. يمكننا اتخاذ مسار تشغيل اختبار التوزيع لكلا سلسلتي الأدوات في النافذة وإجراء كل اختبار مرتين ، أو هل ينبغي علينا اختبار اختبارات cgo مرتين فقط (مرة في مجلس التعاون الخليجي ، ومرة ​​واحدة لـ MSVC)؟

cchamplin ليس لدي إجابة على سؤالك. أظن أن إيان يعرف الإجابة.

اليكس

ما هي تكلفة إجراء جميع الاختبارات مرتين بدلاً من مجرد cgo؟

mxplusb ، يمكننا فقط تشغيل تكوين بناء جديد لنظام Windows

أخبرني فقط كيف أجعله مختلفًا: ضع متغير بيئة مختلفًا / جديدًا ، ثم شيء ما سوف يلتقط ذلك ، أفترض؟

ربما يستغرق الأمر بعض الأشياء لإنجاح هذا الأمر.

إما أننا بحاجة إلى التشغيل داخل قذيفة / بيئة حيث سيتم تشغيل اختبار go الذي ينفذ اختبار التوزيع داخله بعد تشغيل / استدعاء vsvars.bat المناسب

أو يمكن أن يكون لدينا dist تنفيذ vsvars المناسب واستخراج متغيرات البيئة التي تحتاجها ثم تعيينها / تمريرها للاختبار.

من المحتمل أيضًا أن نرغب في بعض متغيرات البيئة لإخبار dist أو make.bat بأننا نريد إجراء الاختبارات باستخدام مجموعة msvc-compiler.

إما أننا بحاجة إلى التشغيل داخل قذيفة / بيئة حيث سيتم تشغيل اختبار go الذي ينفذ اختبار التوزيع داخله بعد تشغيل / استدعاء vsvars.bat المناسب

أو يمكن أن يكون لدينا dist تنفيذ vsvars المناسب واستخراج متغيرات البيئة التي تحتاجها ثم تعيينها / تمريرها للاختبار.

أفضل إذا لم نقم بتشغيل ملفات دفعية من dist.exe أو go.exe. من الصعب التعامل مع الملفات الدفعية.

من المحتمل أيضًا أن نرغب في بعض متغيرات البيئة لإخبار dist أو make.bat بأننا نريد إجراء الاختبارات باستخدام مجموعة msvc-compiler.

كنت أتمنى أن يعرف إيان ما هو أفضل نهج هنا. من خلال ما أعرفه ، فإننا ندعم برامج التحويل البرمجي للغة C على نظام Unix أيضًا (gcc أو clang). بالتأكيد تسمح لنا عملية البناء لدينا باختبار مترجمي لغة سي مختلفين.

اليكس

لم ألاحظ من قبل أنك تخطط لاستخدام go build -compiler msvc . هذا غير منطقي. يأخذ الخيار go build -compiler اسم مترجم Go (حاليًا إما gc أو gccgo). لا يأخذ اسم مترجم سي. يتم تمرير مترجم C في متغير البيئة CC . يتم تعيين مترجم C الافتراضي عن طريق تعيين متغير البيئة CC_FOR_TARGET عند تشغيل make.bat ، كما هو موثق في التعليقات في make.bat.

أتوقع أنه سيكون لدينا منشئ نرتب له لضبط متغير البيئة CC_FOR_TARGET على msvc قبل تشغيل all.bat. لا أفهم لماذا يتعين علينا فعل أي شيء آخر.

يتم تمرير مترجم C في متغير بيئة CC. يتم تعيين مترجم C الافتراضي عن طريق تعيين متغير البيئة CC_FOR_TARGET عند تشغيل make.bat ، كما هو موثق في التعليقات في make.bat.

شكرا لك ايان للتوضيح.

cchamplin آمل أن تتمكن من تعديل تغييراتك لتلائم النموذج الحالي. أخبرنا ، إذا كان لديك أي مشكلة. شكرا لك.

أتوقع أنه سيكون لدينا منشئ نرتب له لضبط متغير البيئة CC_FOR_TARGET على msvc قبل تشغيل all.bat.

لدينا 3 بناة نوافذ amd64 على https://build.golang.org. هل يجب أن نستبدل واحدًا في MSVC واحد؟ هل نريد منشئ 386 MSVC؟

اليكس

ianlancetayloralexbrainman مفهومة حول علم -compiler. لا أعتقد أن هناك طريقة سهلة لجعل إعداد CC="msvc" (أو CC="cl.exe" ) يعمل فقط. لا يزال CC بحاجة للإشارة إلى موقع دول مجلس التعاون الخليجي لكي تعمل إصدارات MSVC. لا تحتوي مجموعة أدوات مترجم msvc على الأدوات المتاحة للسماح لـ CGO بإجراء الاستبطان الذي تحتاجه (البحث عن التعريف ، دقة النوع) لذلك لا يزال GCC مطلوبًا في عمليات إنشاء MSVC ، ولا يتم استخدام GCC في مرحلة التجميع / الربط الفعلية.

هل إضافة علم جديد للذهاب للبناء وكل شيء مقبول (toolchain أو شيء من هذا القبيل)؟ لقد اضطررت بالفعل إلى إضافة علامة أدوات إلى cgo على ما أعتقد.

يبدو أيضًا أن تعيين CC_FOR_TARGET قبل all.bat قد يكون له عواقب سلبية لأنه سيؤثر على المترجم المستخدم في التمهيد. لا أعتقد أنه يمكن استخدام MSVC أثناء عملية التمهيد (لست 100٪ في هذا الأمر ، لم أحاول فعلاً ولكني أشك بشدة في أنها ستنجح)

أرى ، بالنسبة لـ MSVC ، نحتاج إلى الحصول على كل من GCC و MSVC؟ أين يتم استخدام GCC فقط بواسطة أداة CGO؟ يبدو هذا مؤسفًا إلى حد ما ، لأنه يعني أننا سنعتمد تمامًا على دول مجلس التعاون الخليجي و MSVC لتنفيذ نفس ABI بالضبط ، لكن أعتقد أن هذا مرجح إلى حد ما.

أعتقد أنه يمكننا إضافة متغير بيئة آخر CC_FOR_CGO ، والذي يمكن ضبطه على GCC.

سيتم استخدام CC_FOR_TARGET المستخدم بواسطة make.bat لإنشاء وقت تشغيل / cgo. ليس من الواضح بالنسبة لي كيف يمكن أن يعمل cgo على الإطلاق إذا لم يتم إنشاء وقت التشغيل / cgo بواسطة مترجم C الذي تستخدمه.

ربما يجب أن نبدأ بجعل الأشياء تعمل عندما يتم استدعاء make.bat من خلال تعيين CC_FOR_TARGET إلى cl و CGO_ENABLED إلى 0 .

شكرا ianlancetaylor :

أرى ، بالنسبة لـ MSVC ، نحتاج إلى الحصول على كل من GCC و MSVC؟ أين يتم استخدام GCC فقط بواسطة أداة CGO؟ يبدو هذا مؤسفًا إلى حد ما ، لأنه يعني أننا سنعتمد تمامًا على دول مجلس التعاون الخليجي و MSVC لتنفيذ نفس ABI بالضبط ، لكن أعتقد أن هذا مرجح إلى حد ما.

أوافق على أنه أمر مؤسف ، وسأكون سعيدًا لمعرفة بعض البدائل ، لم أجد واحدًا بعد. هناك بالتأكيد مخاطر بناء بهذه الطريقة (على سبيل المثال ، يحتوي كود cgo الذي يتم إنشاؤه على أنواع مختلفة من التعريفات أو المعرفة اعتمادًا على المترجم الذي يعتقد أنه تم إنشاؤه بواسطته). لذلك قد لا تنجح الإنشاءات دائمًا أو تعمل بشكل صحيح دون بعض التغيير والتبديل (هناك آلية للتعامل مع هذا في تطبيقي ، لكنها عملية يدوية إلى حد ما). للأسف ، أعتقد أن هذه مخاطرة سيتعين على الأشخاص تحملها إذا أرادوا استخدام سلسلة أدوات MSVC وكل ما يمكننا فعله هو توثيقه في الوقت الحالي.

في ملاحظة مماثلة ، لا يوجد حتى الآن مسار حقيقي للمضي قدمًا لتوفير الدعم المعقد 64 و 128 في برامج MSVC المبنية ببساطة لأن برنامج التحويل البرمجي MSVC غير متوافق مع c99.

أعتقد أنه يمكننا إضافة متغير بيئة آخر CC_FOR_CGO ، والذي يمكن ضبطه على GCC.

لذا فإن التطبيق الحالي الذي أمتلكه هو أنه إذا تم توجيه الأمر إلى go build للبناء باستخدام MSVC ، فسوف يبحث افتراضيًا عن cl.exe على المسار ولكن يمكن تجاوز ذلك باستخدام متغير البيئة MSCC. سيستمر CGO في استخدام متغير بيئة CC الذي يعود إلى دول مجلس التعاون الخليجي / أيًا كان موجودًا في zdefaultcc.go الذي تم إنشاؤه

سيتم استخدام CC_FOR_TARGET المستخدم بواسطة make.bat لإنشاء وقت تشغيل / cgo. ليس من الواضح بالنسبة لي كيف يمكن أن يعمل cgo على الإطلاق إذا لم يتم إنشاء وقت التشغيل / cgo بواسطة مترجم C الذي تستخدمه.

في التطبيق الحالي ، سيعمل cgo بسعادة مع ثنائيات msvc حتى لو تم إنشاء سلسلة أدوات go بالكامل بواسطة دول مجلس التعاون الخليجي. على سبيل المثال ، تمت إضافة رمز MSVC إلى go / src. يتم تشغيل all.bat لبناء بيئة Go باستخدام دول مجلس التعاون الخليجي. بعد ذلك يمكن استخدام go / bin / go.exe للإنشاء باستخدام سلسلة أدوات msvc (بافتراض توفير العلامات). ربما أكون قد أسيء فهم ما تقوله هنا بالرغم من ذلك.

التعقيد حول هذا الأمر لأن إخبار go we want to build with msvc هو أكثر تعقيدًا ثم مجرد تبديل المترجم إلى cl. سلسلة أدوات MSVC مختلفة تمامًا عن سلسلة أدوات دول مجلس التعاون الخليجي. في MSVC ، يجب إعداد بيئة من خلال التشغيل داخل vcvars.bat (أو القيام بما يفعله v8 على سبيل المثال وهو تشغيل vcvars.bat واستخراج جميع المعلومات التي تحتاجها من متغيرات البيئة التي تقوم بإعدادها ثم استخدامها في بنائها معالجة). بعد أن نكون في بيئة MSVC ، يتمثل الاختلاف الرئيسي في الأدوات نفسها المستخدمة cl.exe لتجميع ملفات C و C ++ ، ويتم استخدام ml.exe و ml64.exe لتجميع الملفات ، وأخيراً يتم استخدام link.exe (مللي ثانية) ربط كل شيء معا. لذلك فهو أكثر من مجرد تعيين CC=cl.exe وتمريره العلامات الصحيحة. هل هذا منطقي / يساعد في توضيح الأشياء؟

لمزيد من التوضيح على

سيتم استخدام CC_FOR_TARGET الذي تستخدمه make.bat لإنشاء وقت تشغيل / cgo. ليس من الواضح بالنسبة لي كيف يمكن أن يعمل cgo على الإطلاق إذا لم يتم إنشاء وقت التشغيل / cgo بواسطة مترجم C الذي تستخدمه.

go build بتحديد الملفات المناسبة من وقت التشغيل / cgo أثناء عملية الإنشاء (على سبيل المثال ، go build / go test / go run - ليست عملية البناء) عندما تم اختيار سلسلة أدوات msvc.

أنا منفتح على الاقتراحات حول كيفية عمل ذلك ، ولكن لا ينبغي أن يتطلب خيار سطر أوامر جديدًا لأداة go. هل يمكننا كتابة برنامج Go Pure يعمل مثل GCC بقدر ما يتعلق الأمر بأداة go ولكنه يدير MSVC بالفعل؟

هل يمكننا كتابة برنامج Go Pure يعمل مثل GCC بقدر ما يتعلق الأمر بأداة go ولكنه يدير MSVC بالفعل؟

أعتقد أن هذا قد يكون عمليًا ، دعني أرى ما إذا كان بإمكاني الحصول على شيء يسير في هذا الطريق.

بالإضافة إلى ذلك ، أعتقد أنني بحاجة إلى توضيح ما إذا كانت إضافة علامات سطر الأوامر إلى أدوات أخرى ستكون مشكلة أيضًا. في الوقت الحالي ، يتمثل التصحيح الشامل لهذا في إنشاء العديد من علامات سطر الأوامر الجديدة في أدوات مختلفة

• cmd / cgo
  
  
  
  • -toolchain [gcc، msvc] (الافتراضي إلى دول مجلس التعاون الخليجي) Toolchain لاستخدامها عند إنشاء ملفات إخراج cgo
  
  
• كمد / رابط
  
  
  
  • -rlocbss (الافتراضيات إلى false) انقل .bss إلى .data
  
  
  • -toolchain [gcc، msvc] (الافتراضي إلى دول مجلس التعاون الخليجي) Toolchain لاستخدامها في الارتباط الخارجي
  
  

نقوم أيضًا بإنشاء خيارات البناء التالية / متغيرات البيئة cgo:

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

بعد بضع دقائق من التفكير ، هناك بعض العقبات التي قد يكون من الصعب التغلب عليها إذا قمنا فقط بالوكالة ، فإن أوامر المترجم فكرت في برنامج مختلف معًا

1. يحتاج go build إلى معرفة ما هي سلسلة الأدوات الخارجية لتحديد ملفات وقت التشغيل / cgo المراد إنشاؤها ، وإلا سينتهي الأمر بمجرد تمرير إصدارات gcc غير المتوافقة إلى أمر الوكيل الخاص بنا. قد نكون قادرين على اختراق هذا داخل الوكيل نفسه ، لكنه سيكون هشًا ومن المحتمل أن ينكسر إذا تمت إضافة ملفات إضافية إلى وقت التشغيل / cgo.
2. يحتاج cmd / cgo إلى معرفة نوع سلسلة الأدوات الخارجية المستخدمة لاختيار أي إصدار من كود C الناتج لاستخدامه
3. سيحتاج البرنامج الوكيل إلى آلية ما لمعرفة ما إذا كان يجب تنفيذ gcc أم لا (كما هو الحال عند استدعاؤه بواسطة cmd / cgo) أو تنفيذ cl.exe الذي يمكن تمريره ولكن هذا يعني أن المتصل سيحتاج إلى معرفة سلسلة الأدوات هو أو لدينا cmd / cgo لتمرير أعلام غير موجودة إلى دول مجلس التعاون الخليجي.
4. go build يستدعي cmd / link الذي يحتاج أيضًا إلى معرفة نوع toolchain بحيث يمكنه تنفيذ .bss إلى .data relocation. وحتى يتمكن من تمرير إشارات محددة إلى الرابط (قد نتمكن من التعامل مع هذا الأخير جزء في الوكيل نفسه رغم ذلك)

هل تحديد متغير بيئة لاستخدام go build لتحديد عمل إصدارات msvc؟ على الرغم من أنني أعتقد أنه يضع المعيار أعلى لشخص يريد فقط إنشاء برنامج باستخدام msvc ، حيث يتعين عليهم الآن تعيين متغيرات بيئة متعددة بالإضافة إلى التشغيل داخل vsvars.bat (بحد أدنى CC و UNDECIDED_TURN_ON_MSVC_BUILD_VAR )

البديل الآخر هو أن يكون لديك go build تشغيل أمر زائف noop على CC المحدد ثم تحليل الشعار / الرأس لاكتشاف ما إذا كان msvc أو gcc والمتابعة مع تعديلات toolchain المناسبة في تلك المرحلة ... لست متأكدًا من مدى هشاشة هذا أو كيف سيعمل مع سلاسل الأدوات المتوافقة مع msvc مثل clang.

اكتشفت مشكلة Github هذه مؤخرًا ، وهذا العمل مثير جدًا بالنسبة لي. آمل أن يهبط هذا في مكان ما في المستقبل القريب.

أعتزم استخدام CGo على Windows كأغلفة لبعض التعليمات البرمجية الخاصة بالجهات الخارجية التي تم إنشاؤها باستخدام MSVC ، والتي لا يمكنني إعادة بنائها من المصادر باستخدام mingw-w64 . لدي بعض حالات الاختبار الخطيرة نسبيًا لتشغيلها من خلال ، لذا يمكنني التحقق من صحتها جيدًا.

على أي حال ، شكرًا لـ cchamplin وأي شخص آخر يعمل عليه ، ويرجى إخباري بأي حال يمكنني المساعدة.

cchamplin أعرف ما يكفي سلاسل أدوات المترجم في Windows و cgo التي قد أتمكن من مساعدتها. هل ستتمكن من اللحاق بي فيما كنت تعمل عليه؟ سأرى ما يمكنني القيام به للمساعدة. وأنا أعلم أنdeadprogram حالة استخدام لديها وذلك لدي جيدة السرير اختبار المتقدمة عندما نكون على استعداد للاختبار.

مرحبًا mxplusb ، التصحيح جاهز تقريبًا للعمل. إذا كان بإمكاني العثور على الوقت ، فسأرسل التغييرات إلى gerrit الليلة أو غدًا ، وهو ما سيبدأ في مراجعة كل شيء وتحديثه واعتماده.

تغيير https://golang.org/cl/133937 يذكر هذه المشكلة: cmd/link: Add flag rlocbss to relocate .bss data to .data

تغيير https://golang.org/cl/133938 يشير إلى هذه المشكلة: runtime/cgo: MSVC toolchain support in cgo native code

تغيير https://golang.org/cl/133939 يذكر هذه المشكلة: cmd/cgo: Add toolchain flag to cgo command for MSVC support

تغيير https://golang.org/cl/133946 يذكر هذه المشكلة: cmd/compile: Add support for MSVC toolchain to go build

يبدو أنني أخطأت في المشكلة إملائيًا في بعض الالتزامات. سأترك عملية المراجعة جارية وسأحدد أفضل طريقة لإصلاحها.

تغيير https://golang.org/cl/133943 يذكر هذه المشكلة: cmd/cgo: Add support for CC_FOR_CGO environment variable

تغيير https://golang.org/cl/133942 يذكر هذه المشكلة: tests: Update various tests to prepare for MSVC compiler toolchain

تغيير https://golang.org/cl/133940 يذكر هذه المشكلة: misc/cgo: Adjust tests to be compatible with MSVC toolchain support

تغيير https://golang.org/cl/133941 يذكر هذه المشكلة: runtime: Add runtime.CompilerType to denote between host compiler type

تغيير https://golang.org/cl/133945 يذكر هذه المشكلة: cmd/link: Add external toolchain support for MSVC

تغيير https://golang.org/cl/133944 يذكر هذه المشكلة: cmd/compile, cgo: Add support for MSVC flags

cchamplin هل يمكنك وصف ما كان القرار النهائي؟ كيف يبدو دعم MSVC؟ ما هي أعلام سطر الأوامر التي سيتم إضافتها؟ ما الذي يجب على المستخدم فعله ببيئته بالإضافة إلى تنزيل MSVC؟ شكرا

أيضا ، كيف يمكننا أن نجرب هذا التصحيح؟ لم أتمكن من العثور على التزاماتك في الريبو.

rasky لا يزال الأمر في حالة تغير

@ blizzardplus على غرار الأشياء المذكورة أعلاه في كثير من تجربتها (الأمر متروك لك). تم نشر جميع التغييرات ذات الصلة مرة أخرى لهذه المشكلة بواسطة gopherbot ، يمكنك العثور عليها هناك.

cchamplin هل يوجد دعم gcc أو clang ؟ إذا كان الأمر كذلك ، فهل تم اختبارهم؟

cchamplin لا أرى أي نشاط على CLs منذ 11 سبتمبر ، هل هناك تقدم في هذا الأمر أم أنه بحاجة إلى موارد إضافية؟

cchamplin لكي يعمل هذا لأرشيف c ، يجب تغيير قسم ctors إلى .CRT $ XCU (https://msdn.microsoft.com/en-us/library/bb918180.aspx) - إذا لم يتم ذلك ، لن يتم تهيئة وقت تشغيل golang. كما اتضح أيضًا ، إذا قمت بتعيينه على هذا ، فإنه يعمل بشكل جيد لدول مجلس التعاون الخليجي أيضًا - يقوم مجلس التعاون الخليجي بهذه الوظائف ، وينقلها إلى قسم نصي ، ويعدل main لاستدعاءها قبل الرئيسي الحقيقي. يمكن لبرنامج Visual Studio فهم ملفات الأرشيف. وبما أن واجهة الملفات المُجمَّعة مسبقًا / المُجمَّعة مسبقًا هي C ، فلا ينبغي أن تكون هناك مشكلة في وجود هذا في الأرشيف فقط. يوجد تحذير بشأن قسمين نصيين ولكن يبدو أن الحالات البسيطة تعمل بشكل جيد (تحتاج إلى مزيد من الاختبارات للتأكيد ، فلا توجد مشكلات).

أيضًا ، لكي يعمل هذا من أجل c-Shared ، يجب تزيين الوظائف المراد تصديرها __declspec (dllexport) ، لكن لا يمكنني العثور على مكان حدوث هذا التوسيع في // التصدير.

blizzardplus يوجد تصحيح متابعة لهذا لدعم clang-MSVC. لست متأكدًا مما تقصده بالتجميع المتقاطع في هذه الحالة؟ لن تتمكن من استخدام سلسلة أدوات MSVC على أنظمة بخلاف أنظمة Windows. يجب ألا تتغير وظائف التجميع المتقاطعة الأخرى.

kshelton لسوء الحظ ، هذا وقت مزدحم جدًا من العام بالنسبة لي لأن لديّ مشاريع أخرى في الأعمال والمؤتمرات التي

kshelton شكرا. لم أقم بمراجعة التصحيح مرتين ، أفترض أنني قمت بتطويره بافتراض أن c-archive لن يعمل على MSVC ، أو قمت بتعطيله على وجه التحديد؟ سرت في طريق محاولة تزيين الصادرات بشكل صحيح عندما كنت أحاول الحصول على مكون إضافي / عمل مشترك على windows. أعتقد أن هناك قضايا أخرى ، لكن يمكنني الخلط بين مسألتين. هناك مشاكل حقيقية تتعلق بكيفية الانتقال إلى أماكن الكود المشترك في PLT / GOT لـ ELF مقابل Windows .edata و idata و EAT. أعتقد أن معظم المشكلات التي واجهتها كانت تتعلق بالانتقال إلى أماكن أخرى وعدم القدرة على جعلهم يعملون. إذا كان لدى أي شخص نظرة ثاقبة في هذا فسيكون ذلك رائعًا. انظر # 19282

لقد حاولت أن أرى cchamplin ، إذا كان بإمكاني إنشاء Go فوق 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>

ما الذي افتقده هنا؟

شكرا لك.

اليكس

تضمين التغريدة

ما الذي افتقده هنا؟

من المحتمل أن تحتاج كحد أدنى إلى تعيين 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) تمرير. كيف تقترح تعديل كود Go لجعل٪ GOROOT٪ \ src \ all.bat يقوم بتشغيل اختباراتك المعدلة من https://go-review.googlesource.com/c/go/+/133940. ربما يمكن أن يختبر all.bat كلاً من نسختي gcc و msvc من الاختبارات. ربما يمكننا استخدام بعض متغيرات البيئة التي تخبر all.bat بإصدار الاختبارات المطلوب تشغيلها - عندئذٍ يمكن أن يكون لدينا بنّاءان مختلفان يشغّلان إصدارات مختلفة من الاختبارات. هل فكرت في كل هذا؟

كما أنني لم أحاول شخصيًا أبدًا بناء نفسه مع MSVC. لست متأكدًا مما إذا كان هذا سيعمل / يجب دعمه.

يمكنك تشغيل all.bat حتى اكتماله بنجاح دون تثبيت دول مجلس التعاون الخليجي. يحتاج الإصدار الحالي من Go فقط إلى إصدار آخر من Go (على الأقل go1.4) للإنشاء. يحتاج Cgo فقط إلى مترجم C ، وكان لدي انطباع بأن التغييرات التي أجريتها تطبق إصدار Cgo الذي تم إنشاؤه بواسطة MSVC. لكن ربما أكون مخطئا. يرجى تصحيح لي إذا كنت مخطئا.

شكرا لك.

اليكس

تضمين التغريدة

يحتوي https://go-review.googlesource.com/c/go/+/133940 على بعض الاختبارات. كيف أتحقق من اجتياز الاختبارات؟ ما هي الخطوات بالضبط؟

ربما يمكن أن يختبر all.bat كلاً من نسختي gcc و msvc من الاختبارات. ربما يمكننا استخدام بعض متغيرات البيئة التي تخبر all.bat بإصدار الاختبارات المطلوب تشغيلها - عندئذٍ يمكن أن يكون لدينا بنّاءان مختلفان يشغّلان إصدارات مختلفة من الاختبارات. هل فكرت في كل هذا؟

نعم ، يتم استخدام هذه الآلية بالضبط في https://go-review.googlesource.com/c/go/+/133946/. منذ تشغيل جميع المكالمات في run.bat على windows ، تم وضع آلية استدعاء اختبارات cgo هناك. لذلك ستبدأ أنت أو المنشئ بإعداد عادي CC = gcc. ثم تقوم بتعيين GOTESTMSVC = 1 و GOVSVARSPATH = بعض مسارات vsvars.bat. بعد ذلك ، يجب تشغيل المبنى باستخدام all.bat من خلال اختبارات gcc و msvc cgo.

يمكنك تشغيل all.bat حتى اكتماله بنجاح دون تثبيت دول مجلس التعاون الخليجي. يحتاج الإصدار الحالي من Go فقط إلى إصدار آخر من Go (على الأقل go1.4) للإنشاء. يحتاج Cgo فقط إلى مترجم C ، وكان لدي انطباع بأن التغييرات التي أجريتها تطبق إصدار Cgo الذي تم إنشاؤه بواسطة MSVC. لكن ربما أكون مخطئا. يرجى تصحيح لي إذا كنت مخطئا.

انت على حق. تذهب نفسها يجب أن تبني بشكل جيد. قد تكون هناك مشكلات عندما تصل إلى الاختبار ، حيث تم تعديل run.bat لتعيين بعض متغيرات البيئة عندما يكون GOTESTMSVC = 1. ربما نحاول اكتشاف ما إذا كان go يتم إنشاؤه باستخدام msvc ، ثم تعيين متغيرات بيئة التوزيع المناسبة حتى لا تفشل الاختبارات.

ثم تقوم بتعيين GOTESTMSVC = 1 و GOVSVARSPATH = بعض مسارات 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. ولكن ماذا سيفعل المستخدمون الآخرون للتغيير الذي أجريته عندما يحتاجون إلى استخدام MSVC لـ Cgo؟ ما هي خطتك لذلك؟

اليكس

تضمين التغريدة
لست متأكدًا مما يحدث. هذا الاختبار يفشل بالنسبة لي في الماجستير

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

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

في help.go https://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/internal/help/help.go#L37
يتكرر من خلال أوامر base.Go.Go. الذي تمت تهيئته في main.go https://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/main.go#L43
لكنني لست متأكدًا من كيفية استدعاء وظيفة init في اختبار قابل للتنفيذ ، لذلك ليس لدي أي فكرة عن مدى نجاح السيد في الاختبارات في الوقت الحالي ، حيث أعتقد أن هذا يجب أن يفشل في جميع المجالات.

قد يعمل إعداد GOTESTMSVC و GOVSVARSPATH أيضًا للأشخاص الذين يقومون بتنفيذ all.bat. ولكن ماذا سيفعل المستخدمون الآخرون للتغيير الذي أجريته عندما يحتاجون إلى استخدام MSVC لـ Cgo؟ ما هي خطتك لذلك؟

لذلك في موقف تريد فيه فقط إنشاء بعض أكواد Cgo باستخدام MSVC

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

يجب أن يكون كل ما تحتاجه على ما أعتقد

لست متأكدًا من كيفية استدعاء وظيفة init في اختبار قابل للتنفيذ ، لذلك ليس لدي أي فكرة عن مدى نجاح السيد في الاختبارات في الوقت الحالي ، حيث أعتقد أن هذا يجب أن يفشل في جميع المجالات.

عند استخدام go test مع ملف في cmd / go ، ستقوم أداة go بإنشاء حزمة cmd / go ثم إنشاء الاختبارات وإنشاء برنامج تشغيل الاختبار وبناء ذلك وربط كل شيء معًا في حزمة رئيسية جديدة. يحدث هذا على الرغم من أن cmd / go هو في حد ذاته حزمة رئيسية. أي أن الحزمة الرئيسية في cmd / go / *. go ستُعامل على أنها حزمة غير رئيسية لأغراض الاختبار. يتيح ذلك الاختبارات لاستدعاء الوظائف المحددة في الحزمة الرئيسية إذا كان ذلك مناسبًا.

آسف ، أنا بطيء في الرد. لكن لم يكن لدي وقت فراغ للنظر في هذا مرة أخرى.

لست متأكدًا مما يحدث. هذا الاختبار يفشل بالنسبة لي في الماجستير

أنا لم أستعمل السيد. لقد استخدمت e56d52f66b95b87001867a2487a11bd961f40d4d الالتزام. ألم تقم بتشغيل all.bat على هذا الالتزام قبل إرساله للمراجعة؟ هل نجح all.bat؟ هل يمكنك محاولة تشغيل all.bat على هذا الالتزام مرة أخرى لمعرفة ما إذا كان الأمر يتعلق بتكوين نظامي. شكرا لك.

لذلك في موقف تريد فيه فقط إنشاء بعض أكواد Cgo باستخدام MSVC

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

يجب أن يكون كل ما تحتاجه على ما أعتقد

2 من متغيرات البيئة ، على الأرجح ، معقدان للغاية بالنسبة للمستخدم العادي. و CC_FOR_CGO=gcc يبدو غريبًا بالنسبة لي - لماذا نستخدم دول مجلس التعاون الخليجي لإنشاء كود باستخدام MSVC؟

اليكس

تضمين التغريدة

أنا لم أستعمل السيد. لقد استخدمت e56d52f66b95b87001867a2487a11bd961f40d4d الالتزام. ألم تقم بتشغيل all.bat على هذا الالتزام قبل إرساله للمراجعة؟ هل نجح all.bat؟ هل يمكنك محاولة تشغيل all.bat على هذا الالتزام مرة أخرى لمعرفة ما إذا كان الأمر يتعلق بتكوين نظامي. شكرا لك.

أعتقد أن الأمر يتعلق بتكوين نظامي الذي كان يعطيني نتائج غريبة عند إجراء الاختبارات. أعتقد أنني أصلحت المشكلة ودفعت بعض التحديثات لمجموعة التغيير.

2 من متغيرات البيئة ، على الأرجح ، معقدان للغاية بالنسبة للمستخدم العادي. و CC_FOR_CGO = تبدو دول مجلس التعاون الخليجي غريبة بالنسبة لي - لماذا نستخدم دول مجلس التعاون الخليجي لإنشاء كود باستخدام MSVC؟

يجب أن يكون في الواقع CC_FOR_CGO = gcc.exe ، خطأي. ولكن للإجابة على سؤالك؛ من جيريت:

PS1 ، الخط 1324:
لا يزال cgo بحاجة إلى دول مجلس التعاون الخليجي المتاحة لتحليل النوع. إذا تم تعيين CC على مترجم MSVC ، يحتاج cgo إلى وسيلة لاستدعاء GCC التي يتم توفيرها بواسطة CC_FOR_CGO. لسوء الحظ ، لا تمتلك سلسلة أدوات MSVC آلية لتوفير نفس النوع من المعلومات التي يتم جمعها من دول مجلس التعاون الخليجي. من الناحية النظرية ، يمكن إنشاء أداة go محددة لجمع معلومات النوع التي يستخدمها cgo ولكن قد يكون ذلك خارج النطاق وربما جهدًا كبيرًا (أنا شخصياً لم أكتب أي شيء لإجراء تحليل ثابت من النوع لرمز C / C ++).

يبدو أيضًا أنني كسرت شيئًا ما مع مسح ذاكرة التخزين المؤقت بين عمليات التشغيل لـ GCC vs MSVC ، ولست متأكدًا من سبب استمرار بعض الاختبارات كما لو كانت مخزنة مؤقتًا.

أعتقد أنني أصلحت المشكلة ودفعت بعض التحديثات لمجموعة التغيير.

هذا الإعداد https://github.com/golang/go/issues/20982#issuecomment -447618566 on

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

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

    Allows building with MSVC as an external compiler/linker.

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

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

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

يأخذني إلى أبعد من ذلك ، لكنه لا يزال يفشل مع

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

ALL TESTS PASSED

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

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

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

يجب أن يكون في الواقع CC_FOR_CGO = gcc.exe ، خطأي.

لا أشعر بالقلق بشأن. exe في gcc.exe. مشاكلي

• أنت بحاجة إلى كل من أدوات دول مجلس التعاون الخليجي و MSVC لاستخدام MSVC (سيكون من الصعب شرح ذلك لمستخدمينا) ، لكنني أفهم أنه لا يمكن فعل أي شيء حيال ذلك ؛

• كنت بحاجة إلى كلا متغيري البيئة CC_FOR_CGO = gcc و CC = cl.exe set - ربما يمكننا افتراض أن CC_FOR_CGO مضبوطة دائمًا على دول مجلس التعاون الخليجي؟

ولكن للإجابة على سؤالك؛ من جيريت:

شكرا لك على شرح.

اليكس

تضمين التغريدة

# 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. أرى أن نسختك من MSVC مختلفة قليلاً عن نسختك ، والتي يمكن أن تكون السبب أيضًا. لست متأكدًا من سبب تجاهلهم الفعال لهذا القمع في إصدار مختلف.

يمكنك أيضًا محاولة إجراء تغيير ليشمل القمع عالميًا بغض النظر عن السبب

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

كنت بحاجة إلى كلا متغيري البيئة CC_FOR_CGO = gcc و CC = cl.exe set - ربما يمكننا افتراض أن CC_FOR_CGO مضبوطة دائمًا على دول مجلس التعاون الخليجي؟

أعتقد أن التحقق من وجود مجلس التعاون الخليجي إذا كان مجلس التعاون الخليجي موجودًا إذا لم يتم تعيين CC_FOR_CGO سيكون جيدًا. CC_FOR_CGO هي أكثر للأشخاص مثلي الذين ليس لديهم دول مجلس التعاون الخليجي في طريقهم. يبدو CC_FOR_CGO الخاص بي بهذا الشكل CC_FOR_CGO = I: \ Development \ tmd-gcc \ bingcc.exe. إذا لم نرغب في دعم حالة استخدام دول مجلس التعاون الخليجي التي لا تسير على طريق إنشاءات MSVC ، فأعلمني بذلك ويمكنني التخلص من متغير البيئة معًا.

حاولت مرة أخرى هذا الإصدار

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

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

    Allows building with MSVC as an external compiler/linker.

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

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

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

وأحصل على نفس الخطأ

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

ALL TESTS PASSED

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

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

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

هل يمكنك تأكيد وجود هذا الخط بداخله:

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

هذه بداية ملف src / runtime / cgo / msvc_libinit_windows.c

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

// +build cgo

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

يمكنك أيضًا محاولة إجراء تغيير ليشمل القمع عالميًا بغض النظر عن السبب

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

لقد أجريت هذا التغيير:

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

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

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

لكني أرى نفس الخطأ

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

ALL TESTS PASSED

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

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

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

اليكس

كنت أحاول إعادة إنتاج هذا الليلة الماضية ولم أتمكن من ذلك. أتساءل عما إذا كنت تعاني من هذا: https://developercommunity.visualstudio.com/content/problem/35734/c-cannot-disable-specific-warnings-with-pragmas-wh.html

هل من الممكن أن تقوم بالتحديث إلى أحدث SDK وأدوات البناء؟ أنا على SDK 10.0.17763.0. والإصدار 15.9.28307.222 من أدوات البناء / devenv

أحاول إنشاء Windows DLL مع MSVC ، ولكن يبدو أن Go يحاول تعطيل بعض التحذيرات برقم أكثر من 65535 (أو ليس رقمًا) ، مما يتسبب في توقف MSVC.

لا ، يعتبر Werror أحد خيارات دول مجلس التعاون الخليجي ، للتعامل مع كل تحذير على أنه خطأ.

بالنسبة لـ MSVC ، يجب استخدام WX .

pravic نقطة جيدة ، كيف أفعل ذلك؟ أنا لا أقوم بإعداده ، كل ما أفعله هو:

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

galich للأسف ، لا يمكنني المساعدة لأنني لا أتبع تكامل MSVC.

على سبيل المثال ، أين هي التصحيحات المتعلقة بهذا الموضوع؟ في الماجستير أو في مكان آخر؟

pravic يمكنك العثور على التغييرات هنا: https://go-review.googlesource.com/c/go/+/133946/5

mxplusb شكرًا على الرابط ، يبدو أن مشكلتي الخاصة مع / Werror تم حلها هناك.
هل تعلم متى سيصل هذا إلى الإصدار التجريبي / الليلي / المستقر؟

هل من الممكن أن تقوم بالتحديث إلى أحدث SDK وأدوات البناء؟ أنا على SDK 10.0.17763.0. والإصدار 15.9.28307.222 من أدوات البناء / devenv

cchamplin تمكنت أخيرًا من تحديث MSVC الخاص بي. لدي الآن

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

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

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

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

حاولت مرة أخرى هذا الإصدار

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

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

    Allows building with MSVC as an external compiler/linker.

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

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

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

ويتم إكمال all.bat بنجاح. لكني أتلقى هذه التحذيرات.

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

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

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

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

##### ../test

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

ALL TESTS PASSED

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

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

ولاحظت أيضًا أنك أجريت جميع الاختبارات مرتين.

...
##### 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 من المحتمل إلغاء التحذيرات لهذه الاختبارات ، خاصة في هذه الحالة تحذيرات الطيف.

بالنسبة للاختبارات التي يتم إجراؤها مرتين ، أعتقد أنه تم بهذه الطريقة للمُنشئ ، قم بإجراء الاختبارات مرة واحدة باستخدام تجميع دول مجلس التعاون الخليجي ثم قم بإجراء الاختبارات مرة أخرى باستخدام MSVC (عند التمكين) لضمان عمل التجميع باستخدام كلا سلسلتي الأدوات. لست متأكدًا مما هو مطلوب هنا ، لذا يمكنني تغييره بحيث عندما يتم استدعاء all.bat مع تمكين MSVC ، فإننا نجري الاختبارات فقط باستخدام MSVC ، أخبرني بذلك. في هذه الحالة أفترض أنه سيتعين إضافة بنائين إضافيين لـ MSVC فقط ، على عكس بعض البناة الذين يقومون أيضًا بالبناء باستخدام MSVC؟

تم الاتفاق على أنه على نظام التشغيل Windows ، ستكون هناك حاجة لتشغيل مُنشئ واحد باستخدام سلسلة أدوات MinGW-W64 وآخر باستخدام سلسلة أدوات MSVC لاختبار كلا السيناريوهين.

أعتقد أنه تم ذلك بهذه الطريقة للمُنشئ ، قم بإجراء الاختبارات مرة واحدة باستخدام تجميع دول مجلس التعاون الخليجي ثم قم بتشغيلها مرة أخرى باستخدام MSVC (عند التمكين) لضمان عمل التجميع باستخدام سلسلتي الأدوات.

أوافق على أن هذا هو السلوك المفضل ، لذلك هناك ضمان بأنه لا يكسر أعباء العمل الحالية في حالة وجود كلا سلسلتي الأدوات.

من المحتمل أن يتم قمع التحذيرات لهذه الاختبارات ، خاصة في هذه الحالة تحذيرات الطيف.

لا يعرض الأمر Go تحذيرات ، لذا يجب عدم عرض التحذيرات.

كما أنني لاحظت أن الأمر go env لا يعرض متغير CC_FOR_CGO. إذا كان CC_FOR_CGO يؤثر على كيفية عمل go build ، فيجب عرض CC_FOR_CGO مع الآخرين. هل نحتاج حقًا إلى متغير CC_FOR_CGO؟ ماذا أيضًا ، ولكن CC_FOR_CGO = دول مجلس التعاون الخليجي هل يمكن أن يكون؟

بالنسبة للاختبارات التي يتم إجراؤها مرتين ، أعتقد أنه تم بهذه الطريقة للمُنشئ ، قم بإجراء الاختبارات مرة واحدة باستخدام تجميع دول مجلس التعاون الخليجي ثم قم بإجراء الاختبارات مرة أخرى باستخدام MSVC (عند التمكين) لضمان عمل التجميع باستخدام كلا سلسلتي الأدوات.

لا تستخدم الكثير من الاختبارات دول مجلس التعاون الخليجي. عندما يتم إجراء اختبارات الحزمة مرتين دون سبب ، يعد مضيعة لوقت الأشخاص / الكمبيوتر. كما ترون من https://github.com/golang/go/issues/20982#issuecomment -480569880 archive/zip تم تشغيل اختبارات الحزمة مرتين - لا أرى حاجة للتشغيل الثاني.

لست متأكدًا من كيفية ترتيب ذلك ، ولكن ربما يجب عليك استبدال مكالمتك go tool dist test في run.bat للقيام فقط بمجموعة مختارة من الاختبارات اللازمة لاختبار بناء MSVC. انظر ، على سبيل المثال ، go tool dist test -h حول كيفية تحديد بعض الاختبارات المحددة فقط. bradfitz ربما يمكننا إنشاء علامة أو متغير بيئة يخبر الأمر dist بتشغيل اختبارات MSVC المحددة.

ولكن بشكل عام ، يعد 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>

وبعد ذلك يمكنني إنشاء ملف تنفيذي باستخدام MSVC

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

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

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

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

لذا فإن البناء باستخدام MSVC سيتطلب من المستخدمين تشغيل ملف دفعي MS لتعيين جميع متغيرات البيئة (انظر GOVSVARSPATH في مخرجاتي) - وهذا ، على ما أفترض ، قياسي وليس له علاقة بـ Go. و set CC=cl . بسيطا بما فيه الكفاية.

المشكلة الوحيدة التي أراها مع هذا الأسلوب هي أن مستخدمي MSVC سيظلون بحاجة إلى تثبيت مجلس التعاون الخليجي. يتم استخدام gcc بواسطة cmd / cgo لاكتشاف جميع واجهات C - لم يتم تنفيذ هذا الجزء باستخدام MSVC. يبدو غير مألوف بالنسبة للأشخاص الذين لا يعرفون كيف يعمل cmd / cgo ، ولكنه ما هو عليه.

ianlancetaylor و bradfitz هل يبدو كل هذا معقولاً لدفع هذا إلى الأمام؟ هل يجب أن نحاول إتاحة هذا في go1.13؟

يمكن للمطورين الذين لديهم MSVC مثبتًا بالفعل اختبار جميع التعليمات البرمجية الجديدة. سوف يتخطى البناة الآخرون الاختبارات.

اليكس

يتم استخدام gcc بواسطة cmd / cgo لاكتشاف جميع واجهات C - لم يتم تنفيذ هذا الجزء باستخدام MSVC.

كيف يمكن التغلب على ذلك؟ من الناحية المثالية ، سيكون أمرًا رائعًا إذا لم يكن هناك حاجة إلى دول مجلس التعاون الخليجي ، فقط MSVC.

كيف يمكن التغلب على ذلك؟

يجب إعادة كتابة أجزاء cmd / cgo التي تستخدم gcc لاستخدام MSVC. إن كان ممكنا.

اليكس

كنت أتساءل ما إذا كانت هذه الميزة أقرب إلى جعلها في مرحلة الإنتاج؟ أرى أنه تم وضع علامة عليه لـ 1.13 ، وقد تم إصدار ذلك للتو. أحاول إنشاء امتدادات Python باستخدام إنشاء Go c-archive المرتبط بكود الامتداد ، لكن Python تتطلب MSVC.

لا أعرف ما هي حالة هذه القضية. لقد تم دفعه للأمام من الإصدار إلى الإصدار ، لذلك سأقوم بنقله إلى الوضع غير المخطط له. إذا وصل إلى 1.14 ، فهذا عظيم.

حتى مع متطلبات المترجم المزدوج ، أود أن أرى التطبيق الحالي يدخل في الإصدار التالي. إنه على الأقل يجعل من الممكن تجميع الملفات التنفيذية / المكتبات باستخدام MSVC ، وهو أفضل من لا شيء.

حتى مع متطلبات المترجم المزدوج ، أود أن أرى التطبيق الحالي يدخل في الإصدار التالي.

أعتقد أن هذا سيكون تطبيقًا جيدًا "تجريبيًا". سيسمح بالتخلص من الأخطاء وبدء التنفيذ في النضج. ما هي الأشياء الأخرى المتبقية التي يجب القيام بها قبل أن تخضع لمراجعة جادة؟

لذا من وجهة نظري وما يمكنني تذكره من المرة الأخيرة التي نظرت فيها إلى هذا (منذ 6 أشهر تقريبًا) كان هناك عشرات أو نحو ذلك من عناصر التنظيف التي يجب إكمالها لعملية مراجعة الكود. قد تكون هناك حاجة أيضًا إلى عمل إضافي لإزالة تكرار بعض الاختبارات التي تم نسخها بشكل أساسي مع تعديلات طفيفة جدًا للعمل مع سلسلة أدوات مختلفة. هناك أيضًا حاجة لمراجعة وإيقاف بعض تحذيرات msvc.

تشمل القضايا الرئيسية المعلقة ما يلي:

لا يمكننا إجراء تحليل الكتابة بدون دول مجلس التعاون الخليجي ، ولا يوجد حل بسيط أو فوري لذلك.

إنهاء الإعداد وكيف سيعمل كل شيء للبناة.

أعتقد أنه كانت هناك بعض التغييرات المهمة إلى حد ما على المترجم والرابط في الأشهر الستة الماضية والتي قد تؤثر بشدة على العمل الحالي المنجز لهذا الغرض ، لكنني لم أتمكن من تأكيد ذلك. نظرًا للتعقيد ومنحنى التعلم العالي حول التنقل في برنامج التحويل البرمجي / الرابط / سلسلة الأدوات في Go ، فقد يستغرق الأمر وقتًا طويلاً بالنسبة لي لأصلح نفسي بما يكفي لمعرفة تأثير التغييرات على مجموعة العمل هذه.

لا يوجد دعم للأنواع الرقمية المعقدة. MSCVs C lib هو ببساطة غير متوافق. أعتقد أنه من المحتمل أن تكون هناك طريقة لإخراج هذا باستخدام C ++ لكنني غير متأكد ، ربما يمكن لشخص ما من MS على دراية بسلاسل أدوات MSVC أن يتناغم.

لسوء الحظ ، أصبحت الحياة والمشاريع الأخرى في طريقي إلى حد كبير في طريقي إلى تخصيص المزيد من الوقت لتحقيق ذلك ، لكنني سأحاول قضاء بعض الوقت في هذا الأمر في الأسابيع القادمة.

manbearian تتعلق هذه المشكلة بإضافة دعم MSVC إلى golang. مَن في فريق MSVC سيكون جيدًا للتشاور بشأن أسئلة MSVC؟

@ kesmit13 و mxplusb

هذه

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

هو cchamplin أحدث كود يعمل.

قلقي الحالي بشأن الكود ، أنه من غير الواضح كيفية استخدامه. ما الأمر الذي تديره؟ كيف هي بيئتي تحتاج إلى الإعداد؟

أعتقد أن الخطوة التالية هي أن يحاول شخص ما استخدام هذا الرمز ، ومعرفة ما إذا كان بإمكانه استخدامه بالفعل. إذا نجحت ، فيجب توثيق الخطوات ، حتى يتمكن الآخرون من استخدام الكود أيضًا. ربما يكون الأمر معقدًا للغاية أو لا يعمل. مما نحتاج إلى تعديل الكود وفقًا لذلك.

بمجرد أن نكون سعداء بالحالة الحالية للشفرة ، يجب أن نعيد وضعها على المستوى الرئيسي. هناك تغيير تم تعديله للعديد من الملفات المختلفة ، لذلك لن يكون من السهل إعادة التأسيس. ربما يمكننا تعديل التغيير لإجراء تغييرات أقل ، لذلك من الأسهل إعادة تحديد القاعدة.

اليكس

mxplusb @ kesmit13 تمت https://go-review.googlesource.com/c/go/+/133946/6

تضمين التغريدة

قلقي الحالي بشأن الكود ، أنه من غير الواضح كيفية استخدامه. ما الأمر الذي تديره؟ كيف هي بيئتي تحتاج إلى الإعداد؟

أوافق على ضرورة إضافة الوثائق حول كيفية استخدام هذا. لست متأكدًا تمامًا من مكان وضعه ، اسمح لي أن أعرف إذا كانت لديك أفكار. هل يجب أن تندرج تحت وثائق cmd / go للبناء / التشغيل عبر MSVC ، أو إذا كان يجب أن تكون موجودة ضمن وثائق CGO ، أو ربما في مكان آخر تمامًا؟

لا تستخدم الكثير من الاختبارات دول مجلس التعاون الخليجي. عندما يتم إجراء اختبارات الحزمة مرتين دون سبب ، يعد مضيعة لوقت الأشخاص / الكمبيوتر. كما ترى من # 20982 (تعليق) تم تشغيل اختبارات أرشيف / حزمة مضغوطة مرتين - لا أرى حاجة للتشغيل الثاني.

لست متأكدًا من كيفية ترتيب ذلك ، ولكن ربما يجب عليك استبدال اختبار استدعاء أداة go tool dist في run.bat للقيام فقط بمجموعة مختارة من الاختبارات اللازمة لاختبار بناء MSVC. انظر ، على سبيل المثال ، اذهب إلى اختبار توزيع الأدوات - h لمعرفة كيفية تحديد بعض الاختبارات المحددة فقط. bradfitz ربما يمكننا إنشاء علامة أو متغير بيئة يخبر الأمر dist بتشغيل اختبارات MSVC المحددة.

يتضمن التغيير بالفعل متغير بيئة تمت إضافته إلى dist لإعلامه بأننا نقوم بأشياء MSVC "GO_TEST_TESTINGMSVC" على ما أعتقد. ما لست متأكدًا منه هو كيف سنقوم بتصفية الاختبارات التي سيتم إجراؤها على الأشياء التي يمكن أن تؤثر فقط MSVC إذا لم نقم بإجراء جميع الاختبارات مرتين. من المحتمل أن يقتصر الأمر على الاختبارات ذات الصلة بـ CGO ، لكنني أعتقد أن هناك اختبارات CGO في كل مكان ولا أعرف ما إذا كان Dist لديه آلية لتصفية هؤلاء؟

لست متأكدًا تمامًا من مكان وضعه ، اسمح لي أن أعرف إذا كانت لديك أفكار.

أعتقد قبل تحديث أي وثائق ، يجب عليك فقط وصف كيفية إنشاء كود Cgo باستخدام MSVC هنا. بالنسبة إلى mxplusb و @ kesmit13 حتى يتمكنوا من تجربة تغييراتك.

على سبيل المثال ، لاستخدام gcc لإنشاء كود Cgo ، فإن I

1. اضبط٪ PATH٪ الخاص بي ليشمل gcc.exe
2. build Go أولاً بتشغيل make.bat من دليل %GOROOT%\src
3. استخدم الأوامر القياسية go build و go install

كيف أفعل الشيء نفسه مع MSVC؟

ما لست متأكدًا منه هو كيف سنقوم بتصفية الاختبارات التي سيتم إجراؤها على الأشياء التي يمكن أن تؤثر فقط MSVC إذا لم نقم بإجراء جميع الاختبارات مرتين. من المحتمل أن يقتصر الأمر على الاختبارات ذات الصلة بـ CGO ، لكنني أعتقد أن هناك اختبارات CGO في كل مكان ولا أعرف ما إذا كان Dist لديه آلية لتصفية هؤلاء؟

سأبدأ بدليل٪ GOROOT٪ \ misc \ cgo. أيًا كان المصدر الذي يمكنك بناؤه هناك ، يجب عليك بناءه. أي شيء فوق ذلك يعود إليك.

اليكس

cchamplin آسف للتأخير في هذا ، سأبذل قصارى جهدي لاختباره هذا الأسبوع

مرحبًا ، أيها الناس آسفون على التأخر في الحفلة ... يمكنني أن أحاول الإجابة عن الأسئلة المتعلقة بوظيفة MSVC أو توجيهك إلى الأشخاص الذين يمكنهم ذلك. لقد قرأت المحادثة ، لكن لسوء الحظ ، لست على دراية كافية بـ go لفهم وظائف دول مجلس التعاون الخليجي المطلوبة والتي قد تكون مفقودة أو لا تكون مفقودة من MSVC.

مرحبا يا رفاق،
هل تم إصدار هذه الميزة في Go 1.14؟
في حالة إصدارها ، يرجى مشاركة أي مستندات متاحة للاستفادة منها.
إذا لم يتم إصداره بعد ، فهل هناك أي فكرة عن موعد إصداره؟
تنتظر بفارغ الصبر دعم MSVC.
شكرا لك مقدما :)

مرحبًا ، لم يرد أحد على طلبي للحصول على مزيد من المعلومات ، لذلك لست متأكدًا مما هو مطلوب. هل يمكن لأحد أن يملأني من فضلك؟

لسوء الحظ ، لا أعرف ما إذا كان هناك أي شخص يعمل بنشاط على حل هذه المشكلة.

مرحبًا ، لم يرد أحد على طلبي للحصول على مزيد من المعلومات ، ...

مرحبا manbearian

أي طلب هذا؟ ما هي المعلومات اللي تريدها؟

اليكس

لقد تم وضع علامة لي سابقًا في هذا الموضوع للحصول على معلومات ، لكنني لا أعرف ما الذي يبحث عنه الأشخاص ولم أتمكن من مساعدتي. إذا لم تكن هناك حاجة إلى مساعدة ، فهذا رائع. فقط من فضلك أعلمني.

فقط من فضلك أعلمني.

تضمين التغريدة

شكرا لعرضك. أنا لا أعرف من وضع علامة عليك. إذا كانوا لا يزالون بحاجة إلى المساعدة ، فسيتم وضع علامة عليك مرة أخرى.

اليكس

إذا لم يتم إصداره بعد ، فهل هناك أي فكرة عن موعد إصداره؟
تنتظر بفارغ الصبر دعم MSVC.

MustafaHosny اللهم امين

الشفرة موجودة وكاملة ؛ أعتقد أن الشيء الوحيد الذي يعيق هذا الأمر حقًا هو اختبار الأشخاص للتغييرات وتقديم التعليقات حتى يمكن مراجعتها والموافقة عليها بشكل صحيح. أنا متردد في إعادة وضع التغييرات على رأس المدير الحالي. لقد قمت بذلك من 5 إلى 6 مرات وهي تستغرق وقتًا طويلاً للغاية ، وبعد ذلك لم أحصل على أي اختبار / تعليقات. ما لم تكن هناك أطراف أخرى على استعداد للمشاركة في اختبار هذا ، قد تكون القضية ميتة في الماء.

ما لم تكن هناك أطراف أخرى على استعداد للمشاركة في اختبار هذا ، قد تكون القضية ميتة في الماء.

cchamplin الاعتماد علي لاختبار / تصحيح التغييرات الخاصة بك. ليس لدي خبرة في الانتقال إلى سلسلة الأدوات ولكني قمت بمراجعة التزاماتك ويبدو أنها منظمة وموثقة بشكل جيد.

cchamplin رائع أن نسمع أن جزء التنفيذ قد اكتمل.
أنا مهتم بالمشاركة في جزء الاختبار ، لكنني مبتدئ في GoLang وأيضًا متعلم جيد في windows apis (بدأ قبل أسابيع قليلة). كنت أخطط للعمل مع windows api في MS C ++ حيث يبدو أن الكثير من الموارد الرسمية متاحة لذلك. ولكن بعد ذلك بدأت في البحث عن لغة (لبرمجة نظامي) حيث يمكنني استخدامها لبرمجة نظام متعدد المنصات وأنا معجب بـ GoLang. مستعد دائمًا للمساهمة من نهايتي وفي حاجة ماسة إلى التوجيه.

cchamplin إذا

cchamplin أيضًا ، لقد بحثت في CLs الخاصة بك ولم أشاهد أيًا منها لأداة cgo لذلك بدأت في التصحيح الخاص بي. هل هناك أي عمل سابق؟

تضمين التغريدة

cchamplin أيضًا ، لقد بحثت في CLs الخاصة بك ولم أشاهد أيًا منها لأداة cgo لذلك بدأت في التصحيح الخاص بي. هل هناك أي عمل سابق؟

لست متأكدًا مما إذا كنت أفهم أم لا ، على https://go-review.googlesource.com/c/go/+/133946/6 ، تلمس العديد من الالتزامات ذات الصلة مباشرة جزء cgo من Go في بعض السعة.

ccahoon حسنًا ، يجب أن

تضمين التغريدة

أرغب في إسقاط شرط mingw64 من بعض مشاريعي في العمل

لمعلوماتك فقط. ال

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

التغيير لا يزال بحاجة إلى Mingw للعمل. ستحتاج إلى تثبيت أدوات Mingw و MSVC لاستخدام تغيير cchamplin .

اليكس

cchamplin ، لماذا لا تزال هناك حاجة إلى Mingw؟ ما هو المطلوب لإزالة هذه التبعية؟

تضمين التغريدة في الوقت الحالي ، يتعين علينا استخدام MSYS2 (الذي يتضمن mingw64) لأن عملية البناء التي لا تعتمد على MSVC تتطلب أدوات آلية. اسقاط ذلك سيكون رائعا ولكن أيضًا كما قال cglong ، لست متأكدًا من سبب هذا يتطلب أيضًا mingw64.

ericlagergrencglong CGO يحتاج إلى جمع ويكون نوع المعلومات المتاحة حول رمز C أنه يجري تجميع معها. يوجد في GCC علامة ستخرج بيانات النوع بتنسيق قابل للتحليل بسهولة. MSVC على حد علمي لا يحتوي على الوظيفة اللازمة لتقديم نفس المعلومات. لن يتطلب بناء الأدوات أثناء التشغيل فقط رمزًا لشفرة lex / parse C و C ++ ولكن أيضًا لفهم وتقييم توجيهات ما قبل المعالج. سيكون مشروعًا كبيرًا إلى حد ما لبناء مثل هذا الشيء في Go. ربما توجد مكتبة متاحة بالفعل في مكان ما على الرغم من أنه يمكننا معرفة كيفية اعتمادها؟

cchamplin مسكتك ، هذا ما كنت

يحتاج CGO إلى جمع معلومات من النوع وإتاحتها حول كود C الذي يتم تجميعه باستخدامه. يوجد في GCC علامة ستخرج بيانات النوع بتنسيق قابل للتحليل بسهولة. MSVC على حد علمي لا يحتوي على الوظيفة اللازمة لتقديم نفس المعلومات.

ربما يكون manbearian قادرًا على تقديم بعض المؤشرات هنا؟

لن أقول إن دول مجلس التعاون الخليجي تصدر بيانات نوع الإخراج بتنسيق خاص. يصدر بيانات تصحيح أخطاء DWARF المخصصة لمصححات الأخطاء ، ويقرأ cgo تلك البيانات باستخدام حزمة debug / dwarf. من المفترض أيضًا أن MSVC يحتوي على تنسيق تصحيح. إذا تم توثيق هذا التنسيق في أي مكان ، فيمكننا قراءته باستخدام cgo تمامًا كما نفعل مع بيانات DWARF.

ianlancetaylor MSVC يمكنه إرسال ملفات PDB. راجع https://github.com/Microsoft/microsoft-pdb

FWIW ، قراءة إخراج تصحيح MSVC هو ما كنت أتحدث عنه عندما ذكرت أداة cgo في https://github.com/golang/go/issues/20982#issuecomment -648462003

لن أقول إن دول مجلس التعاون الخليجي تصدر بيانات نوع الإخراج بتنسيق خاص. يصدر بيانات تصحيح أخطاء DWARF المخصصة لمصححات الأخطاء ، ويقرأ cgo تلك البيانات باستخدام حزمة debug / dwarf. من المفترض أيضًا أن MSVC يحتوي على تنسيق تصحيح. إذا تم توثيق هذا التنسيق في أي مكان ، فيمكننا قراءته باستخدام cgo تمامًا كما نفعل مع بيانات DWARF.

تضمين التغريدة
لذلك نحن بحاجة إلى بيانات DWARF ، وهي جزء كبير منها. ومع ذلك ، يمكننا نظريًا الحصول على نفس المعلومات من بيانات PDB.

ما كنت أشير إليه على وجه التحديد ، على الرغم من ذلك ، لم يكن فقط بيانات DWARF التي تنتجها دول مجلس التعاون الخليجي ولكن ناتج مجلس التعاون الخليجي -E -dM الذي ينتج كل # تعريف بعد حدوث المعالجة المسبقة. من الممكن أن يوفر PDB بمفرده نفس المعلومات ... ما أشك فيه هو ما إذا كنا سنكون قادرين على إجبار MSVC على إغراق معلومات تصحيح الأخطاء / معلومات النوع بأي صفة دون الحاجة إلى تجميعها فعليًا الرمز. في الوقت الحالي ، يقوم CGO بفعل ذلك بالضبط مع دول مجلس التعاون الخليجي.

من الذاكرة ، يجب أن ينبعث / EP / d1PP شيئًا مشابهًا لـ -E -dM.

من الذاكرة ، يجب أن ينبعث / EP / d1PP شيئًا مشابهًا لـ -E -dM.

إذا كان الأمر كذلك ، فسيكون ذلك ممتازًا ، أفترض أن / d1PP هي علامة غير موثقة؟ لم أره من قبل. سيؤدي ذلك فقط إلى ترك الحصول على معلومات من النوع المكافئ في وقت مبكر.

cchamplin نعم ، إنه غير موثق. يبدو أن الكثير من أعلام / dXXX. إن استخدام أعلام غير موثقة أمر مؤسف ، لكن (IMO) لا يبدو أنه خطيئة على نظام Windows على الأقل. رأيت مطوري MSVC STL يتحدثون عنه في سلسلة رسائل reddit ، ولكنه أيضًا عبر الإنترنت أيضًا.

هل يمكن لأي شخص أن يعطيني ملخصًا قصيرًا للحالة الحالية لدعم MSVC؟ أنا لا أفهم الكثير من كل هذه الأشياء ذات المستوى المنخفض من المترجم. لدي فقط مكتبة go التي أريد استخدامها من C # / UWP - وهي تعمل بالفعل مع go build و buildmode c-shared. ولكن: لن يتم قبول هذا التطبيق من قبل متجر Windows لأن DLL الذي تم إنشاؤه من go يفقد بعض علامات المترجم / الرابط التي (أفترض) لا يمكن تعيينها إلا بواسطة MSVC-toolchain.

إذن: كيف يمكنني اختبار هذا هنا؟ هو موضع تقدير أي نصيحة! شكرا لك!

لن يتم قبول هذا التطبيق من قبل متجر Windows لأن DLL الذي تم إنشاؤه من go يفتقد بعض علامات المترجم / الرابط التي (أفترض) لا يمكن تعيينها إلا بواسطة MSVC-toolchain.

TopperDEL هل يخبرك متجر Windows عن أعلام المترجم المفقودة؟ إذا كان mingw-64 يدعمهم ، فيمكنك دائمًا استخدام -extldflags مع العلامات الصحيحة عند إنشاء dll.

qmuntal نعم ، يفعلون:
"قم بتطبيق خيارات الرابط المطلوبة - SAFESEH و DYNAMICBASE و NXCOMPAT و APPCONTAINER - عند ربط التطبيق."

لقد حاولت بالفعل
go build -ldflags="-s -w '-extldflags=-Wl,--dynamicbase,--high-entropy-va'" -o storj_uplink.dll -buildmode c-shared

لكن هذا لم يغير أي شيء فيما يتعلق بتقديم المتجر. ومن فهمي ، فإن السلامة على الأقل هي أمر خاص بـ MSVC ، أليس كذلك؟

"قم بتطبيق خيارات الرابط المطلوبة - SAFESEH و DYNAMICBASE و NXCOMPAT و APPCONTAINER - عند ربط التطبيق."

لا أعرف أي طريقة سهلة لتمكين أعلام SAFESEH أو APPCONTAINER في Mingw-w64 ، ربما يمكن لهذا المشروع https://github.com/status-im/mingw-windows10-uwp أن يمنحك بعض الإرشادات.

من ناحية أخرى ، سيتم تمكين DYNAMICBASE و NXCOMPAT افتراضيًا في go 1.16 (انظر # 41421) ولكن يمكن استخدامها بالفعل مع -extldflags كما هو مذكور ، في الواقع أقوم بذلك لبعض المشاريع.

qmuntal شكرا! لذلك على الأقل يجب أن تكون علاماتي الإضافية أعلاه صحيحة؟
سألقي نظرة على mingw لنظام التشغيل windows 10-uwp.