Go: cmd/link: msvc 개체 파일 지원

/cc @alexbrainman

@xoviat 어떤 문제가 있습니까? 여기에서 재현할 수 있어야 합니다. 따라서 이것을 재현하기 위해 따라야 할 모든 단계를 제공하십시오.

감사합니다

알렉스

추신: 7월 말까지는 컴퓨터가 없습니다. 그럼 이것부터 볼게요.

당신이 겪고 있는 문제는 무엇입니까?

아직 시도하지 않았지만 msvc 개체 파일에서 c 함수를 go 링커와 .syso로 연결하여 구체적으로 호출하고 싶습니다. 내가 읽은 모든 것은 이것이 가능하지 않다는 것을 나타내지만 발생하는 특정 오류를 재현하는 절차를 만들 것입니다.

특히 go 링커를 사용하여 .syso로 연결하여 msvc 개체 파일에서 c 함수를 호출합니다.

이것을 DLL로 빌드하고 DLL 내부에서 사용해 보셨습니까?

발생하는 특정 오류를 재현하는 절차를 만들 것입니다.

제발. 감사합니다.

알렉스

이것을 DLL로 빌드하고 DLL 내부에서 사용해 보셨습니까?

그것이 사실 나의 원래 계획이었다. swig를 사용하고 있으므로 생성된 c 코드를 별도로 컴파일한 다음 DLL 내보내기로 함수를 다시 작성하는 것이 그리 편리하지 않습니다. 어렵지는 않지만 gcc를 사용하는 워크플로가 go generate; go build 불과할 때 성가신 일입니다.

알겠습니다. 절차가 있습니다. 다음 파일로 시작하십시오.

안녕하세요.고:

package main

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

func main() {
    C.hello()
}

안녕하세요.c:

#include <stdio.h>

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

그런 다음 다음 명령을 실행합니다(경로에 msvc 사용).

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

결과:
Warning: corrupt .drectve at end of def file

생성된 파일을 실행할 때:

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

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

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

내 PC에 cl 명령이 설치되어 있지 않습니다. msvc는 어떻게 설치하나요?

감사합니다.

알렉스

여기에 "빌드 도구 2017"이 필요합니다. Microsoft는 이제 상업적 개발이 아닌 한 누구나 Visual Studio를 무료로 사용할 수 있습니다. 너무 번거로우시면 오브젝트 파일만 주시면 됩니다.

C++만 문제가 아니었다면 나는 이것에 대해 걱정할 필요가 없었을 것입니다. 하지만 그렇기에 고통은 계속된다...

여기에 "빌드 도구 2017"이 필요합니다.

알았어요. 감사합니다.

너무 번거로우시면 오브젝트 파일만 주시면 됩니다.

예, hello.obj를 어딘가에 게시하십시오.

이것에 대해 좀 더 생각하십시오. 실제로 gcc를 사용하여 msvc 컴파일러로 컴파일된 개체 파일을 연결하고 있습니다. 운동을 시도하고 수행할 수 있지만 "go build" 단계를 hello.obj를 C 프로그램에 연결하는 gcc로 대체합니까? 아마도 이전에 수행된 적이 있을 것입니다. 나는 우리가 그것을 할 수 있는 방법을 안다면 바둑에서도 비슷한 일을 할 수 있을 것이라고 생각한다.

알렉스

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는 Windows에서 gcc 링커(lld 아님)를 사용합니다.

개체 파일은 여기: https://github.com/xoviat/msvcgo/blob/master/hello.syso

8월에 집에 가면 해봐야겠습니다. 감사 해요.

알렉스

Go는 Windows에서 gcc 링커(lld 아님)를 사용합니다.

알아요. 그러나 lld는 msvc 개체 형식의 최고의 오픈 소스 문서입니다.

실제로 ld에서 동일한 오류가 발생하므로 오류는 확실히 ld에서 발생합니다.

실제로 ld에서 동일한 오류가 발생하므로 오류는 확실히 ld에서 발생합니다.

예. msvc로 부분을 컴파일하고 gcc로 연결하여 C 프로그램을 빌드하는 방법을 찾아야 합니다.

알렉스

내 무지를 용서하지만 정확히 gcc 연결은 무엇입니까? go 링커의 출력을 연결하고 있습니까?

elf로 변환하기 위해 오브젝트 파일에서 objconv 실행:

objconv -felf hello.obj hello.syso

이제 다음과 같은 오류가 발생합니다.

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

아마도 stdio가 한계가 있습니까?

내 무지를 용서하지만 정확히 gcc 연결은 무엇입니까? go 링커의 출력을 연결하고 있습니까?

2개의 프로그램을 사용하여 Go 프로그램을 빌드합니다.

• 컴파일러는 .go 파일(당시 1개 패키지)을 %GOPATH%/pkg 디렉토리에 저장된 개체 파일로 변환합니다.
• %GOPATH%/pkg 아래의 개체 파일에서 최종 .exe 파일을 빌드하는 링커.

때때로(패키지 중 하나가 Cgo를 사용하는 경우) Go 링커는 외부 링커를 호출하여 C로 구현된 모든 비트를 찾습니다. C 코드에서 printf를 호출한다고 상상해 보십시오. C printf 컴파일된 코드는 Go 실행 파일의 일부여야 하지만 Go 링커는 어디서 얻을 수 있는지 모릅니다. 따라서 Go 링커는 해당 코드를 포함하기 위해 외부 링커를 호출합니다.

Current Go는 gcc 컴파일러/링커를 사용하여 C 코드를 컴파일하고 연결합니다(우리는 mingw gcc 사용). 다른 컴파일러(Microsoft)로 C 코드를 컴파일하려는 경우 컴파일러가 만든 모든 외부 C 코드를 찾기 위해 해당 링커(Microsoft)를 사용해야 합니다.

그래서 gcc 링커를 사용하자고 제안한 것이 잘못된 것 같습니다. 일반적인 시나리오의 경우 Microsoft 컴파일러와 링커를 모두 사용해야 합니다. Microsoft 링커가 입력으로 요구하는 것이 무엇인지 파악하고 일치시켜야 합니다.

C 코드에 외부 코드가 없는 경우 MC 링커 없이 벗어날 수 있습니다. (2개의 정수를 더하는 것과 같은) 정말 간단한 C 프로그램을 시도해 보십시오. 위에서 설명한 대로 작동할 수 있습니다.

알렉스

아마도 stdio가 한계가 있습니까?

해당 코드를 찾으려면 Microsoft 링커를 호출해야 한다고 생각합니다.

알렉스

확신은 못하지만

objconv -felf hello.obj hello.syso

아마도 elf 대신 coff 또는 omf를 시도해야합니까?

아마도 elf 대신 coff 또는 omf를 시도해야합니까?

@xoviat 예, .obj 파일을 elf로 변환하면 안 됩니다. Windows 버전의 gcc는 다른 Windows 컴파일러와 마찬가지로 pe/coff 파일을 생성합니다.

알렉스

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] WSAGetOverlapped 결과
• [x] _cgo_18b6f6fc815b_Cfunc_hello
• [x] x_cgo_init --> msvc_windows_amd64.c
• [x] x_cgo_thread_start --> msvc_windows_amd64.c
• [x] x_cgo_sys_thread_create --> msvc_windows_amd64.c
• [x] x_cgo_notify_runtime_init_done --> gcc_libinit_windows.c
• [x] x_cgo_set_context_function --> gcc_libinit_windows.c

좋아, 예상보다 빨리 여기로 이동해!

전체: asm_amd64.s 는 go의 어셈블러(이상한 어셈블리 포함) 또는 gcc의 어셈블러에 의해 어셈블됩니까?

gcc가 그것을 어셈블하지 않을 것 같습니다. 즉, 아마도 어셈블리로 갈 것입니다. 그런 다음 문제는 go 어셈블러를 사용하여 개체로 어셈블하는 방법입니다.

의도는 runtime/cgo/asm_amd64.s가 Go 개체로 어셈블되고 cmd/link가 다른 모든 Go 개체와 함께 단일 시스템 개체로 연결되고 시스템 링커가 해당 단일 시스템 개체와 모든 개체를 연결하는 것입니다. cgo 종속성을 최종 프로그램에 추가합니다.

테스트 목적으로 지금 해당 개체를 어셈블하는 방법이 있습니까? go를 제외하고 gcc -c asm_amd64.s 와 같습니까?

의도는 runtime/cgo/asm_amd64.s가 Go 개체로 어셈블되고 cmd/link가 다른 모든 Go 개체와 함께 단일 시스템 개체로 연결되고 시스템 링커가 해당 단일 시스템 개체와 모든 개체를 연결하는 것입니다. cgo 종속성을 최종 프로그램에 추가합니다.

지금까지 다음 개체를 찾았습니다.

• go.o : 분명히 go 도구 체인에서
• _cgo_.o : gcc에서 생성, 사용할 수 없음
• 000000.o : gcc에 의해 생성, 사용할 수 없음
• 000001.o : 업데이트: 실제로 go 링커에 의해 생성되지만 gcc 기호가 포함되어 있습니다. 쓸 수 없는.

go.o 는 가장 큰 개체입니다.

@ianlancetaylor

나는 당신이 말한 것이 옳다고 생각하지 않습니다. crosscall_amd64 는 000001.o에 있지만 해당 파일에는 "모든 go 코드"가 없습니다.

000001.o:     file format pe-x86-64

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

이 파일은 분명히 프로세스에서 너무 늦은 gcc에 의해 생성되었습니다.

테스트 목적으로 지금 해당 개체를 어셈블하는 방법이 있습니까? go를 제외하고 gcc -c asm_amd64.s와 같습니까?

asm_amd64.s는 런타임 패키지의 일부입니다. 다음과 같이 "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 파일에 정의되어 있습니다. 해당 파일은 모든 런타임/cgo/gcc_* 파일과 마찬가지로 GCC에 의해 컴파일됩니다. 따라서 모든 Go 코드가 포함된 단일 go.o 파일로 결합되지 않습니다. 이전에 설명했던 파일 runtime/cgo/asm_amd64.s는 crosscall2 기호를 정의합니다. go.o에서 해당 기호를 찾을 수 있습니다.

감사 해요.

좋아, 액세스 위반 시 충돌하는 실행 파일을 링크하는 데 성공했습니다.
go.runtime.rt0_go+5F --> go.__acrt_stdio_initializer.

그것이 지금 내가 가진 모든 시간입니다. 이 부분은 나중에 다시 설명하겠습니다.

@alexbrainman 맞습니다.

@alexbrainman 계속하려면 MSVC가 필요합니다. 도움이 필요한지 알려주십시오.

계속하려면 MSVC가 필요합니다.

나는 이것을 설치하고있다 https://www.visualstudio.com/downloads/#build -tools-for-visual-studio-2017

설치한 후에는 어떻게 해야 합니까?

알렉스

설치가 완료되면 go 라이브러리인 "libgo"를 빌드해야 합니다. cgo 폴더 에서 다음 파일을 복사

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

MSVC와 호환되도록 gcc_windows_amd64.c를 조정해야 합니다. 다음과 같이 함수를 수정합니다.

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

    ThreadStart ts;

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

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

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

    crosscall_amd64(ts.fn);
}

"build.bat"라는 이 모든 파일이 있는 폴더에 새 파일을 만듭니다.

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

ren gcc_amd64.o gcc_amd64.obj

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

폴더가 요청한 대로 구성되면 알려주십시오.

그건 그렇고, 이 작업과 go에 대해 모두 감사합니다. 여러분은 정말 마법 같은 언어를 만들었습니다.

폴더가 요청한 대로 구성되면 알려주십시오.

https://github.com/golang/go/issues/20982#issuecomment -327365063에 설명된 대로 libgo.lib를 빌드할 수 있었습니다.
다음에 무엇을 해야 합니까?

알렉스

자, 이제 다음 파일이 필요합니다.

• libgo.lib
• 찐득 찐득 한 것
• 안녕하세요.cgo2.o
• 안녕하세요.c

hello.c는 다음과 같습니다.

#include <stdio.h>

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

hello.cgo2.o 및 go.o 를 얻으려면 다음 파일로 시작해야 합니다.

package main

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

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

"hello.go"라고

$ env:TMP 에서 파일을 지속적으로 복사하는 powershell 스크립트를 설정하십시오.

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

그런 다음 폴더에서 hello.c 및 hello.go 와 함께 go build 를 실행합니다. 복사된 위치에서 필요한 파일을 복구할 수 있어야 합니다.

위에서 지정한 파일이 있으면 다음을 사용하여 빌드할 수 있습니다.

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

질문이 있으면 알려주세요.

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

그러면 go.exe 실행 파일이 생성되지만 실행되지 않습니다. 거기에는 합리적인 asm 코드가 없습니다. 첫 번째 지시는 아무데도 뛰어들지 않습니다. 그냥 엉망입니다.

어쩌면 정말 간단한 것부터 시작해야 할 수도 있습니다. "INT $3"을 실행하고 다른 것은 없는 단일 asm 함수로 asm 파일(Go asm 파일)을 작성하십시오. 그리고 그것으로부터 실행 가능한 프로그램을 구축해 보십시오. 프로그램은 맨 처음에 여러분의 기능을 실행해야 합니다.

Go 도구를 먼저 사용하고(필요한 경우 gcc를 사용하여) 빌드한 다음 MSVC를 사용하여 동일한 작업을 시도합니다.

알렉스

알렉스, 도와주셔서 감사합니다. 나는 그 일을 할 것이다.

나는 내 자신의 참조를 위해이 두 기사를 여기에 첨부 할 것입니다. 그렇지 않으면 더 이상 업데이트가 없습니다.

실제로 msvc 라이브러리만 사용하는 상당히 복잡한 go 프로그램이 작동하고 있습니다. 바닐라 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

이상적으로는 마찰을 최소화하기 위해 link.exe 와 호환되도록 개체 파일을 사전 처리하는 go 프로그램을 작성하지만 이는 일종의 확장 목표입니다.

포인터 주셔서 감사합니다. 곧 프로세스를 기록하겠습니다.

불행하게도 나는 연결을 통해 수행 할 수 있다고 생각하지 않습니다 link.exe 우리가에서 초기화되지 않은 데이터를 방출하는 GCC를 변경하지 않는 한 .data 대신 섹션 .bss 섹션을 -하지만 우리는 할 수 .bss 섹션을 인식하도록 llvm-lld 를 확실히 수정하십시오.

_cgo_.o 와 _all.o 별도로 처리해야 합니다. 몇 가지 질문이 있습니다.

(1) _cgo_.o 는 go 런타임을 포함하지 않기 때문에 최종 실행 파일이 아닌 것 같습니다. 컴파일러가 구조체의 정의를 파악하기 위해 DWARF 기호를 보는 것처럼 보입니다. 문제는 외부에서 여러 라이브러리, 특히 msvc에서 생성된 라이브러리와 연결하려는 경우 실행 파일을 생성하기 어렵다는 것입니다.

이 단계를 피할 수 있습니까?

(2) 현재 GCC에서 -Wl,-r 를 전달하여 GNU ld 를 사용하여 모든 개체 파일을 _all.o 연결합니다. 이것은 (1) 다른 링커에 이 기능이 없는 것 같고 (2) 명령이 CGO_LDFLAGS 영향을 받기 때문에 문제가 됩니다. 예를 들어 다음 명령은 잘못된 결과를 생성합니다.

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

번들된 개체 파일 대신 실행 파일을 생성합니다.

생성된 .a 에 모든 오브젝트 파일을 직접 넣는 것으로 이 단계를 전혀 피할 수 있습니까?

@zooba 이 패치로 MSFT가 link.exe 를 업데이트할 수 있는 기회는 무엇입니까?

불행히도 .bss 섹션 대신 .data 섹션에서 초기화되지 않은 데이터를 내보내도록 gcc를 변경하지 않는 한 link.exe를 통해 링크를 수행할 수 있다고 생각하지 않습니다. 그러나 .bss 섹션을 인식하도록 llvm-lld를 확실히 고칠 수 있습니다. (내가 한 일이다).

MSFT 업데이트하지 않는 가정 그래서 link.exe (가능성이있는), 그와 오브젝트 파일을 컴파일하는 것이 좋을 것입니다 cl.exe 보다는 gcc .

_cgo_.o 는 go 런타임을 포함하지 않기 때문에 최종 실행 파일이 아닌 것 같습니다.

맞습니다. 기본적으로 두 세트의 오브젝트 파일(제 생각에는)이 결국 함께 연결됩니다. go.o 파일(IIRC)에는 모든 go 코드 + 런타임이 포함되고 다른 개체에는 C 코드가 포함됩니다. 두 개체 집합 사이를 이동하는 어셈블리 루틴이 있습니다.

또한 Unix 어셈블리 파일을 컴파일하려면 clang 가 필요합니다.

우리의 목적을 위해 -Wl,-r 는 lib.exe [object files] /OUT:obj 를 실행하는 것과 같습니다. 이 옵션은 "증분 링크"를 의미하며, 이는 "일부 입력 파일을 가져오고 일부 작업을 수행한 다음 다른 개체 파일을 내보냅니다."를 의미합니다. 지금 "일부 작업" 부분에 대해 걱정하지 않는다면 "일부 입력 파일 및/또는 개체 파일을 가져오고 다른 개체 파일을 뱉어내십시오"라는 요구 사항을 받아들일 수 있습니다. 도서관.

-fno-zero-initialized-in-bss 옵션을 사용하여 .bss 섹션이 아닌 .data 섹션에 변수를 넣지 않도록 GCC에 지시할 수 있습니다.

팁에서 우리는 cgo 코드를 작성할 때 더 이상 -Wl,-r 사용하지 않습니다.

cmd/link가 MSVC 개체 파일을 .syso 파일로 사용하기 위해 이해할 필요는 없습니다. 이러한 파일은 어쨌든 외부 링커로 전달됩니다. 그래서 여기서 필요한 것은 MSVC 링커를 외부 링커로 호출하는 것인데, -extld 옵션을 사용하여 수행할 수 있어야 합니다. 이미 그렇게 하고 계시다면 죄송합니다. 이 경우 무엇이 실패합니까?

이미 그렇게 하고 계시다면 죄송합니다. 이 경우 무엇이 실패합니까?

IIRC, gcc에서 생성된 객체의 link.exe barfs.

사실, CC 환경 변수를 적절하게 설정하여 MSVC C의 컴파일러도 사용해야 합니다. 단일 링크에서 GCC 개체와 MSVC 개체를 결합하는 데 작동하지 않을 것이라고 생각합니다.

그러나 런타임 C 라이브러리가 미리 컴파일되는 문제가 발생합니다. 그리고 재컴파일하려고 하면 cl 가 유닉스 어셈블리를 컴파일할 수 없다는 문제가 발생합니다. 그래서 런타임 라이브러리의 일부를 이식하고 링크를 시도합니다. 이것이 제가 하고 실패한 것입니다.

그 과정에서 cl 는 코드의 핵심 부분을 잘못 컴파일합니다. 이 문제를 수정하기 위한 제 생각은 MSVC 코드를 플랫 C API를 사용하여 DLL로 분리한 다음 작동을 멈출 때까지 더 많은 런타임 라이브러리를 점진적으로 컴파일하는 것입니다.

문제를 해결하기 위한 @haohui 의 아이디어는 달랐습니다. 그는 문제의 근본을 고치기보다는 링커를 패치하여 문제를 해결했습니다. 분명히 그는 나보다 더 많은 성공을 거뒀지만, 나중에 생각해 보면 그의 접근 방식이 나보다 성공할 가능성이 더 높기 때문일 것입니다.

이 시점(IMHO)에서 내가 권장하는 것은 작동을 멈추거나 gcc 코드가 남지 않을 때까지 cl 를 사용하여 더 많은 런타임 라이브러리를 점진적으로 컴파일하는 것입니다. 그러면 문제가 어디에 있는지 정확히 알 수 있습니다.

그리고 링커 패치를 사용하면 DLL이 필요하지 않습니다.

llvm-lld의 패치는 https://bugs.llvm.org/show_bug.cgi?id=35283 에서 사용할 수 있습니다.

시간을 할애하여 예시를 제공하겠습니다.

+1 @haohui 진행해 주셔서 감사합니다!

@haohui 패치가 적용되는 llvm 버전은 무엇입니까? 패치를 사용하는 방법과 MSVC 파일에 링크하는 방법에 대한 지침이 있습니까?

_cgo_.o 및 _all.o 파일과 관련하여 동일한 문제가 있었으므로 이 문제에 대한 수정 사항이 다른 문제에 대한 수정 사항일 수도 있습니다. https://github.com/golang/go /이슈/17014

모든 작업에 감사드립니다. 좋은 진전이 이루어지고 있는 것 같습니다. 새로운 기능은 Go 1.11까지 고정되므로 이정표가 변경됩니다.

그래서 나는 어젯밤에 이것에 뛰어 들었다. msvc:cl 을 통해 모든 것을 빌드한 다음 msvc:link를 통해 모든 것을

따라서 msvc:cl이 C99를 완전히 지원하지 않는 것과 같은 단순한 문제 외에도(지금은 _Complex 유형을 처리할 수 없습니다). go 내부에서 빌드한 PE 라이브러리와 msvc에서 빌드한 라이브러리를 결합하는 데는 보다 체계적인 문제가 있습니다. 특히 msvc:link 는 .bss 세그먼트를 날려버립니다(이 데이터를 .data에 던질 수 있다고 생각합니다). 이는 go assembler SB(pseudo reg)가 .bss가 이동되는 경우 잘못된 주소 지정 결과를 초래하는 것처럼 보이기 때문에 문제입니다. .

내 초기 생각은 어셈블러가 .bss 및 .noptrbss에 들어갈 항목을 각각 .data 및 .noptrdata에 배치하도록 하는 것입니다. 이것이 가능한지조차 확실하지 않습니다. 내 만지작거리는 것이 성공하지 못했고 주소 지정이 완전히 중단되었습니다.

지금은 link.exe를 사용할 수 없다고 생각합니다. lld-link.exe로 시작해야 한다고 생각합니다.

그 뒤에 있는 생각이 .bss 데이터 주위를 이동하지 않도록 lld-link를 패치할 수 있다는 것이라면 그 호소를 이해합니다. 현실적으로 목표가 실제 msvc 도구 체인을 지원하는 것이라면 내부 컴파일로 이동하여 데이터를 .bss/.noptrbss에 배치하는 문제를 해결해야 합니다.

go로 lld-link.exe를 재배포할 수 없나요? LTCG가 활성화되어 있지 않은 한 MSVC 개체 파일을 지원하는 가장 위험이 낮은 경로인 것 같습니다. 이상적이지는 않지만 리소스 제약에 직면해 있습니다.

또한 최상의 전략인 점진적인 진행을 허용합니다.

좋아요, 좋은 후속 소식이 있습니다. 점심 시간에 이 작업에 한 시간을 할애할 수 있었습니다.

현재 문제의 앞부분에서 작업한 예가 있습니다.

- hello.go:
package main

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

func main() {
    C.hello()
}

- extern.c
#include <stdio.h>

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

>ac.out.exe
Hello World from C

바이너리는 MSVC 및 Go 도구 체인으로 완전히 구축되었습니다(GCC 또는 기타 LLVM이 설치되지 않음).

결과:

• Go tools/link.exe에서 내부 어셈블리에 대한 .bss 데이터를 .data로 출력하는 것은 궁극적으로 상당히 간단했습니다.
• msvc에 대해 여러 ASM 조각을 조정해야 했습니다.
• 몇 개의 GCC #defs가 shim되었습니다.
• cgo에서 생성한 .c 파일 중 일부를 약간 조정해야 했습니다.
• 복소수는 지원되지 않는 순간에 shim해야 합니다.
• msvc 지원을 위해 빌드하거나 링크하기 위해 추가 플래그를 직접 추가해야 할 수 있으며 ldflags 등이 충분하지 않을 수 있습니다.

다음 단계:
이번 주말에 시간이 있다면 변경 사항을 포크로 가져오고 빌드/링크의 플래그 뒤에 있는 기능을 가져오는 작업을 할 것입니다. 그런 다음 PR을 검토하여 종류를 결정할 수 있도록 하겠습니다. .bss 데이터를 이동하는 것이 어딘가에 영향을 미칠 것이라고 100% 확신할 수는 없습니다.

내가 생각할 수있는 유일한 단점은 바이너리의 크기를 날려 버릴 것이라는 것입니다. 그러나 괜찮을 것입니다.

괜찮아!

이거 정리하는데 이틀 더 걸렸네요 죄송합니다. 따라서 패치의 첫 번째 초안은 여기에서 찾을 수 있습니다. https://github.com/cchamplin/go/commit/69a5cfc1dd0106fd8a2928a83e4c7001e81e89b8 :: https://github.com/cchamplin/go/tree/msvc_toolchain_support

이것은 여전히 ​​거친하지만 msvc로 코드를 성공적으로 빌드했습니다.

사람들이 지금 테스트를 시작하고 버그를 다시 보고하여 업스트림을 위한 더 나은 위치에 이를 수 있다면 정말 좋을 것입니다. 또한 누구든지 필기 시험을 치르고 싶다면 놀라운 일이 될 것입니다!

용법:

go build -compiler msvc [path]

• 복소수를 작동시킬 수 있는지 확인할 때까지 현재 복소수는 지원되지 않습니다.
• msvc 컴파일러로 go 런타임을 빌드하려고 하면 어떻게 되는지 모르겠습니다.
• gcc는 여전히 필요하고 gco가 컴파일 할 때 정의 및 유형 데이터를 얻기 위해

연결된 패치로 인해 부트스트랩 문제가 발생합니다.

@alexbrainman toolchain1 부스트래핑 단계 에서 pkg/boostrap/src/bootstrap 복사할 파일을 결정하는 방법과 위치는 무엇입니까?

cc @alexbrainman

연결된 패치로 인해 부트스트랩 문제가 발생합니다.

요즘 부트스트랩이 어떻게 작동하는지 모르겠습니다. 그러나 다른 사람들( @rsc 및 @ianlancetaylor)이 도움을 줄 수

부트스트랩이 작동하지 않는 경우 @cchamplin 이 make.bat를 어떻게 실행하는지 궁금합니다.

알렉스

@xoviat 무엇이 문제인지 모르지만 부트스트랩 디렉토리 목록은 cmd/dist/buildtool.go에 있습니다.

@alexbrainman , @ianlancetaylor , @xoviat 더 철저하게 확인했어야

부트스트랩 문제를 수정하여 https://github.com/cchamplin/go/commit/69a5cfc1dd0106fd8a2928a83e4c7001e81e89b8 분기를 업데이트했습니다. 이제 올바르게 부트스트랩해야 한다고 생각합니다.

일부 /src/internal/syscall 디렉토리를 cmd/internal/msvc로 복사해야 했습니다. 그게 큰 문제가 될까요? src/internal을 사용하지 않고 레지스트리에 액세스하는 방법을 잘 모르겠습니다.

일부 /src/internal/syscall 디렉토리를 cmd/internal/msvc로 복사해야 했습니다. 그게 큰 문제가 될까요? src/internal을 사용하지 않고 레지스트리에 액세스하는 방법을 잘 모르겠습니다.

요즘에는 어떻게 되는지 모르겠지만 소스 파일을 수동으로 복사하지 않고도 cmd/dist가 그렇게 할 수 있다고 생각합니다. 코드를 제출할 준비가 되면 Russ 또는 Ian이 도움이 될 것이라고 확신합니다.

@bradfitz 와 @ianlancetaylor 가 여기서 어떻게 진행할지 결정할 때라고 생각합니다. Go가 Microsoft 빌드 도구와 gcc를 지원하기를 원하십니까? 해당 Microsoft 도구를 빌더에 설치해야 합니다(CL 수락을 시작하기 전에 설치해야 함). 아마도 새로운 환경 변수를 도입해야 할 것입니다. 새로운 문서.

대답이 예인 경우 @cchamplin 은 https://golang.org/doc/contribute.html에 따라 코드 변경 사항을 제출해야 합니다. 그렇게 하시겠습니까? 변경 사항이 상당히 크므로 개별적으로 검토하고 제출할 수 있도록 더 작은 CL로 분할해야 합니다. 각 변경 사항은 제출되기 전에 all.bat PASS가 있어야 합니다. 첫 번째 CL 제출을 시작하기 전에 모든 CL을 볼 수 있다면 좋을 것입니다.

감사합니다.

알렉스

Go가 Microsoft 빌드 도구와 gcc를 지원하기를 원하십니까?

참고로 이 패치는 이미 진행 중인 패치가 있는 #17014도 지원합니다.

대답이 예인 경우 @cchamplin 은 https://golang.org/doc/contribute.html에 따라 코드 변경 사항을 제출해야 합니다. 그렇게 하시겠습니까? 변경 사항이 상당히 크므로 개별적으로 검토하고 제출할 수 있도록 더 작은 CL로 분할해야 합니다.

예, 그것을 깨는 것은 큰 문제가되어서는 안됩니다. 모든 코드를 정리하고, 문서를 작성하고, 테스트를 생성하는 등의 노력을 하기 전에 이것이 들어갈 가능성이 있는 항목인지 여부만 알면 됩니다.

Go가 Microsoft 빌드 도구와 gcc를 지원하기를 원하십니까?

내 생각에 대답은 예입니다. 컴파일러 자체는 VS Community에서 무료이며 완전한 Windows 지원이 없는 것은 정말 실망스럽습니다. Windows 도구 모음이 지원되지 않기 때문에 github.com/Microsoft/hcsshim 를 컴파일하기 위해 Linux 상자를 세울 필요가 없습니다.

Windows 도구 모음을 지원하지 않는 이유는 무엇입니까?

원칙적으로 MSVC 개체 파일을 지원하는 것이 좋다고 생각합니다. 건축주가 필요합니다.

내 주요 관심사는 Windows 또는 MSVC 릴리스 간에 형식이 얼마나 변경될 수 있는지입니다. 대부분의 다른 플랫폼에서 사용되는 ELF 형식은 매우 안정적입니다. 새로운 프로세서에 대한 지원을 추가하는 것 외에는 ELF 지원을 조정할 필요가 거의 없습니다. MSVC 파일 형식도 비슷하게 안정적입니까?

MSVC 도구 체인과 관련된 형식은 상당히 안정적입니다. 가장 큰 문제는 도구 자체를 지원하는 것입니다. Microsoft는 Visual Studio 릴리스 간에 항목(파일 및 레지스트리 항목)을 이동하는 경향이 있습니다. 이 대부분은 구성할 수 있지만(적어도 내가 작성한 패치에서) Visual Studio의 새 주요 버전이 릴리스될 때 Go를 변경하지 않으면 빌드 도구 체인으로 호환되지 않을 가능성이 여전히 존재합니다. 그러나 지원되는 모든 이전 버전의 Visual Studio는 계속 작동합니다.

내가 아는 한 COFF 형식은 C ABI(C++이 아님)에만 노출되면 합리적인 안정성을 갖습니다. 또한 광범위하게 문서화되어 있으며 LLVM은 참조 구현을 제공합니다.

@cchamplin 사용자가 MSVC와 연결하기 전에 vcvarsall.bat를 호출하도록 요구하는 것이 좋습니다. 이렇게 하면 유지 관리가 거의 0에 가깝게 크게 줄어듭니다.

건축주가 필요합니다.

@ianlancetaylor MSVC 개체가 의도한 대로 작동하는 것으로 입증되면 msys/cygwin 빌더와 MSVC 빌더가 모두 필요하다고 생각하십니까? 아니면 MSVC 빌더만 있어야 합니까?

일부 사람들은 cygwin 도구를 사용하는 것을 선호할 것이며 이미 작동하고 있으며 계속 작동하기를 원하므로 두 명의 빌더가 필요하다고 생각합니다.

이 스레드의 맨 아래에서 보면 MSVC 문제가 해결된 것 같습니다. 하지만 문제가 발생하면 저는 MSVC 팀에 있습니다. github 또는 이메일([email protected])에서 저에게 핑을 보내주세요.

건축주가 필요합니다.

예. 그리고 MS 빌드 도구가 설치되도록 기존 빌더를 변경하는 것으로 시작해야 합니다. 따라서 이 문제에 대한 CL을 수락할 때 사용할 수 있습니다.

모든 빌더에 gcc 도구와 Microsoft 도구를 모두 설치할 수 있습니다. gcc와 microsoft 도구를 한 번에 테스트하는 all.bat를 실행할 수 있습니까? 그렇지 않은 경우 다른 도구에 대해 다른 빌더를 구성해야 합니다. 사용되는 외부 컴파일러 및 링커를 제어하는 ​​매개변수는 무엇입니까?

내 주요 관심사는 Windows 또는 MSVC 릴리스 간에 형식이 얼마나 변경될 수 있는지입니다.

Windows와 함께 컴파일러가 설치되지 않습니다. 직접 설치해야 합니다. 우리가 gcc에서 하는 것처럼. 우리는 우리가 좋아하는 버전을 설치합니다. 다른 빌더에서 다른 gcc 버전을 실행할 수도 있습니다.

MSVC 파일 형식도 비슷하게 안정적입니까?

나는 그것에 대해 아무것도 모른다. 제공된 도구만 ​​사용하는 것 같습니다.

알렉스

내 주요 관심사는 Windows 또는 MSVC 릴리스 간에 형식이 얼마나 변경될 수 있는지입니다. 대부분의 다른 플랫폼에서 사용되는 ELF 형식은 매우 안정적입니다. 새로운 프로세서에 대한 지원을 추가하는 것 외에는 ELF 지원을 조정할 필요가 거의 없습니다. MSVC 파일 형식도 비슷하게 안정적입니까?

예, COFF는 매우 안정적입니다.

@bradfitz 및 @ianlancetaylor 이 문제에 대한 변경 사항을 테스트하기 위해 Windows Builder를 사용하려면 무엇이 필요합니까? https://github.com/golang/go/issues/20982#issuecomment -370719472에서 내 질문을

감사합니다

알렉스

이제 go가 msvc 개체를 지원합니까?

https://golang.org/cl/110555 에서 이 문제를 언급 변경: debug/pe: parse the import directory correctly

@alexbrainman @bradfitz @ianlancetaylor :

나는 패치를 정리하고 더 소화하기 쉬운 조각으로 나누는 데 필요한 대부분의 작업을 수행했습니다. 프로젝트에 실제 제출할 준비가 거의 완료되었다고 생각합니다. 코드를 제출하기 전에 빌더 상황에 대한 정보를 기다려야 하는지 아니면 최대한 빨리 해야 하는지 알아야 합니다.

언제든지 CL을 보낼 수 있지만 누군가 빌더를 설정해야 합니다. 그렇지 않으면 테스트할 방법이 없습니다.

@johnsonj , Windows 이미지에 MSVC 컴파일러 도구를 추가할 수 있습니까?

이상적으로는 새 호스트 유형을 추가하지 않고 기존 Windows 호스트 유형 중 1-3개에 Cygwin 외에 MSVC 도구를 사용하는 것이 좋습니다. 그런 다음 수정된 호스트 유형 위에 더 많은 빌더 구성을 추가할 수 있습니다.

/cc @andybons @bcmills as FYI (Windows 일이 어떻게 발생하는지... Jeff에게 도움을 요청합니다 :))

@johnsonj , Windows 이미지에 MSVC 컴파일러 도구를 추가할 수 있습니까?

@cchamplin 빌더에 필요한 모든 도구를 직접 추가하는 것이 좋습니다. 다른 사람은 없지만 무엇이 필요한지 알고 있습니다. 전체 지침은 golang.org/x/build/env/windows 디렉토리에서 확인할 수 있습니다. 특히 startup.ps1에 줄을 더 추가하고 싶을 것입니다. 해당 디렉터에서 변경해야 할 사항을 알게 되면 https://golang.org/doc/contribute.html을 통해 변경하고 검토를 위해 변경 사항을 보내면 승인되면 이 지침을 사용하여 빌더를 업데이트할 수 있습니다.

이상적으로는 새 호스트 유형을 추가하지 않고 기존 Windows 호스트 유형 중 1-3개에 Cygwin 외에 MSVC 도구를 사용하는 것이 좋습니다. 그런 다음 수정된 호스트 유형 위에 더 많은 빌더 구성을 추가할 수 있습니다.

Windows에는 항상 Mingw(gcc) C 컴파일러와 링커가 있었습니다. 우리는 다른 C 빌드 도구 세트를 가지고 있지 않습니다. Microsoft C 컴파일러에 대한 지원을 추가하면 all.bat를 한 번만 실행하여 Mingw 및 Microsoft C 기능을 모두 테스트할 수 있습니까? 아니면 Mingw 또는 Microsoft C가 서로를 제외합니까? Mingw 또는 Microsoft를 가리키도록 일부 환경 변수를 설정해야 합니까? 코드가 어떻게 구성되고 테스트되어야 하는지 이해하려고 노력하고 있다고 가정합니다. 또한 이것은 얼마나 많은 다른 빌더가 필요한지를 결정할 것입니다.

알렉스

이미지에서 바이너리를 굽는 방법을 살펴보겠습니다.

https://golang.org/cl/112036 에서 이 문제를 언급 변경: env/windows: add visual studio tools to image

@johnsonj @bradfitz : 빌더에 넣어주셔서 감사합니다.

@alexbrainman @bradfitz @ianlancetaylor : 이에 대한 테스트 전략에 관해서는 정확히 무엇을 선택해야 할지 잘 모르겠습니다. 창에서 두 도구 모음에 대해 dist 테스트를 실행하고 모든 테스트를 두 번 수행할 수 있습니다. 아니면 cgo 테스트를 두 번(gcc에 한 번, msvc에 한 번)만 테스트해야 합니까?

그래서 이것에 대한 테스트 전략에 관해서는 정확히 무엇을 해야 할지 잘 모르겠습니다. 창에서 두 도구 모음에 대해 dist 테스트를 실행하고 모든 테스트를 두 번 수행할 수 있습니다. 아니면 cgo 테스트를 두 번(gcc에 한 번, msvc에 한 번)만 테스트해야 합니까?

@cchamplin 귀하의 질문에 대한 답변이 없습니다. Ian이 답을 알고 있다고 생각합니다.

알렉스

cgo 대신 모든 테스트를 두 번 실행하는 데 드는 비용은 얼마입니까?

@mxplusb , Windows용 새 빌드 구성을 실행할 수 있으며 기존 3과 병렬로 실행됩니다. 새 빌더 구성은 괜찮습니다. 우리는 정기적으로 추가합니다.

다르게 만드는 방법을 알려주십시오. 다른/새 환경 변수를 설정하면 무언가가 선택될 것입니다.

이 작업을 수행하려면 몇 가지 작업이 필요할 것입니다.

적절한 vsvars.bat가 실행/호출된 후 dist 테스트가 실행되는 go 테스트가 내부에서 실행될 셸/환경에서 내부를 실행해야 합니다.

또는 dist가 적절한 vsvar를 실행하고 필요한 환경 변수를 추출한 다음 테스트를 위해 설정/전달하도록 할 수 있습니다.

또한 dist 또는 make.bat에 -compiler msvc 세트로 테스트를 실행하고 싶다고 알려주는 환경 변수를 원할 것입니다.

적절한 vsvars.bat가 실행/호출된 후 dist 테스트가 실행되는 go 테스트가 내부에서 실행될 셸/환경에서 내부를 실행해야 합니다.

또는 dist가 적절한 vsvar를 실행하고 필요한 환경 변수를 추출한 다음 테스트를 위해 설정/전달하도록 할 수 있습니다.

dist.exe 또는 go.exe에서 배치 파일을 실행하지 않는 것이 좋습니다. 배치 파일을 처리하는 것은 번거롭습니다.

또한 dist 또는 make.bat에 -compiler msvc 세트로 테스트를 실행하고 싶다고 알려주는 환경 변수를 원할 것입니다.

Ian이 여기에서 가장 좋은 방법이 무엇인지 알기를 바랐습니다. 내가 아는 바에 따르면 우리는 Unix에서도 다양한 C 컴파일러(gcc 또는 clang)를 지원합니다. 확실히 빌드 프로세스를 통해 다양한 C 컴파일러를 테스트할 수 있습니다.

알렉스

go build -compiler msvc 를) 사용할 계획이라는 것을 전에는 알지 못했습니다. 말이 안 됩니다. go build -compiler 옵션은 Go 컴파일러(현재 gc 또는 gccgo)의 이름을 사용합니다. C 컴파일러의 이름을 사용하지 않습니다. C 컴파일러는 CC 환경 변수에 전달됩니다. 기본 C 컴파일러는 make.bat의 주석에 설명된 대로 make.bat를 실행할 때 CC_FOR_TARGET 환경 변수를 설정하여 설정됩니다.

all.bat를 실행하기 전에 CC_FOR_TARGET 환경 변수를 msvc로 설정하는 빌더가 있을 것으로 예상합니다. 왜 우리가 다른 일을 해야 하는지 모르겠습니다.

C 컴파일러는 CC 환경 변수에 전달됩니다. 기본 C 컴파일러는 make.bat의 주석에 설명된 대로 make.bat를 실행할 때 CC_FOR_TARGET 환경 변수를 설정하여 설정됩니다.

설명해주신 Ian님 감사합니다.

@cchamplin 기존 모델에 맞게 변경 사항을 조정할 수 있기를 바랍니다. 문제가 있으면 알려주십시오. 감사합니다.

all.bat를 실행하기 전에 CC_FOR_TARGET 환경 변수를 msvc로 설정하는 빌더가 있을 것으로 예상합니다.

https://build.golang.org 에 3개의 amd64 윈도우 빌더가

알렉스

@ianlancetaylor @alexbrainman -compiler 플래그에 대해 이해했습니다. CC="msvc" (또는 실제로 CC="cl.exe" )를 작동하도록 설정하는 쉬운 방법은 없다고 생각합니다. CC는 여전히 MSVC 빌드가 작동하려면 GCC 위치를 가리켜야 합니다. msvc 컴파일러 도구 집합에는 CGO가 필요한 자체 검사(정의 조회, 유형 확인)를 수행할 수 있는 도구가 없으므로 GCC는 MSVC 빌드에 여전히 필요하며 GCC는 실제 컴파일/연결 단계에서 사용되지 않습니다.

빌드 등을 위해 새 플래그를 추가하는 것이 모두 허용됩니까(도구 체인 또는 기타)? 나는 이미 cgo에 툴체인 플래그를 추가해야 했습니다.

또한 all.bat 전에 CC_FOR_TARGET 를 설정하면 부트스트랩에 사용되는 컴파일러에 영향을 미치기 때문에 부정적인 결과가 나타날 수 있습니다. 부트스트랩 프로세스 중에 MSVC를 사용할 수 있다고 생각하지 않습니다.

MSVC의 경우 GCC와 MSVC가 모두 있어야 합니까? Cgo 도구에서만 GCC를 사용하는 곳은 어디입니까? 그것은 우리가 정확히 동일한 ABI를 구현하는 GCC와 MSVC에 절대적으로 의존한다는 것을 의미하기 때문에 다소 불행해 보이지만, 그럴 가능성이 상당히 높습니다.

GCC로 설정할 수 있는 또 다른 환경 변수 CC_FOR_CGO 를 추가할 수 있을 것 같습니다.

make.bat에서 사용하는 CC_FOR_TARGET 는 런타임/cgo를 빌드하는 데 사용됩니다. 런타임/cgo가 사용 중인 C 컴파일러에 의해 빌드되지 않은 경우 cgo가 어떻게 작동할 수 있는지 나에게는 명확하지 않습니다.

아마도 CC_FOR_TARGET 를 cl 하고 CGO_ENABLED 를 0 설정하는 make.bat 가 호출될 때 일을 시작해야 할 것입니다.

@ianlancetailor 감사

MSVC의 경우 GCC와 MSVC가 모두 있어야 합니까? Cgo 도구에서만 GCC를 사용하는 곳은 어디입니까? 그것은 우리가 정확히 동일한 ABI를 구현하는 GCC와 MSVC에 절대적으로 의존한다는 것을 의미하기 때문에 다소 불행해 보이지만, 그럴 가능성이 상당히 높습니다.

나는 그것이 불행하다는 데 동의하고 어떤 대안을 배우게 되어 기쁠 것입니다. 아직 찾지 못했습니다. 확실히 이런 식으로 빌드할 위험이 있습니다(예: 빌드되는 cgo 코드는 빌드되고 있다고 생각하는 컴파일러에 따라 다른 유형 def 또는 정의를 갖습니다). 따라서 빌드가 약간의 조정 없이는 항상 성공하거나 올바르게 작동하지 않을 수 있습니다(내 구현에서 이를 처리하는 메커니즘이 있지만 약간의 수동 프로세스임). 슬프게도 이것은 사람들이 MSVC 도구 체인을 사용하려는 경우 감수해야 하는 위험이며 우리가 지금 할 수 있는 일은 문서화하는 것뿐입니다.

비슷한 참고로 MSVC 컴파일러가 c99와 호환되지 않기 때문에 MSVC 빌드 cgo 프로그램에서 complex64 및 complex128 지원을 제공하기 위한 실제 경로는 아직 없습니다.

GCC로 설정할 수 있는 또 다른 환경 변수 CC_FOR_CGO 를 추가할 수 있을 것 같습니다.

따라서 현재 구현은 go build가 MSVC로 빌드하도록 지시받은 경우 기본적으로 경로에서 cl.exe를 찾지만 환경 변수 MSCC로 재정의할 수 있습니다. CGO는 생성된 zdefaultcc.go에 있는 gcc/무엇이든 다시 CC 환경 변수를 계속 사용합니다.

make.bat에서 사용하는 CC_FOR_TARGET 는 런타임/cgo를 빌드하는 데 사용됩니다. 런타임/cgo가 사용 중인 C 컴파일러에 의해 빌드되지 않은 경우 cgo가 어떻게 작동할 수 있는지 나에게는 명확하지 않습니다.

현재 구현에서 cgo는 전체 go 도구 체인이 gcc에 의해 구축된 경우에도 msvc 바이너리에 대해 행복하게 작동합니다. 예를 들어 MSVC 코드가 go/src에 추가됩니다. all.bat는 gcc를 사용하여 go 환경을 구축하면서 실행됩니다. 그 후 go/bin/go.exe를 사용하여 msvc 도구 체인으로 빌드할 수 있습니다(플래그가 제공된다고 가정). 그런데 여기서 무슨 말씀을 하시는지 제가 오해할 수도 있습니다.

우리가 msvc로 빌드하고 싶다고 말하는 것이 컴파일러를 cl로 전환하는 것보다 더 복잡하기 때문에 이것에 대한 복잡성. MSVC 도구 체인은 gcc 도구 체인과 매우 다릅니다. MSVC에서는 vcvars.bat 내에서 실행을 통해 환경을 설정해야 합니다. 프로세스). MSVC 환경에 들어간 후 주요 차이점은 도구 자체가 됩니다. cl.exe는 C 및 C++ 파일을 컴파일하는 데 사용되며 ml.exe와 ml64.exe는 파일을 어셈블하는 데 사용되며 마지막으로 link.exe(ms)는 다음 작업에 사용됩니다. 모든 것을 함께 연결하십시오. 따라서 CC=cl.exe 설정하고 올바른 플래그를 전달하는 것 이상입니다. 그것이 의미가 있습니까/설명하는 데 도움이됩니까?

에 대해 더 명확히 하기 위해

make.bat에서 사용하는 CC_FOR_TARGET은 런타임/cgo를 빌드하는 데 사용됩니다. 런타임/cgo가 사용 중인 C 컴파일러에 의해 빌드되지 않은 경우 cgo가 어떻게 작동할 수 있는지 나에게는 명확하지 않습니다.

go build 는 빌드 프로세스 중 런타임/cgo에서 적절한 파일을 선택하고 있습니다(예: go build / go test / go run -- 빌더 프로세스 아님). msvc 도구 모음이 선택되었습니다.

나는 이것이 어떻게 작동해야 하는지에 대한 제안에 열려 있지만 go 도구에 대한 새로운 명령줄 옵션이 필요하지 않아야 합니다. go 도구에 관한 한 GCC처럼 작동하지만 실제로 MSVC를 실행하는 순수한 Go 프로그램을 작성할 수 있습니까?

go 도구에 관한 한 GCC처럼 작동하지만 실제로 MSVC를 실행하는 순수한 Go 프로그램을 작성할 수 있습니까?

나는 그것이 실행 가능하다고 믿는다. 내가 그 길에서 뭔가를 얻을 수 있는지 보자.

또한 다른 도구에 명령줄 플래그를 추가하는 것도 문제가 될 것인지 명확히 해야 한다고 생각합니다. 현재 이에 대한 포괄적인 패치는 다양한 도구에서 몇 가지 새로운 명령줄 플래그를 생성하고 있습니다.

• cmd/cgo
  
  
  
  • -toolchain [gcc,msvc] (기본값은 gcc) cgo 출력 파일을 빌드할 때 사용할 도구 모음
  
  
• cmd/링크
  
  
  
  • -rlocbss(기본값은 false) .bss를 .data로 재배치
  
  
  • -toolchain [gcc,msvc] (기본값은 gcc) 외부 연결에 사용할 도구 모음
  
  

또한 다음 빌드 옵션/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가 존재하지 않는 플래그를 gcc에 전달하도록 할 것입니다.
4. go build 는 cmd/link를 호출하여 .bss에서 .data 재배치를 수행하고 링커에 특정 플래그를 전달할 수 있도록 도구 체인을 알아야 합니다(후자를 처리할 수 있습니다. 프록시 자체의 일부)

go build 사용하도록 환경 변수를 지정하면 msvc 빌드가 작동합니까? msvc를 사용하여 프로그램을 빌드하려는 사람에게는 기준을 더 높게 설정한다고 생각하지만 이제 vsvars.bat 내부에서 실행하는 것 외에도 여러 환경 변수를 설정해야 합니다(최소 CC 및 UNDECIDED_TURN_ON_MSVC_BUILD_VAR )

또 다른 대안은 go build 가 지정된 CC 에서 가짜 noop 명령을 실행한 다음 로고/헤더를 구문 분석하여 msvc 또는 gcc인지 감지하고 해당 지점에서 적절한 도구 모음 조정을 진행하도록 하는 것입니다. ...이것이 얼마나 부서지기 쉬운지 또는 clang과 같은 msvc 호환 도구 모음과 함께 작동하는지 잘 모르겠습니다.

최근에 이 Github 문제를 발견했고 이 작업은 저에게 매우 흥미진진합니다. 나는 이것이 가까운 장래에 어딘가에 착륙하기를 바랍니다.

내 의도는 Windows에서 CGo를 MSVC를 사용하여 빌드된 일부 타사 코드에 대한 래퍼로 사용하는 것입니다. mingw-w64 사용하여 소스에서 다시 빌드할 수 없습니다. 나는 그것을 통해 실행할 비교적 심각한 테스트 케이스가 있으므로 꽤 잘 검증할 수 있습니다.

여하튼 @cchamplin 과 이 작업을 하고 있는 다른 사람에게 감사를

@cchamplin Windows 및 cgo의 컴파일러 도구 체인에 대해 내가 도울 수 있는 위험에 대해 충분히 알고 있습니다. 당신이 작업 중 일부에 나를 따라 잡을 수 있습니까? 내가 무엇을 도울 수 있는지 알아보겠습니다. 나는 유스 케이스 @deadprogram 알고 있다 우리가 시험에 준비가되면 내가 좋은 고급 테스트 베드 그래서.

안녕하세요 @mxplusb , 패치는 실제로 어느 정도 준비가 되었습니다. 시간을 찾을 수 있다면 오늘 밤이나 내일 gerrit에 변경 사항을 제출하여 모든 검토, 업데이트 및 승인을 진행하도록 하겠습니다.

https://golang.org/cl/133937 에서 이 문제를 언급 변경: cmd/link: Add flag rlocbss to relocate .bss data to .data

https://golang.org/cl/133938 에서 이 문제를 언급 변경: runtime/cgo: MSVC toolchain support in cgo native code

https://golang.org/cl/133939 에서 이 문제를 언급 변경: cmd/cgo: Add toolchain flag to cgo command for MSVC support

https://golang.org/cl/133946 에서 이 문제를 언급 변경: cmd/compile: Add support for MSVC toolchain to go build

일부 커밋에 문제를 입력한 것 같습니다. 검토 프로세스를 진행하고 가장 좋은 수정 방법을 결정하도록 하겠습니다.

https://golang.org/cl/133943 에서 이 문제를 언급 변경: cmd/cgo: Add support for CC_FOR_CGO environment variable

https://golang.org/cl/133942 에서 이 문제를 언급 변경: tests: Update various tests to prepare for MSVC compiler toolchain

https://golang.org/cl/133940 에서 이 문제를 언급: misc/cgo: Adjust tests to be compatible with MSVC toolchain support

https://golang.org/cl/133941 에서 이 문제를 언급 변경: runtime: Add runtime.CompilerType to denote between host compiler type

변경 https://golang.org/cl/133945 에서 이 문제를 언급합니다. cmd/link: Add external toolchain support for MSVC

https://golang.org/cl/133944 에서 이 문제를 언급 변경: cmd/compile, cgo: Add support for MSVC flags

@cchamplin 최종 결정이 무엇인지 설명해 주시겠습니까? MSVC 지원은 어떻게 됩니까? 어떤 명령줄 플래그가 추가됩니까? 사용자는 MSVC를 다운로드하는 것 외에 환경에서 무엇을 해야 합니까? 감사 해요

또한 이 패치를 어떻게 시도할 수 있습니까? 저장소에서 커밋을 찾을 수 없습니다.

@rasky 변경 사항이 검토를 거치면서 여전히 약간의 유동적입니다. CC 환경 변수가 MSVC를 가리키거나 CC가 설정되지 않고 cl.exe가 경로에 있지만 gcc가 아닌 cgo 응용 프로그램을 구축하기만 하면 설정해야 하는 특정 명령줄 플래그가 없을 것입니다.

@blizzardplus 위와 유사하게 현재 리뷰와 함께 많은 변화가

@cchamplin 은 gcc 또는 clang 사용하여 크로스 컴파일을 지원합니까? 그렇다면 테스트를 받습니까?

@cchamplin 9/11 이후 CL에 대한 활동이 보이지 않습니다. 이에 대한 진행 상황이 있습니까? 아니면 추가 리소스가 필요한가요?

@cchamplin 이 c-archive에서 작동하려면 ctors 섹션을 .CRT$XCU(https://msdn.microsoft.com/en-us/library/bb918180.aspx)로 변경해야 합니다. golang 런타임이 초기화되지 않습니다. 또한 이것을 설정하면 gcc에서도 잘 작동한다는 것이 밝혀졌습니다. gcc는 여전히 해당 기능을 가져와 텍스트 섹션으로 이동하고 실제 main보다 먼저 호출하도록 main을 수정합니다. Visual Studio는 .a 아카이브 파일을 이해할 수 있으며 사전 컴파일/어셈블된 파일의 인터페이스가 C이므로 아카이브에 있는 것만으로도 문제가 되지 않습니다. 2개의 .text 섹션에 대한 경고가 있지만 간단한 경우는 잘 작동하는 것 같습니다(문제가 없는지 확인하려면 더 많은 테스트가 필요함).

또한 이것이 c-shared에서 작동하려면 내보낼 함수를 __declspec(dllexport)로 데코레이트해야 하지만 //export의 확장이 어디에서 발생하는지 찾을 수 없는 것 같습니다.

@blizzardplus clang-MSVC를 지원하기 위한 후속 패치가 있습니다. 이 경우 크로스 컴파일이 무엇을 의미하는지 잘 모르겠습니다. Windows가 아닌 시스템에서는 MSVC 도구 체인을 사용할 수 없습니다. 다른 크로스 컴파일 기능은 변경되지 않아야 합니다.

@kshelton 불행히도 지금은 제가 발표하는 작업과 회의에 다른 프로젝트가 있기 때문에 일년 중 매우 바쁜 시기입니다. 12월까지 패치에 필요한 리팩토링을 다시 시작하지 못할 수도 있습니다.

@kshelton 감사합니다. 패치를 다시 확인하지 않았습니다. c-archive가 MSVC에서 작동하지 않거나 특별히 비활성화한다는 가정 하에 개발한 것으로 가정합니다. Windows에서 플러그인/공유 작업을 수행하려고 할 때 내보내기를 적절하게 장식하려고 하는 경로를 따라갔습니다. 내가 믿는 다른 문제가 있지만 두 가지 문제를 병합할 수 있습니다. 공유 코드를 ELF 대 Windows .edata, idata 및 EAT에 대해 PLT/GOT에 배치하는 방법에 실제 문제가 있습니다. 내가 직면한 대부분의 문제는 재배치와 작업을 수행할 수 없는 것과 관련된 것이었습니다. 누구든지 이것에 대한 통찰력이 있다면 그것은 훌륭할 것입니다. #19282 참조

@cchamplin CL 위에 Go를 빌드할 수 있는지 확인하려고 했습니다.

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

이 배치 파일을 사용하여 환경을 설정했습니다.

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

make.bat를 실행할 때 이 오류가 발생합니다.

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

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

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

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

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

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

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

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

Command output:

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

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

The system cannot find the batch label specified - fail

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

내가 여기서 무엇을 놓치고 있습니까?

감사합니다.

알렉스

@alexbrainman

내가 여기서 무엇을 놓치고 있습니까?

최소한 CC_FOR_CGO=gcc를 설정해야 합니다. 또한 개인적으로 MSVC를 사용하여 자체적으로 빌드를 시도한 적이 없습니다. 이것이 작동하는지/지원되어야 하는지 확실하지 않습니다.

-씨

최소한 CC_FOR_CGO=gcc를 설정해야 합니다.

https://go-review.googlesource.com/c/go/+/133940 에 몇 가지 테스트가 포함되어 있습니다. 테스트 통과를 어떻게 확인합니까? 정확한 단계는 무엇입니까?

또한 Go 빌더 https://build.golang.org %GOROOT%\src\all.bat를 실행하여 모든 테스트(https://go-review.googlesource.com/c/go/+/에 나열된 테스트 포함)를 확인합니다. 133940) 통과. %GOROOT%\src\all.bat가 https://go-review.googlesource.com/c/go/+/133940 에서 조정된 테스트를 실행하도록 Go 코드를 수정하는 방법을 제안합니다

또한 개인적으로 MSVC를 사용하여 자체적으로 빌드를 시도한 적이 없습니다. 이것이 작동하는지/지원되어야 하는지 확실하지 않습니다.

gcc를 설치하지 않고도 all.bat를 실행하여 성공적으로 완료할 수 있습니다. 현재 Go 버전을 빌드하려면 다른 Go 버전(적어도 go1.4)만 있으면 됩니다. Cgo에만 C 컴파일러가 필요합니다. 귀하의 변경 사항이 MSVC로 빌드된 Cgo 버전을 구현한다는 인상을 받았습니다. 그러나 아마도 내가 착각하고 있는 것 같다. 내가 틀렸다면 저를 수정하십시오.

감사합니다.

알렉스

@alexbrainman

https://go-review.googlesource.com/c/go/+/133940 에 몇 가지 테스트가 포함되어 있습니다. 테스트 통과를 어떻게 확인합니까? 정확한 단계는 무엇입니까?

아마도 all.bat는 테스트의 gcc 및 msvc 버전을 모두 테스트할 수 있습니다. 아마도 우리는 실행할 테스트 버전을 all.bat에 알려주는 환경 변수를 사용할 수 있습니다. 그러면 두 개의 다른 빌더가 다른 버전의 테스트를 실행하게 할 수 있습니다. 그걸 다 생각했어?

예, 이 정확한 메커니즘은 https://go-review.googlesource.com/c/go/+/133946/ 에서 사용됩니다

gcc를 설치하지 않고도 all.bat를 실행하여 성공적으로 완료할 수 있습니다. 현재 Go 버전을 빌드하려면 다른 Go 버전(적어도 go1.4)만 있으면 됩니다. Cgo에만 C 컴파일러가 필요합니다. 귀하의 변경 사항이 MSVC로 빌드된 Cgo 버전을 구현한다는 인상을 받았습니다. 그러나 아마도 내가 착각하고 있는 것 같다. 내가 틀렸다면 저를 수정하십시오.

당신이 올바른지. Go 자체는 잘 빌드되어야 합니다. GOTESTMSVC=1일 때 일부 환경 변수를 설정하도록 run.bat가 수정되었기 때문에 테스트에 도달할 때 문제가 있을 수 있습니다. go가 msvc로 빌드되고 있는지 감지하고 적절한 dist 환경 변수를 설정하여 테스트가 실패하지 않도록 할 수 있습니다.

그런 다음 GOTESTMSVC=1 및 GOVSVARSPATH=some vsvars.bat 경로를 설정합니다. all.bat를 사용하여 빌드한 후 gcc 및 msvc cgo 테스트를 모두 실행해야 합니다.

나는 그것을 시도했다.

나는 사용했다

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

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

    Allows building with MSVC as an external compiler/linker.

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

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

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

이 배치 파일을 먼저 실행합니다.

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

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

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

그런 다음 all.bat 를 실행합니다. all.bat 실패

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

또한 GOTESTMSVC 및 GOVSVARSPATH를 설정하면 all.bat를 실행하는 사람들이 사용할 수 있습니다. 그러나 변경 사항의 다른 사용자가 Cgo용 MSVC를 사용해야 할 때 무엇을 합니까? 그것에 대한 당신의 계획은 무엇입니까?

알렉스

@alexbrainman
무슨 일이 일어나고 있는지 잘 모르겠습니다. 그 테스트는 마스터에서 나에게 실패하고 있습니다.

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

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

help.go에서 https://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/internal/help/help.go#L37
base.Go.Commands를 통해 반복합니다. main.go에서 초기화되는 https://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/main.go#L43
하지만 그 init 함수가 테스트 실행 파일에서 어떻게 호출되는지 잘 모르겠습니다. 그래서 지금 마스터가 테스트를 어떻게 통과하고 있는지 알 수 없습니다. 이것이 전반적으로 실패해야 한다고 생각하기 때문입니다.

또한 GOTESTMSVC 및 GOVSVARSPATH를 설정하면 all.bat를 실행하는 사람들이 사용할 수 있습니다. 그러나 변경 사항의 다른 사용자가 Cgo용 MSVC를 사용해야 할 때 무엇을 합니까? 그것에 대한 당신의 계획은 무엇입니까?

따라서 MSVC로 일부 Cgo 코드를 빌드하려는 상황에서

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

내가 생각하기에 당신이 필요로하는 모든 것이어야합니다

그 init 함수가 테스트 실행 파일에서 어떻게 호출되는지 잘 모르겠습니다. 그래서 지금 마스터가 테스트를 통과하는 방법을 알 수 없습니다. 이것이 전반적으로 실패해야 한다고 생각하기 때문입니다.

cmd/go의 파일과 함께 go test 를 사용할 때 go 도구는 cmd/go 패키지를 빌드한 다음 테스트를 빌드하고 테스트 드라이버를 생성하고 빌드하고 모든 것을 함께 새 기본 패키지에 연결합니다. 이것은 cmd/go 자체가 기본 패키지인 경우에도 발생합니다. 즉, cmd/go/*.go의 기본 패키지는 테스트를 위해 기본이 아닌 패키지로 처리됩니다. 이를 통해 테스트는 적절한 경우 기본 패키지에 정의된 함수를 호출할 수 있습니다.

죄송합니다, 답변이 느립니다. 그러나 나는 이것을 다시 조사할 여유가 없었다.

무슨 일이 일어나고 있는지 잘 모르겠습니다. 그 테스트는 마스터에서 나에게 실패하고 있습니다.

저는 마스터를 사용하지 않았습니다. 귀하의 e56d52f66b95b87001867a2487a11bd961f40d4d 커밋을 사용했습니다. 검토를 위해 보내기 전에 해당 커밋에 대해 all.bat를 실행하지 않았습니까? all.bat가 성공했습니까? 내 시스템 구성과 관련이 있는지 확인하기 위해 해당 커밋에서 all.bat를 다시 실행해 볼 수 있습니까? 감사합니다.

따라서 MSVC로 일부 Cgo 코드를 빌드하려는 상황에서

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

내가 생각하기에 당신이 필요로하는 모든 것이어야합니다

2 환경 변수는 아마도 일반 사용자에게 너무 복잡합니다. 그리고 CC_FOR_CGO=gcc 가 이상해 보입니다. MSVC로 코드를 빌드하기 위해 gcc를 사용하는 이유는 무엇입니까?

알렉스

@alexbrainman

저는 마스터를 사용하지 않았습니다. 귀하의 e56d52f66b95b87001867a2487a11bd961f40d4d 커밋을 사용했습니다. 검토를 위해 보내기 전에 해당 커밋에 대해 all.bat를 실행하지 않았습니까? all.bat가 성공했습니까? 내 시스템 구성과 관련이 있는지 확인하기 위해 해당 커밋에서 all.bat를 다시 실행해 볼 수 있습니까? 감사합니다.

테스트를 실행할 때 이상한 결과를 가져온 시스템 구성과 관련이 있다고 생각합니다. 문제를 해결하고 변경 세트에 대한 일부 업데이트를 푸시한 것 같습니다.

2 환경 변수는 아마도 일반 사용자에게 너무 복잡합니다. CC_FOR_CGO=gcc가 이상해 보입니다. MSVC로 코드를 빌드하기 위해 gcc를 사용하는 이유는 무엇입니까?

실제로 CC_FOR_CGO=gcc.exe여야 합니다. 제 실수입니다. 그러나 귀하의 질문에 대답하기 위해; 게릿에서:

PS1, 1324행:
cgo는 여전히 유형 분석에 사용할 수 있는 gcc가 필요합니다. CC가 MSVC 컴파일러로 설정된 경우 cgo는 CC_FOR_CGO에서 제공하는 GCC를 호출하는 수단이 필요합니다. 불행히도 MSVC 도구 체인에는 gcc에서 수집되는 동일한 유형 정보를 제공하는 메커니즘이 없습니다. 이론적으로 go 특정 도구는 cgo에서 사용하는 유형 정보를 수집하기 위해 만들 수 있지만 범위를 벗어나 상당한 노력을 기울일 수 있습니다(저는 개인적으로 C/C++ 코드의 정적 유형 분석을 수행하기 위해 아무 것도 작성하지 않았습니다).

또한 GCC 대 MSVC 실행 사이에 캐시 지우기로 무언가를 깨뜨린 것 같습니다. 일부 테스트가 여전히 캐시된 것처럼 작동하는 이유를 잘 모르겠습니다.

문제를 해결하고 변경 세트에 대한 일부 업데이트를 푸시한 것 같습니다.

이 설정은 https://github.com/golang/go/issues/20982#issuecomment -447618566에서

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

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

    Allows building with MSVC as an external compiler/linker.

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

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

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

나를 더 멀리 데려다 주지만 여전히 실패합니다.

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

ALL TESTS PASSED

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

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

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

실제로 CC_FOR_CGO=gcc.exe여야 합니다. 제 실수입니다.

나는 gcc.exe의 .exe에 대해 걱정하지 않습니다. 내 문제는

• MSVC를 사용하려면 gcc와 MSVC 도구가 모두 필요하지만(사용자에게 설명하기가 어려울 수 있음) 이에 대해 아무 것도 할 수 없음을 이해합니다.

• CC_FOR_CGO=gcc 및 CC=cl.exe 설정 환경 변수가 모두 필요했습니다. CC_FOR_CGO가 항상 gcc로 설정되어 있다고 가정할 수 있습니까?

그러나 귀하의 질문에 대답하기 위해; 게릿에서:

설명해주셔서 감사합니다.

알렉스

@alexbrainman

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

msvc_libinit_windows.c의 다른/이전 사본이 없는 한 경고가 어떻게 발생하는지 잘 모르겠습니다. 다음 줄이 포함되어 있는지 확인할 수 있습니까?

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

C4710은 stdio 포함에 대해 억제되어야 합니다. 귀하의 MSVC 버전이 내 버전과 약간 다르며 이것이 범인일 수도 있습니다. 나는 그들이 다른 버전에서 그 억제를 적극적으로 무시하는 이유를 잘 모르겠습니다.

또한 무엇이든 상관없이 전 세계적으로 억제를 포함하도록 변경을 시도할 수 있습니다.

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

CC_FOR_CGO=gcc 및 CC=cl.exe 설정 환경 변수가 모두 필요했습니다. CC_FOR_CGO가 항상 gcc로 설정되어 있다고 가정할 수 있습니까?

CC_FOR_CGO가 설정되어 있지 않으면 gcc가 존재하는지 확인하는 gco가 좋을 것이라고 생각합니다. CC_FOR_CGO는 경로에 gcc가 없는 나와 같은 사람들을 위한 것입니다. 내 CC_FOR_CGO는 다음과 같습니다. CC_FOR_CGO=I:\Development\tmd-gcc\bingcc.exe. MSVC 빌드 경로에 없는 GCC의 사용 사례를 지원하지 않으려면 알려주시면 환경 변수를 함께 제거할 수 있습니다.

이 버전으로 다시 시도했습니다

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을 사용 중입니다. 및 빌드 도구/devenv의 버전 15.9.28307.222

MSVC를 사용하여 Windows DLL을 빌드하려고 하는데 Go가 65535(또는 숫자가 아님)보다 큰 숫자로 일부 경고를 비활성화하려고 시도하여 MSVC가 중지되는 것 같습니다.

아니요. Werror 는 모든 경고를 오류로 처리하기 위한 GCC 옵션입니다.

MSVC의 경우 WX 를 사용해야 합니다.

@pravic 좋은 점, 어떻게 하면 될까요? 나는 그것을 설정하지 않고 내가하고있는 모든 것 :

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

@galich 불행히도 MSVC 통합을 따르지 않기 때문에 도울 수 없습니다.

예를 들어 이 스레드와 관련된 패치는 어디에 있습니까? 마스터에서 또는 다른 곳에서?

@pravic 에서 변경 사항을 확인할 수 있습니다. https://go-review.googlesource.com/c/go/+/133946/5

@mxplusb 링크 주셔서 감사합니다. /
이것이 언제 베타/야간/안정적으로 제공되는지 아십니까?

최신 SDK 및 빌드 도구로 업데이트할 수 있습니까? 저는 SDK 10.0.17763.0을 사용 중입니다. 및 빌드 도구/devenv의 버전 15.9.28307.222

@cchamplin 마침내 MSVC를 업데이트할 수 있었습니다. 나는 지금 가지고있어

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

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

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

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

이 버전으로 다시 시도했습니다

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

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

    Allows building with MSVC as an external compiler/linker.

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

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

    Updates #20982

    Change-Id: I44be1f43aa0d53a688c595bc8336e0364b809ced

all.bat가 성공적으로 완료됩니다. 그러나 나는 이러한 경고를 받습니다.

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

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

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

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

##### ../test

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

ALL TESTS PASSED

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

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

또한 모든 테스트를 두 번 실행하는 것으로 나타났습니다.

...
##### 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 이러한 테스트, 특히 이 경우 유령 경고의 경우 경고가 표시되지 않을 수 있습니다.

두 번 실행되는 테스트의 경우 빌더에 대해 그런 식으로 수행되었다고 생각합니다. gcc 컴파일로 테스트를 한 번 실행한 다음 MSVC(활성화된 경우)를 사용하여 테스트를 다시 실행하여 두 도구 모음이 모두 작동하는지 확인합니다. 여기서 원하는 것이 무엇인지 잘 모르겠으므로 MSVC가 활성화된 상태에서 all.bat를 호출할 때 MSVC로만 테스트를 실행하도록 변경할 수 있습니다. 알려주세요. 이 경우 MSVC로 빌드하는 일부 빌더와 달리 MSVC에 대해서만 빌더를 추가해야 한다고 가정합니다.

Windows에서 두 시나리오를 모두 테스트하려면 MinGW-W64 도구 체인을 사용하여 하나의 빌더를 실행하고 MSVC 도구 체인을 사용하여 다른 빌더를 실행해야 한다는 데 동의했습니다.

빌더를 위해 그런 식으로 수행되었다고 생각합니다. gcc 컴파일로 테스트를 한 번 실행한 다음 MSVC(활성화된 경우)로 테스트를 다시 실행하여 두 도구 모음이 모두 작동하는지 확인합니다.

두 도구 체인이 모두 있는 경우 기존 워크로드를 중단하지 않는다는 보장이 있으므로 이것이 선호되는 동작이어야 한다는 데 동의합니다.

이러한 테스트, 특히 이 경우 유령 경고에 대한 경고가 표시되지 않을 수 있습니다.

Go 명령은 경고를 표시하지 않으므로 경고가 표시되지 않아야 합니다.

또한 go env 명령이 CC_FOR_CGO 변수를 표시하지 않는다는 것을 알았습니다. CC_FOR_CGO가 go 빌드 작동 방식에 영향을 미치는 경우 CC_FOR_CGO가 다른 것들과 함께 표시되어야 합니다. CC_FOR_CGO 변수가 정말로 필요합니까? CC_FOR_CGO=gcc가 아닌 다른 것은 무엇입니까?

두 번 실행되는 테스트의 경우 빌더에 대해 그런 식으로 수행되었다고 생각합니다. gcc 컴파일로 테스트를 한 번 실행한 다음 MSVC(활성화된 경우)를 사용하여 테스트를 다시 실행하여 두 도구 모음이 모두 작동하는지 확인합니다.

많은 테스트에서 gcc를 사용하지 않습니다. 패키지 테스트가 이유 없이 두 번 실행되는 것은 사람/컴퓨터의 시간 낭비입니다. https://github.com/golang/go/issues/20982#issuecomment -480569880 archive/zip 패키지 테스트가 두 번 실행되었음을 알 수 있습니다. 두 번째 실행이 필요하지 않습니다.

어떻게 정렬해야 할지 잘 모르겠지만 run.bat에서 go tool dist test 호출을 대체하여 MSVC 빌드를 테스트하는 데 필요한 테스트를 선택하면 됩니다. 예를 들어 몇 가지 특정 테스트만 선택하는 방법은 go tool dist test -h 를 참조하세요. @bradfitz 는 dist 명령에 MSVC 특정 테스트를 실행하도록 지시하는 플래그 또는 환경 변수를 만들 수 있습니다.

그러나 일반적으로 https://go-review.googlesource.com/c/go/+/133946/5 가 나를 위해 실행 파일을 만들고 있습니다. 예를 들어, gcc로 실행 파일을 빌드할 수 있습니다.

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

hello.c


#include <stdio.h>

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

hello.go


package main

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

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

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

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

그런 다음 MSVC로 실행 파일을 빌드할 수 있습니다.

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

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

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

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

따라서 MSVC를 사용하여 빌드하려면 사용자가 MS 배치 파일을 실행하여 모든 환경 변수를 설정해야 합니다(내 출력의 GOVSVARSPATH 참조). 이는 표준이며 Go와 관련이 없다고 가정합니다. 그리고 set CC=cl . 충분히 간단합니다.

이 접근 방식에서 볼 수 있는 유일한 문제는 MSVC 사용자가 여전히 gcc를 설치해야 한다는 것입니다. gcc는 cmd/cgo에서 모든 C 인터페이스를 검색하는 데 사용됩니다. 이 부분은 MSVC를 사용하여 구현되지 않습니다. cmd/cgo가 작동하는 방식을 모르는 사람들에게는 이상하게 들리지만 그것이 무엇인지입니다.

@ianlancetaylor 와 @bradfitz 가 이 모든 것을 추진하는 것이 합리적으로 들리나요? 이것을 go1.13에서 사용할 수 있도록 해야 합니까?

MSVC가 이미 설치된 빌더는 모든 새 코드를 테스트할 수 있습니다. 다른 빌더는 테스트를 건너뛸 것입니다.

알렉스

gcc는 cmd/cgo에서 모든 C 인터페이스를 검색하는 데 사용됩니다. 이 부분은 MSVC를 사용하여 구현되지 않습니다.

어떻게 극복할 수 있습니까? 이상적으로는 gcc에 대한 요구 사항이 없고 MSVC만 있으면 좋을 것입니다.

어떻게 극복할 수 있습니까?

gcc를 사용하는 cmd/cgo의 일부는 MSVC를 사용하도록 다시 작성해야 합니다. 혹시 가능하다면.

알렉스

이 기능이 프로덕션 단계에 더 가까운지 궁금합니다. 나는 그것이 1.13에 대해 태그가 붙은 것을 보았고 방금 나왔습니다. 확장 코드에 연결된 Go c-archive 빌드를 사용하여 Python 확장을 빌드하려고 하는데 Python에는 MSVC가 필요합니다.

이 문제의 상태가 무엇인지 모르겠습니다. 출시부터 출시까지 앞으로 쫓겨났으니 무계획으로 옮기도록 하겠습니다. 1.14에 들어가면 훌륭합니다.

이중 컴파일러 요구 사항이 있더라도 현재 구현이 다음 릴리스에 적용되는 것을 보고 싶습니다. 최소한 MSVC를 사용하여 실행 파일/라이브러리를 컴파일하는 것을 가능하게 하며, 이는 없는 것보다 낫습니다.

이중 컴파일러 요구 사항이 있더라도 현재 구현이 다음 릴리스에 적용되는 것을 보고 싶습니다.

나는 이것이 좋은 "베타" 구현이 될 것이라고 생각합니다. 버그가 제거되고 구현이 성숙하기 시작할 수 있습니다. 진지한 검토를 거치기 전에 해야 할 일은 무엇입니까?

그래서 내 관점에서 그리고 내가 이것을 마지막으로 봤을 때(~6개월 전) 기억할 수 있는 것은 코드 검토 프로세스를 위해 완료해야 하는 12개 정도의 정리 항목이 있었습니다. 기본적으로 다른 도구 체인과 함께 작동하기 위해 아주 약간의 수정으로 복사된 일부 테스트의 중복을 제거하려면 추가 작업이 필요할 수도 있습니다. 또한 특정 msvc 경고를 검토하고 해제해야 합니다.

주요 미해결 문제는 다음과 같습니다.

gcc 없이는 유형 분석을 할 수 없습니다. 이에 대한 간단하거나 즉각적인 솔루션은 없습니다.

설정을 마무리하고 모든 것이 빌더를 위해 작동하는 방식입니다.

나는 지난 6개월 동안 컴파일러와 링커에 상당한 변화가 있었다고 생각하는데 이것이 현재 작업에 심각한 영향을 미칠 수 있지만 나는 그것을 확인할 수 없었습니다. Go의 컴파일러/링커/도구 체인 탐색에 대한 복잡성과 높은 학습 곡선으로 인해 변경 사항이 이 작업 본문에 미치는 영향을 파악하기에 충분한 속도를 내는 데 상당한 시간이 걸릴 수 있습니다.

복소수 유형은 지원되지 않습니다. MSCVs C lib는 단순히 호환되지 않습니다. 나는 이것을 C++로 shim하는 방법이 있을 것이라고 생각하지만 확실하지 않습니다. 아마도 MSVC 도구 체인에 익숙한 MS의 누군가가 끼어들 수 있을 것입니다.

불행하게도 삶과 다른 프로젝트가 이 일에 더 많은 시간을 할애하는 데 방해가 되지만 앞으로 몇 주 동안 이 일에 시간을 할애할 것입니다.

@manbearian 이 문제는

@kesmit13 및 @mxplusb

이것

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

작동하는 @cchamplin 최신 코드입니다.

코드에 대한 나의 현재 관심사는 그것을 사용하는 방법이 불분명하다는 것입니다. 어떤 명령을 실행합니까? 내 환경은 어떻게 설정해야 합니까?

다음 단계는 누군가가 그 코드를 사용해 보고 실제로 사용할 수 있는지 확인하는 것이라고 생각합니다. 작동한다면 다른 사람들도 코드를 사용할 수 있도록 단계를 문서화해야 합니다. 너무 복잡하거나 작동하지 않을 수 있습니다. 그에 따라 코드를 조정해야 합니다.

코드의 현재 상태가 만족스러우면 마스터로 다시 베이스해야 합니다. 변경 사항이 조정된 파일이 너무 많아 리베이스하기가 쉽지 않습니다. 변경 사항을 조정하여 변경 사항을 줄일 수 있으므로 더 쉽게 리베이스할 수 있습니다.

알렉스

@mxplusb @kesmit13 현재 구현은 마스터를 기반으로 했으며 여기에서 찾을 수 있습니다. https://go-review.googlesource.com/c/go/+/133946/6

@alexbrainman

코드에 대한 나의 현재 관심사는 그것을 사용하는 방법이 불분명하다는 것입니다. 어떤 명령을 실행합니까? 내 환경은 어떻게 설정해야 합니까?

이를 사용하는 방법에 대한 문서를 추가해야 한다는 데 동의합니다. 어디에 넣어야 할지 잘 모르겠지만 생각이 있으면 알려주세요. MSVC를 통해 빌드/실행하기 위해 cmd/go 문서 아래에 있어야 하는지, 아니면 CGO 문서 아래에 있어야 하는지, 아니면 완전히 다른 곳에 있어야 하는지 알 수 있습니다.

많은 테스트에서 gcc를 사용하지 않습니다. 패키지 테스트가 이유 없이 두 번 실행되는 것은 사람/컴퓨터의 시간 낭비입니다. #20982 (comment) archive/zip 패키지 테스트에서 볼 수 있듯이 두 번 실행할 필요가 없습니다.

어떻게 정렬해야 할지 잘 모르겠지만 run.bat에서 go tool dist test 호출을 대체하여 MSVC 빌드를 테스트하는 데 필요한 테스트만 선택해야 합니다. 예를 들어 일부 특정 테스트만 선택하는 방법에 대해서는 go tool dist test -h를 참조하십시오. @bradfitz 는 dist 명령에 MSVC 특정 테스트를 실행하도록 지시하는 플래그 또는 환경 변수를 만들 수 있습니다.

변경 사항에는 이미 dist에 추가된 환경 변수가 포함되어 있어 우리가 "GO_TEST_TESTINGMSVC"라는 MSVC 작업을 수행하고 있음을 알립니다. 내가 확신할 수 없는 것은 모든 테스트를 두 번 실행하지 않는 경우 MSVC만이 영향을 미칠 수 있는 항목으로 테스트를 필터링하는 방법입니다. 잠재적으로 CGO 관련 테스트로 제한할 수 있지만 CGO 테스트가 도처에 있고 dist에 이러한 테스트를 걸러내는 메커니즘이 있는지 모르겠습니다.

어디에 넣어야 할지 잘 모르겠지만 생각이 있으면 알려주세요.

문서를 업데이트하기 전에 여기에서 MSVC로 Cgo 코드를 빌드하는 방법을 설명해야 한다고 생각합니다. @mxplusb 및 @kesmit13 의 경우 변경 사항을 시도할 수 있습니다.

예를 들어 gcc를 사용하여 Cgo 코드를 빌드하려면

1. gcc.exe를 포함하도록 내 %PATH%를 조정합니다.
2. %GOROOT%\src 디렉토리에서 make.bat를 실행하여 먼저 Go 빌드
3. 표준 go build 및 go install 명령 사용

MSVC로 동일한 작업을 수행하려면 어떻게 해야 합니까?

내가 확신할 수 없는 것은 모든 테스트를 두 번 실행하지 않는 경우 MSVC만이 영향을 미칠 수 있는 항목으로 테스트를 필터링하는 방법입니다. 잠재적으로 CGO 관련 테스트로 제한할 수 있지만 CGO 테스트가 도처에 있고 dist에 이러한 테스트를 걸러내는 메커니즘이 있는지 모르겠습니다.

%GOROOT%\misc\cgo 디렉토리로 시작하겠습니다. 거기에 빌드할 수 있는 소스가 무엇이든 빌드해야 합니다. 그 이상의 것은 당신에게 달려 있습니다.

알렉스

@cchamplin 지연에 대해 죄송합니다. 이번 주에 최선을 다해 테스트하고 진행 상황을 알려 드리겠습니다.

안녕하세요, 파티에 늦어서 죄송합니다... MSVC 기능에 대한 질문에 답하거나 가능한 사람들에게 안내해 드릴 수 있습니다. 대화를 읽었지만 불행히도 MSVC에서 누락되거나 누락되지 않은 GCC 기능을 이해하는 데 익숙하지 않습니다.

안녕 여러분,
이 기능이 Go 1.14에서 출시되었습니까?
공개되면 사용 가능한 문서를 공유하십시오.
아직 출시되지 않았다면 언제 출시될지에 대한 아이디어가 있습니까?
MSVC 지원을 간절히 기다리고 있습니다.
미리 감사드립니다 :)

안녕하세요, 추가 정보에 대한 제 요청에 아무도 응답하지 않았으므로 무엇이 필요한지 잘 모르겠습니다. 누군가 저를 채워주시겠습니까?

불행히도 누군가가 이 문제에 대해 적극적으로 노력하고 있는지 모르겠습니다.

안녕하세요, 더 많은 정보를 요청하는 내 요청에 아무도 응답하지 않았습니다. ...

안녕하세요 @manbearian

어떤 요청입니까? 어떤 정보가 필요합니까?

알렉스

나는 정보를 위해 이 스레드의 앞부분에 태그가 지정되었지만 사람들이 무엇을 찾고 있는지 모르고 도움을 줄 수 없었습니다. 도움이 필요하지 않다면 좋습니다. 알려주세요.

알려주세요.

@만베리안

제안해 주셔서 감사합니다. 누가 당신을 태그했는지 모르겠습니다. 여전히 도움이 필요하면 다시 태그를 지정합니다.

알렉스

아직 출시되지 않았다면 언제 출시될지에 대한 아이디어가 있습니까?
MSVC 지원을 간절히 기다리고 있습니다.

@dhinesherode91

코드가 있고 완전합니다. 나는 이것을 정말로 막고 있는 유일한 것은 사람들이 변경 사항을 테스트하고 피드백을 제공하여 그들이 적절하게 검토되고 승인될 수 있도록 하는 것이라고 믿습니다. 나는 현재 마스터 위에 변경 사항을 리베이스하는 것을 주저합니다. 나는 그것을 5-6번 했고 매우 시간이 많이 걸리고 테스트/피드백을 받지 못했습니다. 추가 당사자가 이 테스트에 기꺼이 참여하지 않는 한 문제는 물에 잠길 수 있습니다.

추가 당사자가 이 테스트에 기꺼이 참여하지 않는 한 문제는 물에 잠길 수 있습니다.

@cchamplin 은 변경 사항을 테스트/디버깅하는 데 도움이 됩니다. 저는 툴체인에 대한 경험이 없지만 귀하의 커밋을 검토한 결과 꽤 구조화되고 문서화되어 있는 것 같습니다.

@cchamplin 구현 부분이 완료되었다는 소식을 듣게 되어
테스트 부분에 참여하는 데 관심이 있지만 GoLang의 초보자이자 Windows api(몇 주 전에 시작)의 좋은 학습자이기도 합니다. 많은 공식 리소스를 사용할 수 있는 것처럼 보이므로 MS C++에서 Windows API로 작업할 계획이었습니다. 그러나 그 다음 나는 다중 플랫폼 시스템 프로그래밍에 사용할 수 있는 언어(내 시스템 프로그래밍용)를 찾기 시작했고 GoLang에 깊은 인상을 받았습니다. 항상 내 쪽에서 공헌할 준비가 되어 있고 많은 지도가 필요합니다.

@cchamplin 리베이스하면 그 위에 구축하려고합니다. 직장에서 일부 프로젝트에서 mingw64 요구 사항을 삭제하고 싶습니다. 내 빌드 도구는 모두 MSVC용으로 설정되어 있으므로 패치를 사용하는 것 외에 다른 작업을 수행할 필요가 없습니다.

@cchamplin 또한 귀하의 CL을 살펴보았지만 cgo 도구에 대한 항목이 없었으므로 자체 패치를 시작했습니다. 사전 작업이 있습니까?

@ericlagergren

@cchamplin 또한 귀하의 CL을 살펴보았지만 cgo 도구에 대한 항목이 없었으므로 자체 패치를 시작했습니다. 사전 작업이 있습니까?

https://go-review.googlesource.com/c/go/+/133946/6에서 많은 관련 커밋이 어느 정도 Go의 cgo 부분을 직접 만지는지 이해했는지 확실하지 않습니다.

@ccahoon 알았어, 내가 놓친 게 틀림없어. cgo 도구가 업데이트되지 않았다면 그렇게 하겠다고 제안했을 것입니다.

@ericlagergren

직장에서 일부 프로젝트에서 mingw64 요구 사항을 삭제하고 싶습니다.

참고로. NS

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

변경하려면 여전히 Mingw가 작동해야 합니다. @cchamplin 변경을 사용하려면 Mingw 및 MSVC 도구가 모두 설치되어 있어야 합니다.

알렉스

@cchamplin , Mingw가 여전히 필요한 이유는 무엇입니까? 이 종속성을 제거하려면 무엇이 필요합니까?

@alexbrainman 말을 그것을 떨어 뜨리면 환상적 일 것입니다. 그러나 @cglong이 말했듯이 이것이 왜 mingw64가 필요한지 잘 모르겠습니다.

@ericlagergren @cglong CGO는 컴파일되는 C 코드에 대한 사용 가능한 유형 정보를 수집하고 보유해야 합니다. GCC에는 편리하게 구문 분석 가능한 형식으로 유형 데이터를 출력하는 플래그가 있습니다. 내가 아는 한 MSVC에는 동일한 정보를 제공하는 기능이 없습니다. go에서 도구를 빌드하려면 C 및 C++ 코드를 lex/parse하는 코드뿐만 아니라 전처리기 지시문을 이해하고 평가하는 코드가 필요합니다. Go에서 그러한 것을 구축하는 것은 상당히 큰 사업이 될 것입니다. 아마도 우리가 채택하는 방법을 알아낼 수 있지만 어딘가에 이미 사용 가능한 라이브러리가 있습니까?

@cchamplin 잡았다, 그게 내가 생각한 것입니다. libclang 및 cznic/cc와 같은 타사 라이브러리를 알고 있습니다. 그러나 불행히도 libclang은 거대하고 cznic/cc는 Windows 또는 macOS에서 테스트되지 않았습니다. PDB는 충분한 정보를 제공하지 않습니까?

CGO는 컴파일되는 C 코드에 대한 사용 가능한 유형 정보를 수집하고 보유해야 합니다. GCC에는 편리하게 구문 분석 가능한 형식으로 유형 데이터를 출력하는 플래그가 있습니다. 내가 아는 한 MSVC에는 동일한 정보를 제공하는 기능이 없습니다.

아마도 @manbearian 이 여기에 몇 가지 포인터를 제공할 수 있을까요?

GCC가 출력 유형 데이터를 특별한 형식으로 내보낸다고 말하지는 않겠습니다. 디버거용 DWARF 디버깅 데이터를 내보내고 cgo는 debug/dwarf 패키지를 사용하여 해당 데이터를 읽습니다. MSVC에는 디버그 형식도 있을 수 있습니다. 해당 형식이 어디에나 문서화되어 있으면 DWARF 데이터를 수행하는 것처럼 cgo를 사용하여 읽을 수 있습니다.

@ianlancetaylor MSVC는 PDB 파일을 내보낼 수 있습니다. https://github.com/Microsoft/microsoft-pdb 참조

FWIW, MSVC의 디버그 출력을 읽는 것은 내가 https://github.com/golang/go/issues/20982#issuecomment -648462003에서 cgo 도구를 언급할 때 말한 것입니다.

GCC가 출력 유형 데이터를 특별한 형식으로 내보낸다고 말하지는 않겠습니다. 디버거용 DWARF 디버깅 데이터를 내보내고 cgo는 debug/dwarf 패키지를 사용하여 해당 데이터를 읽습니다. MSVC에는 디버그 형식도 있을 수 있습니다. 해당 형식이 어디에나 문서화되어 있으면 DWARF 데이터를 수행하는 것처럼 cgo를 사용하여 읽을 수 있습니다.

@ericlagergren @ianlancetaylor
그래서 우리는 DWARF 데이터가 필요하며, 이는 그것의 큰 부분입니다. 그러나 이론적으로 PDB 데이터에서 동일한 정보를 얻을 수 있습니다.

내가 구체적으로 언급한 것은 GCC가 생성하는 DWARF 데이터뿐만 아니라 전처리가 발생한 후 모든 #define을 출력하는 gcc -E -dM의 출력입니다. PDB가 자체적으로 동일한 정보를 제공할 수도 있습니다...제가 회의적인 것은 실제로 컴파일할 필요 없이 MSVC가 디버그 정보/유형 정보를 어떤 용량으로도 덤핑하도록 강제할 수 있는지 여부입니다. 코드. 지금 CGO는 GCC로 바로 그 일을 하고 있습니다.

메모리에서 /EP /d1PP는 -E -dM과 유사한 것을 방출해야 합니다.

메모리에서 /EP /d1PP는 -E -dM과 유사한 것을 방출해야 합니다.

그렇다면 /d1PP가 문서화되지 않은 플래그라고 가정합니까? 나는 그것을 전에 본 적이 없다. 그러면 미리 동등한 유형 정보를 얻을 수 있습니다.

@cchamplin 예, 문서화되지

누군가 나에게 MSVC 지원의 현재 상태에 대한 간략한 요약을 제공할 수 있습니까? 나는 이 모든 저수준 컴파일러의 내용을 잘 이해하지 못합니다. C#/UWP에서 사용하려는 go 라이브러리가 있고 이미 go build 및 buildmode c-shared에서 작동하고 있습니다. 하지만: go에서 생성된 DLL이 MSVC 도구 체인에서만 설정할 수 있는 일부 컴파일러/링커 플래그를 놓치기 때문에 해당 앱은 Windows Store에서 허용되지 않습니다.

그래서: 여기서 이것을 어떻게 테스트할 수 있습니까? 모든 조언을 주시면 감사하겠습니다! 감사합니다!

go에서 생성된 DLL이 MSVC 도구 체인에서만 설정할 수 있는 일부 컴파일러/링커 플래그를 놓치기 때문에 해당 앱은 Windows Store에서 허용되지 않습니다.

@TopperDEL 은 Windows Store에서 누락된 컴파일러 플래그를 알려줍니까? mingw-64가 지원하는 경우 dll을 빌드할 때 항상 올바른 플래그와 함께 -extldflags 를 사용할 수 있습니다.

@qmuntal 예, 다음을 수행합니다.
"앱을 연결할 때 필요한 링커 옵션인 SAFESEH, DYNAMICBASE, NXCOMPAT 및 APPCONTAINER를 적용하십시오."

나는 이미 시도했다
go build -ldflags="-s -w '-extldflags=-Wl,--dynamicbase,--high-entropy-va'" -o storj_uplink.dll -buildmode c-shared

그러나 그것은 상점 제출과 관련하여 아무 것도 변경하지 않았습니다. 그리고 내 이해에서 적어도 SAFESEH는 MSVC 전용입니다. 맞습니까?

"앱을 연결할 때 필요한 링커 옵션인 SAFESEH, DYNAMICBASE, NXCOMPAT 및 APPCONTAINER를 적용하십시오."

Mingw-w64에서 SAFESEH 또는 APPCONTAINER 플래그를 활성화하는 쉬운 방법을 모르겠습니다. 아마도 이 프로젝트 https://github.com/status-im/mingw-windows10-uwp에서 지침을 제공할 수 있습니다.

반면에 DYNAMICBASE 및 NXCOMPAT은 go 1.16(#41421 참조)에서 기본적으로 활성화되지만 언급한 대로 이미 -extldflags 와 함께 사용할 수 있습니다. 사실 저는 일부 프로젝트에서 그렇게 하고 있습니다.

@qmuntal 감사합니다! 그래서 적어도 위의 extldflags가 맞아야합니까?
Windows 10-uwp용 mingw를 살펴보겠습니다.