Go: cmd/link : prend en charge les fichiers objet msvc

/cc @alexbrainman

@xoviat quel est le problème que vous rencontrez ? Je dois pouvoir le reproduire ici. Alors, s'il vous plaît, fournissez toutes les étapes que je devrai suivre pour reproduire cela.

Merci

Alexis

PS : je n'aurai pas d'ordinateur avant fin juillet. Je vais regarder ça alors.

quel est le problème que vous rencontrez ?

Je ne l'ai pas encore essayé, mais j'aimerais appeler spécifiquement les fonctions c dans les fichiers objet msvc en les liant en tant que .syso avec l'éditeur de liens go. Tout ce que j'ai lu indique que ce n'est pas possible mais je vais créer une procédure pour reproduire l'erreur spécifique qui se produit.

appelez spécifiquement les fonctions c dans les fichiers objet msvc en les liant en tant que .syso avec l'éditeur de liens go

Avez-vous essayé de les intégrer dans une DLL et de les utiliser depuis l'intérieur de la DLL ?

Je vais créer une procédure pour reproduire l'erreur spécifique qui se produit.

Je vous en prie. Merci.

Alexis

Avez-vous essayé de les intégrer dans une DLL et de les utiliser depuis l'intérieur de la DLL ?

C'était en fait mon plan initial. J'utilise swig, il n'est donc pas très pratique de compiler le code c généré séparément, puis de réécrire les fonctions en tant qu'exportations DLL. Ce n'est pas difficile, mais c'est ennuyeux lorsque le workflow avec gcc n'est que de go generate; go build .

Bon, j'ai une procédure. Commencez par ces fichiers :

bonjour.go :

package main

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

func main() {
    C.hello()
}

Bonjour c:

#include <stdio.h>

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

puis exécutez ces commandes (avec msvc sur le chemin):

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

Résultat:
Warning: corrupt .drectve at end of def file

Lors de l'exécution du fichier produit :

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

Je n'ai pas la commande cl installée sur mon pc. Comment installer msvc ?

Merci.

Alexis

Vous avez besoin des "outils de construction 2017" ici . En fait, Microsoft permet désormais à quiconque d'utiliser Visual Studio gratuitement tant qu'il ne s'agit pas d'un développement commercial. Si c'est trop compliqué, je peux juste vous donner le fichier objet si vous voulez.

Si seulement c++ n'était pas une chose, je n'aurais pas à m'inquiéter à ce sujet. Mais c'est le cas, alors la douleur continue...

Vous avez besoin des "outils de construction 2017" ici.

J'ai compris. Merci.

Si c'est trop compliqué, je peux juste vous donner le fichier objet si vous voulez.

Oui, s'il vous plaît, postez hello.obj quelque part.

Penser à cela un peu plus. Vous utilisez en fait gcc pour lier un fichier objet compilé avec le compilateur msvc. Pouvez-vous essayer de faire votre exercice, mais en remplaçant l'étape "go build" par gcc liant hello.obj à un programme C? Cela a peut-être déjà été fait. Je suppose que si nous savons comment faire cela, nous pourrions peut-être faire la même chose avec Go.

Alexis

AFAIK lld https://github.com/llvm-mirror/lld prend en charge les fichiers objet msvc.

Le fichier objet est ici : https://github.com/xoviat/msvcgo/blob/master/hello.syso

lld https://github.com/llvm-mirror/lld prend en charge les fichiers objet msvc

Go utilise l'éditeur de liens gcc (pas lld) sous Windows.

Le fichier objet est ici : https://github.com/xoviat/msvcgo/blob/master/hello.syso

Je vais l'essayer quand je rentre à la maison en août. Merci.

Alexis

Go utilise l'éditeur de liens gcc (pas lld) sous Windows.

Je connais. Mais lld est la meilleure documentation open source du format d'objet msvc.

En fait, j'obtiens la même erreur de ld, donc l'erreur vient certainement de ld.

En fait, j'obtiens la même erreur de ld, donc l'erreur vient certainement de ld.

Oui. Nous devons trouver comment construire un programme C en compilant une partie avec msvc et en établissant un lien avec gcc.

Alexis

Pardonnez mon ignorance, mais qu'est-ce que la liaison gcc exactement ? Relie-t-il la sortie de l'éditeur de liens go ?

Exécution d'objconv sur les fichiers objets à convertir en elf :

objconv -felf hello.obj hello.syso

Nous avons maintenant ces erreurs :

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

Peut-être que stdio est interdit?

Pardonnez mon ignorance, mais qu'est-ce que la liaison gcc exactement ? Relie-t-il la sortie de l'éditeur de liens go ?

Vous utilisez 2 programmes pour construire votre programme Go :

• le compilateur convertit vos fichiers .go (1 package à la fois) en un fichier objet stocké dans le répertoire %GOPATH%/pkg ;
• éditeur de liens qui crée le fichier .exe final à partir des fichiers objets sous %GOPATH%/pkg.

Parfois (lorsqu'un de vos packages utilise Cgo), l'éditeur de liens Go appelle l'éditeur de liens externe pour rechercher tous les bits implémentés en C. Imaginez que vous appelez printf à partir de votre code C. Le code C printf compilé doit faire partie de l'exécutable Go, mais l'éditeur de liens Go ne sait pas où l'obtenir. L'éditeur de liens Go appelle donc l'éditeur de liens externe pour inclure ce code.

Current Go utilise le compilateur/éditeur de liens gcc pour compiler et lier le code C (nous utilisons mingw gcc). Si vous allez compiler votre code C avec un compilateur différent (par Microsoft), vous devrez utiliser l'éditeur de liens correspondant (par Microsoft) pour trouver tout le code C externe créé par le compilateur.

Donc, je suppose que je me suis trompé en suggérant d'utiliser l'éditeur de liens gcc. Pour le scénario général, vous devrez utiliser à la fois le compilateur et l'éditeur de liens Microsoft. Nous devrons déterminer ce que l'éditeur de liens Microsoft requiert comme entrée et faire correspondre cela.

Vous pourriez vous en tirer sans MC linker, si votre code C n'a pas de code externe. Veuillez essayer un programme C vraiment simple (comme celui qui ajoute 2 entiers ou quelque chose du genre). Cela pourrait fonctionner comme vous l'avez décrit ci-dessus.

Alexis

Peut-être que stdio est interdit?

Je suppose que vous devez appeler l'éditeur de liens Microsoft pour trouver ce code.

Alexis

je ne suis pas sûr mais

objconv -felf hello.obj hello.syso

Peut-être devriez-vous essayer de faire coff ou omf au lieu d'elf ?

Peut-être devriez-vous essayer de faire coff ou omf au lieu d'elf ?

@xoviat oui, vous ne devez pas convertir les fichiers .obj en elf, la version Windows de gcc génère des fichiers pe/coff comme tout autre compilateur Windows.

Alexis

l'éditeur de liens Go appelle l'éditeur de liens externe pour rechercher tous les bits implémentés en C.

Quelle est la commande spécifique utilisée ? Si je connais la commande mingw, je peux peut-être suivre un chemin de comparaison de fichiers pour essayer de faire en sorte que msvc corresponde à ce que mingw publie.

Vous pouvez voir le commentaire exact en exécutant go build -ldflags=-v .

Bon, d'après ce que je peux dire :

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

Go semble créer un répertoire temporaire avec ces fichiers. Existe-t-il un moyen de préserver le répertoire temporaire afin que je puisse inspecter son contenu ?

Essayez go build -work

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

Les fichiers objets restent dans ce répertoire.

L'option -work ne conservera en fait pas les fichiers temporaires créés par l'éditeur de liens. Pour le moment, il vous suffit de modifier les sources de l'éditeur de liens pour ne pas supprimer le répertoire. Nous devrions probablement ajouter une option pour cela, d'une manière ou d'une autre.

Pour le moment, il vous suffit de modifier les sources de l'éditeur de liens pour ne pas supprimer le répertoire.

Si cela ne vous dérange pas, je vais attendre que cela soit implémenté dans HEAD afin de ne pas avoir à faire un travail répétitif.

Existe-t-il un moyen de préserver le répertoire temporaire afin que je puisse inspecter son contenu ?

Le programme cmd/link a l'indicateur -tmpdir pour cela. Vous pouvez l'utiliser comme ceci :

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>

Alexis

Ceci est juste pour ma propre référence, mais cela doit être porté sur 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);
}

Je ne sous-estimerais pas le temps qu'il me faudra pour accomplir cette tâche car je ne suis pas du tout familiarisé avec l'assemblage.

• [x] Comprendre ce que fait l'assemblage
• [x] Assemblage du port vers MSVC
• [x] Comprendre _beginthread vs CreateThread
• [x] Passer à CreateThread

Aussi, symboles non définis :

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

D'accord, alors avancez ici plus rapidement que prévu !

Tout : asm_amd64.s est-

Il semble que gcc ne l'assemble pas, ce qui signifie qu'il s'agit probablement d'un assemblage. Et puis la question devient : comment l'assembler avec l'assembleur go en un objet.

L'intention est que runtime/cgo/asm_amd64.s soit assemblé dans un objet Go, puis cmd/link le lie avec tous les autres objets Go dans un seul objet système, puis l'éditeur de liens système relie cet objet système unique plus tous les dépendances cgo dans le programme final.

Existe-t-il un moyen d'assembler cet objet pour le moment à des fins de test ? Comme gcc -c asm_amd64.s sauf avec go?

L'intention est que runtime/cgo/asm_amd64.s soit assemblé dans un objet Go, puis cmd/link le lie avec tous les autres objets Go dans un seul objet système, puis l'éditeur de liens système relie cet objet système unique plus tous les dépendances cgo dans le programme final.

Pour l'instant j'ai trouvé ces objets :

• go.o : évidemment de la chaîne d'outils go
• _cgo_.o : généré par gcc, inutilisable
• 000000.o : généré par gcc, inutilisable
• 000001.o : Mise à jour : en fait généré par l'éditeur de liens go, mais contient des symboles gcc. Inutilisable.

go.o est le plus gros objet.

@ianlancetaylor

Je ne pense pas que ce que tu dis soit correct. crosscall_amd64 se trouve dans 000001.o, mais ce fichier n'a pas "tout le code 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

Ce fichier a évidemment été généré par gcc, ce qui est trop tard dans le processus.

Existe-t-il un moyen d'assembler cet objet pour le moment à des fins de test ? Comme gcc -c asm_amd64.s sauf avec go?

asm_amd64.s fait partie du package d'exécution. Vous pouvez voir comment la commande "go build" utilise le fichier asm_amd64.s, comme :

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

Alexis

Merci.

Le symbole crosscall_amd64 est défini dans le fichier runtime/cgo/gcc_amd64.s. Ce fichier est compilé par GCC (comme le sont tous les fichiers runtime/cgo/gcc_*). Il n'est donc pas combiné dans le seul fichier go.o qui contient tout le code Go. Le fichier dont nous parlions auparavant, runtime/cgo/asm_amd64.s, définit le symbole crosscall2 . Vous trouverez ce symbole dans go.o.

Merci.

D'accord, j'ai réussi à lier un exécutable qui se bloque sur une violation d'accès alors que dans
go.runtime.rt0_go+5F --> go.___acrt_stdio_initializer.

C'est tout le temps que j'ai pour l'instant ; J'y reviendrai plus tard.

@alexbrainman C'est correct.

@alexbrainman Vous aurez besoin de MSVC pour continuer. Faites-moi savoir si vous avez besoin d'aide pour cela.

Vous aurez besoin de MSVC pour continuer.

J'installe ceci https://www.visualstudio.com/downloads/#build -tools-for-visual-studio-2017

Que dois-je faire une fois installé ?

Alexis

Une fois que vous l'avez installé, vous devez créer "libgo", qui est la bibliothèque go. Copiez les fichiers suivants du dossier cgo :

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

Nous devons ajuster gcc_windows_amd64.c pour qu'il soit compatible avec MSVC. Modifiez la fonction comme suit :

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

Créez un nouveau fichier dans le dossier avec tous ces fichiers appelé "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

Faites-moi savoir quand vous avez le dossier structuré comme demandé.

Au fait, merci d'avoir travaillé dessus et d'y être allé. Vous avez créé un langage vraiment magique.

Faites-moi savoir quand vous avez le dossier structuré comme demandé.

J'ai réussi à construire libgo.lib comme vous l'avez décrit ici https://github.com/golang/go/issues/20982#issuecomment -327365063
Que devrais-je faire ensuite?

Alexis

Bon, maintenant nous avons besoin des fichiers suivants :

• libgo.lib
• aller
• bonjour.cgo2.o
• Bonjour c

hello.c est le suivant :

#include <stdio.h>

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

Pour obtenir hello.cgo2.o et go.o , vous devez commencer par le fichier suivant :

package main

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

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

appelé "hello.go"

Configurez un script powershell qui copie en continu les fichiers de $ env:TMP :

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

Ensuite, exécutez go build avec hello.c et hello.go dans le dossier. Vous devriez pouvoir récupérer les fichiers requis à partir de l'emplacement où ils ont été copiés.

Une fois que vous avez les fichiers spécifiés ci-dessus, vous pouvez construire avec :

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

Faites moi savoir si vous avez des questions.

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

Cela crée un fichier exécutable go.exe, mais il ne s'exécute pas. Je ne vois aucun code asm sensé là-bas. Première instruction juste sauter dans nulle part. C'est juste un gâchis.

Vous devriez peut-être commencer par quelque chose de très simple. Ecrivez un fichier asm (Go asm file) avec une seule fonction asm qui exécute "INT $3" et n'a rien d'autre. Et essayez de construire un programme exécutable à partir de celui-ci - le programme devrait exécuter votre fonction au tout début.

Construisez-le peut-être d'abord en utilisant les outils Go (et également en utilisant gcc si nécessaire), puis essayez de faire de même en utilisant MSVC.

Alexis

Alex, merci pour ton aide. Je vais travailler dessus.

Je vais joindre ces deux articles ici pour ma propre référence. Sinon, je n'ai pas d'autre mise à jour.

En fait, j'ai fait fonctionner un programme go assez complexe qui n'utilise que la bibliothèque msvc. Il s'avère que l'éditeur de liens msvc et llvm-lld n'ont pas correctement géré la section .bss .

Une fois que j'ai patché l'éditeur de liens, le programme peut s'exécuter.

Malheureusement, go build casse lorsqu'il génère _cgo_.o / _all.o . Est-il possible de faire la lumière sur les logiques derrière la génération de ces deux fichiers dans cgo ?

Vous pouvez exécuter go tool cgo pour exécuter directement cgo. Les sources sont ici : https://github.com/golang/go/tree/master/src/cmd/cgo

De plus, si vous pouviez le faire fonctionner, ce serait génial. Je n'ai tout simplement pas consacré de temps à cela, donc il n'y a eu aucun progrès. Désolé pour ça.

J'ai déjà des programmes qui peuvent fonctionner correctement à travers une série de couture à la main - ce que j'essaie de faire ici, c'est de voir si le processus peut être réintégré dans go pour le rendre moins douloureux. :-)

Si vous pouvez documenter le processus de couture à la main, je pourrai peut-être vous aider.

Rien qu'en regardant, _cgo_.o semble être produit comme ceci (simplifié) :

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

À partir d'ici : https://github.com/golang/go/blob/b4c84a1b010f012668b5e3ccaf63f609cd11c5fe/src/cmd/go/internal/work/exec.go#L1975

Voir aussi ici pour la documentation :
https://github.com/golang/go/blob/840f2c167f1d5196559d8a1e77c370960e66d34e/src/cmd/cgo/doc.go#L607

Idéalement, nous écririons un programme go qui prétraite les fichiers objets afin qu'ils soient compatibles avec link.exe pour une friction minimale, mais c'est en quelque sorte un objectif étendu.

Merci pour le pointeur - je vais écrire le processus sous peu.

Malheureusement, je ne pense pas que la liaison puisse être effectuée via link.exe moins que nous ne modifiions gcc pour émettre des données non initialisées dans la section .data au lieu de la section .bss -- mais nous pouvons corriger définitivement llvm-lld pour reconnaître la section .bss (ce que j'ai fait).

Nous devons aborder _cgo_.o et _all.o séparément. J'ai quelques questions à leur sujet :

(1) Il semble que _cgo_.o ne soit pas l'exécutable final car il ne contient pas le runtime go. Il semble que le compilateur examine ses symboles DWARF pour comprendre la définition de la structure. Le problème est qu'il est difficile de générer un exécutable si vous souhaitez établir un lien avec un certain nombre de bibliothèques externes, en particulier celles générées par msvc.

Est-il possible d'éviter cette étape ?

(2) go utilisez GNU ld pour assembler tous les fichiers objets dans _all.o passant le -Wl,-r dans GCC. C'est problématique car (1) il ne semble pas qu'un autre éditeur de liens ait cette fonctionnalité, et (2) la commande est affectée par le CGO_LDFLAGS . Par exemple, la commande suivante génère des résultats incorrects :

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

Il génère un exécutable au lieu d'un fichier objet groupé.

Est-il possible d'éviter cette étape en mettant simplement tous les fichiers objets dans le .a généré directement ?

@zooba Quelles sont les chances que MSFT mette à jour link.exe avec ce patch ?

Malheureusement, je ne pense pas que la liaison puisse être effectuée via link.exe à moins que nous ne modifiions gcc pour émettre des données non initialisées dans la section .data au lieu de la section .bss - mais nous pouvons certainement corriger llvm-lld pour reconnaître la section .bss (c'est ce que j'ai fait).

Donc, en supposant que MSFT ne met pas à jour link.exe (ce qui est probable), il serait bon de compiler les fichiers objets avec cl.exe plutôt que gcc .

Il semble que _cgo_.o ne soit pas l'exécutable final car il ne contient pas le runtime go.

C'est correct, il y a essentiellement deux ensembles de fichiers objet (je pense) qui sont liés ensemble à la fin. Le fichier go.o (IIRC) contient tout le code go + runtime, et les autres objets contiennent le code C. Il existe des routines d'assemblage pour sauter entre les deux ensembles d'objets.

De plus, nous avons besoin de clang pour compiler les fichiers d'assemblage Unix.

Pour nos besoins, -Wl,-r sera identique à l'exécution de lib.exe [object files] /OUT:obj . L'option signifie « lien incrémentiel », ce qui signifie « prendre des fichiers d'entrée, effectuer un travail, puis cracher un autre fichier objet ». Si nous ne nous soucions pas de la partie "travailler" pour l'instant, nous pouvons simplement considérer l'exigence comme "prendre des fichiers d'entrée et/ou des fichiers objet et cracher un autre fichier objet", sauf dans notre cas, le fichier objet sera une bibliothèque.

Vous pouvez dire à GCC d'éviter de mettre des variables dans la section .data plutôt que dans la section .bss en utilisant l'option -fno-zero-initialized-in-bss .

Notez que sur le pourboire, nous n'utilisons plus -Wl,-r lors de la construction du code cgo.

Il ne devrait pas être nécessaire que cmd/link comprenne les fichiers objet MSVC afin de les utiliser en tant que fichiers .syso . Ces fichiers sont simplement transmis à l'éditeur de liens externe de toute façon. Je pense donc que ce qui est nécessaire ici, c'est d'appeler l'éditeur de liens MSVC en tant qu'éditeur de liens externe, ce que vous devriez pouvoir faire en utilisant l'option -extld . Si vous le faites déjà, mes excuses; dans ce cas, qu'est-ce qui ne va pas ?

Si vous le faites déjà, mes excuses; dans ce cas, qu'est-ce qui ne va pas ?

IIRC, link.exe barfs sur les objets générés par gcc.

Certes, vous devrez également utiliser le compilateur de MSVC C, en définissant la variable d'environnement CC manière appropriée. Je ne pense pas que cela fonctionnera de combiner des objets GCC et des objets MSVC dans un seul lien.

Mais vous rencontrez ensuite le problème de précompilation des bibliothèques d'exécution C. Et si vous essayez de les recompiler, vous rencontrez le problème que cl ne peut pas compiler l'assembly Unix. Et donc vous portez des parties des bibliothèques d'exécution et essayez de les lier, ce que j'ai fait et j'ai échoué.

Quelque part en cours de route, cl compile mal une partie clé du code. Mon idée pour résoudre ce problème serait de factoriser le code MSVC dans une DLL avec une API C plate, puis de compiler de manière incrémentielle davantage de bibliothèques d'exécution jusqu'à ce qu'il cesse de fonctionner.

L'idée de @haohui pour résoudre le problème était différente. Plutôt que de corriger la racine du problème, il l'a contourné en corrigeant l'éditeur de liens. Évidemment, il a eu plus de succès que moi, mais c'est probablement parce que son approche est, avec le recul, plus susceptible de fonctionner que la mienne.

Ce que je recommanderais à ce stade (à mon humble avis) est de compiler de manière incrémentielle une plus grande partie de la bibliothèque d'exécution avec cl jusqu'à ce qu'elle cesse de fonctionner ou jusqu'à ce que vous n'ayez plus de code gcc. Vous savez alors exactement où est le problème.

Et avec le patch de l'éditeur de liens, aucune DLL n'est nécessaire.

Le correctif de llvm-lld est disponible sur https://bugs.llvm.org/show_bug.cgi?id=35283

Je vais prendre un peu de temps pour donner un exemple.

+1 @haohui Merci beaucoup d'avoir fait avancer ce

@haohui À quelle version de llvm votre correctif s'applique-t-il ? Des instructions sur la façon d'utiliser votre correctif et comment établir un lien avec les fichiers MSVC ?

En ce qui concerne les fichiers _cgo_.o et _all.o , j'ai eu le même problème, donc peut-être qu'un correctif pour ce problème peut également être un correctif pour l'autre problème : https://github.com/golang/go /questions/17014

Merci pour tout ce travail. Il semble que de bons progrès soient réalisés. Les nouvelles fonctionnalités sont gelées jusqu'à Go 1.11, modifiant ainsi le jalon.

Alors je me suis lancé là-dedans hier soir. Il est possible de tout construire via msvc:cl puis de tout lier via msvc:link. Les enjeux sont pourtant légion.

Donc, au-delà des problèmes simples comme msvc:cl ne prenant pas entièrement en charge C99 (pour le moment, nous ne pouvons pas gérer le type _Complex). Il y a plus de problèmes systémiques avec la combinaison des bibliothèques PE construites par go internals et celles construites par msvc. Plus précisément, msvc:link supprime les segments .bss (je pense que cela peut simplement jeter ces données dans .data), ce qui est un problème car il semble que l'assembleur go SB (pseudo reg) entraîne un adressage incorrect si .bss est déplacé .

Ma pensée initiale serait d'essayer de faire en sorte que l'assembleur place les éléments qui entreraient dans .bss et .noptrbss dans .data et .noptrdata respectivement. Je ne suis même pas sûr que cela soit possible ; mon bidouillage n'a pas réussi et l'adressage est complètement arrosé.

Je ne pense pas qu'il soit possible d'utiliser link.exe pour le moment. Je pense que nous devrions commencer par lld-link.exe

Si l'idée derrière cela est que nous pouvons patcher lld-link pour ne pas déplacer les données .bss, je comprends l'attrait. De manière réaliste, si l'objectif est de prendre en charge la chaîne d'outils msvc réelle, alors passez à la compilation interne en plaçant les données dans .bss/.noptrbss car cela devra être traité.

Ne pouvons-nous pas simplement redistribuer lld-link.exe avec go ? Cela semble être le chemin le moins risqué pour prendre en charge les fichiers objet MSVC tant que LTCG n'est pas activé. Je comprends que ce n'est pas idéal, mais nous sommes confrontés à une contrainte de ressources.

Il permet également des progrès incrémentiels qui sont la meilleure stratégie.

D'accord, quelques bonnes nouvelles de suivi, j'ai pu passer une heure à travailler dessus pendant le déjeuner.

Pour le moment, j'ai l'exemple de plus tôt dans le problème:

- 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

Le binaire est entièrement construit avec la chaîne d'outils MSVC et Go (pas de GCC ou autre LLVM installé).

Résultats:

• Avoir les outils Go/link.exe de sortie des données .bss pour les assemblys internes vers .data était finalement assez trivial
• Plusieurs pièces ASM ont dû être ajustées pour msvc
• Quelques #defs GCC ont été calés
• Plusieurs petits ajustements ont dû être apportés à certains des fichiers .c générés par cgo
• Les nombres complexes devront être calés, pour le moment ils ne sont pas pris en charge
• Il est probable que des indicateurs supplémentaires devront être ajoutés directement à la construction ou au lien pour la prise en charge de msvc, les ldflags, etc. ne seront pas suffisants

Prochaines étapes:
Si j'ai le temps ce week-end, je travaillerai sur l'intégration de mes modifications dans un fork et sur la fonctionnalité derrière les drapeaux dans build/link. Ensuite, je ferai passer un RP pour examen afin que nous puissions déterminer les types. Je ne suis pas sûr à 100% que le déplacement des données .bss n'aura pas d'impact quelque part.

Le seul inconvénient auquel je peux penser est que cela fera exploser la taille du binaire, mais ça devrait aller.

D'accord!

Désolé, il m'a fallu quelques jours de plus pour le mettre en place. Ainsi, le premier brouillon d'un correctif peut être trouvé ici : https://github.com/cchamplin/go/commit/69a5cfc1dd0106fd8a2928a83e4c7001e81e89b8 :: https://github.com/cchamplin/go/tree/msvc_toolchain_support

C'est encore difficile, mais j'ai réussi à créer du code avec msvc.

Ce serait génial si les gens pouvaient commencer à tester cela maintenant et me rapporter les bogues afin que je puisse l'obtenir dans un meilleur endroit pour l'amont. Aussi, si quelqu'un veut participer à l'écriture de tests, ce serait génial!

Usage:

go build -compiler msvc [path]

• Les nombres complexes ne sont actuellement pas pris en charge jusqu'à ce que je découvre si nous pouvons les faire fonctionner.
• Je n'ai aucune idée de ce qui se passe si vous essayez de créer le runtime go avec le compilateur msvc.
• gcc est toujours nécessaire et utilisé par gco pour obtenir des définitions et des données de type lors de la compilation, il n'est pas utilisé pour construire quoi que ce soit ). Je ne sais pas si nous pouvons contourner cela, msvc n'a rien qui puisse faire le même nain et #define dumps de code... si quelqu'un a des idées à ce sujet, ce serait génial

Le correctif lié crée un problème d'amorçage.

@alexbrainman Comment et où est-il déterminé quels fichiers seront copiés dans pkg/boostrap/src/bootstrap pendant la phase de boostrapping toolchain1 ?

cc @alexbrainman

Le correctif lié crée un problème d'amorçage.

Je ne sais pas comment fonctionne le bootstrapping de nos jours. Mais je suis sûr que d'autres ( @rsc et @ianlancetaylor) peuvent vous aider.

Je me demande comment @cchamplin exécute make.bat si l'amorçage ne fonctionne pas.

Alexis

@xoviat Je ne sais pas quel est le problème, mais la liste des répertoires d'amorçage se trouve dans cmd/dist/buildtool.go.

Hé @alexbrainman , @ianlancetaylor , @xoviat désolé pour ça, je suppose que j'aurais dû vérifier plus en profondeur.

J'ai mis à jour la branche ici https://github.com/cchamplin/go/commit/69a5cfc1dd0106fd8a2928a83e4c7001e81e89b8 avec un correctif pour le problème d'amorçage, je pense qu'il devrait s'amorcer correctement maintenant.

J'ai dû copier certains répertoires /src/internal/syscall dans cmd/internal/msvc. Est-ce que ça va être un gros problème ? Je ne sais pas comment accéder au registre sans utiliser src/internal.

J'ai dû copier certains répertoires /src/internal/syscall dans cmd/internal/msvc. Est-ce que ça va être un gros problème ? Je ne sais pas comment accéder au registre sans utiliser src/internal.

Je ne sais pas comment c'est fait de nos jours, mais je soupçonne que cmd/dist peut le faire sans que vous ayez à copier manuellement les fichiers source. Je suis certain que Russ ou Ian vous aideront lorsque vous serez prêt à soumettre du code.

Je pense qu'il est temps pour @bradfitz et @ianlancetaylor de décider comment procéder ici. Voulons-nous que Go prenne en charge les outils de construction Microsoft ainsi que gcc ? Nous devrions installer les outils Microsoft correspondants sur nos constructeurs (nous devrions le faire avant de commencer à accepter les CL). Il faudrait probablement introduire de nouvelles variables d'environnement. Nouvelle documentation.

Si la réponse est oui, alors @cchamplin devra soumettre ses modifications de code selon https://golang.org/doc/contribute.html Seriez-vous prêt à le faire ? Le changement est assez important, il doit donc être divisé en CL plus petits, afin qu'ils puissent être examinés et soumis séparément. Chaque modification devra avoir all.bat PASS avant de pouvoir être soumise. Ce serait bien si nous pouvions voir toutes les CL avant de commencer à soumettre la première CL.

Merci.

Alexis

Voulons-nous que Go prenne en charge les outils de construction Microsoft ainsi que gcc ?

Juste une note, ce patch facilite également #17014 pour lequel j'ai déjà un patch en cours.

Si la réponse est oui, alors @cchamplin devra soumettre ses modifications de code selon https://golang.org/doc/contribute.html Seriez-vous prêt à le faire ? Le changement est assez important, il doit donc être divisé en CL plus petits, afin qu'ils puissent être examinés et soumis séparément.

Oui, et le rompre ne devrait pas être une grosse affaire. J'ai juste besoin de savoir si c'est quelque chose qui est susceptible d'entrer ou non avant de faire l'effort de nettoyer tout le code, d'écrire la documentation, de créer des tests, etc.

Voulons-nous que Go prenne en charge les outils de construction Microsoft ainsi que gcc ?

Dans mon esprit, la réponse est oui. Les compilateurs eux-mêmes sont gratuits avec VS Community, et ne pas avoir une prise en charge complète de Windows est vraiment frustrant. Je ne devrais pas avoir à monter une machine Linux pour compiler github.com/Microsoft/hcsshim (par exemple), car une chaîne d'outils Windows n'est pas prise en charge.

Quelle serait la raison de ne pas prendre en charge une chaîne d'outils Windows ?

Je pense qu'en principe, c'est bien de prendre en charge les fichiers objet MSVC. Nous aurions besoin d'un constructeur.

Ma principale préoccupation est de savoir dans quelle mesure le format peut changer entre les versions Windows ou MSVC. Le format ELF utilisé sur la plupart des autres plates-formes est très stable ; nous devons très rarement modifier la prise en charge d'ELF d'une autre manière que d'ajouter la prise en charge de nouveaux processeurs. Le format de fichier MSVC est-il également stable ?

Les formats associés à la chaîne d'outils MSVC sont assez stables. Le plus gros problème va être de prendre en charge les outils eux-mêmes. Microsoft a tendance à déplacer des éléments (fichiers et entrées de registre) entre les versions de Visual Studio. La plupart de ces éléments sont configurables (au moins dans le correctif que j'ai écrit), mais il existe toujours la possibilité que lorsqu'une nouvelle version majeure de Visual Studio est publiée, elle peut ne pas être compatible en tant que chaîne d'outils de construction sans modifications de Go. Cependant, toutes les versions antérieures prises en charge de Visual Studio continueraient de fonctionner.

Pour autant que je sache, le format COFF a une stabilité raisonnable si vous vous exposez uniquement à l'ABI C (pas C++). Il est également abondamment documenté et LLVM fournit une implémentation de référence.

@cchamplin Je recommanderais d'exiger des utilisateurs qu'ils invoquent vcvarsall.bat avant de se lier à MSVC. Cela réduira considérablement la maintenance à près de zéro.

Nous aurions besoin d'un constructeur.

@ianlancetaylor une fois que les objets

Je suis sûr que certaines personnes préféreront utiliser les outils cygwin, et ils fonctionnent déjà et nous voulons qu'ils continuent à fonctionner, donc je pense que nous avons besoin de deux constructeurs.

Hé, il semble d'après le bas de ce fil que vous avez réglé vos problèmes MSVC. Mais si vous rencontrez des problèmes, je fais partie de l'équipe MSVC. N'hésitez pas à me faire un ping sur github ou par e-mail (pré[email protected])

Nous aurions besoin d'un constructeur.

Oui. Et nous devrions probablement commencer par changer nos constructeurs existants pour que les outils de construction MS soient installés. Nous pouvons donc les utiliser car nous acceptons les CL pour ce problème.

Nous pouvons installer à la fois des outils gcc et des outils Microsoft sur tous nos constructeurs. Pouvons-nous exécuter all.bat qui teste à la fois les outils gcc et Microsoft en une seule fois ? Sinon, nous aurions besoin d'avoir différents constructeurs configurés pour différents outils. Quels sont les paramètres qui contrôlent quels compilateurs et éditeurs de liens externes sont utilisés ?

Ma principale préoccupation est de savoir dans quelle mesure le format peut changer entre les versions Windows ou MSVC.

Vous n'avez pas de compilateur installé avec Windows. Vous devez l'installer vous-même. Tout comme nous le faisons avec gcc. Nous installons la version que nous aimons. Nous pourrions même exécuter différentes versions de gcc sur différents constructeurs.

Le format de fichier MSVC est-il également stable ?

Je n'en sais rien. Je soupçonne que vous utilisez simplement les outils fournis.

Alexis

Ma principale préoccupation est de savoir dans quelle mesure le format peut changer entre les versions Windows ou MSVC. Le format ELF utilisé sur la plupart des autres plates-formes est très stable ; nous devons très rarement modifier la prise en charge d'ELF d'une autre manière que d'ajouter la prise en charge de nouveaux processeurs. Le format de fichier MSVC est-il également stable ?

Oui, COFF est très stable.

@bradfitz et @ianlancetaylor de quoi avons-nous besoin pour qu'un constructeur Windows soit disponible pour tester les modifications apportées à ce problème ? Voir mes questions sur https://github.com/golang/go/issues/20982#issuecomment -370719472

Merci

Alexis

est-ce que go supporte l'objet msvc maintenant?

Le changement https://golang.org/cl/110555 mentionne ce problème : debug/pe: parse the import directory correctly

@alexbrainman @bradfitz @ianlancetaylor :

J'ai fait la plupart du travail requis, je crois, pour nettoyer le patch et le casser en morceaux plus digestes. Je crois que je suis sur le point d'être prêt pour une soumission réelle au projet. Je suppose que j'ai besoin de savoir si je dois attendre des informations sur la situation du constructeur avant de soumettre le code ou si je dois le faire dès que possible ?

Vous pouvez envoyer les CL à tout moment, mais quelqu'un doit configurer un constructeur. Sinon, nous n'avons aucun moyen de les tester.

@johnsonj , pourriez-vous ajouter les outils de compilation MSVC à nos images Windows ?

J'aimerais idéalement ne pas ajouter de nouveau type d'hôte et faire en sorte que 1 à 3 de nos types d'hôtes Windows existants disposent des outils MSVC en plus de Cygwin. Et ensuite, nous pouvons ajouter d'autres configurations de constructeur en plus de ces types d'hôtes modifiés.

/cc @andybons @bcmills as FYI (pour savoir comment les choses se

@johnsonj , pourriez-vous ajouter les outils de compilation MSVC à nos images Windows ?

@cchamplin, je vous suggère d'essayer d'ajouter vous-même les outils nécessaires au constructeur. Personne d'autre, mais vous savez ce qui est requis. Vous pouvez regarder dans le répertoire golang.org/x/build/env/windows pour des instructions complètes. En particulier, vous souhaitez probablement ajouter plus de lignes dans startup.ps1. Une fois que vous savez ce qui doit changer dans ce directeur, apportez les modifications et envoyez votre modification pour examen via https://golang.org/doc/contribute.html Une fois acceptées, nous pourrions mettre à jour les constructeurs en utilisant ces instructions.

J'aimerais idéalement ne pas ajouter de nouveau type d'hôte et faire en sorte que 1 à 3 de nos types d'hôtes Windows existants disposent des outils MSVC en plus de Cygwin. Et ensuite, nous pouvons ajouter d'autres configurations de constructeur en plus de ces types d'hôtes modifiés.

Nous avons toujours eu le compilateur et l'éditeur de liens Mingw (gcc) C sur Windows. Nous n'avons jamais un ensemble différent d'outils de construction C. Une fois que nous aurons ajouté la prise en charge du compilateur Microsoft C, serait-il possible de tester les fonctions Mingw et Microsoft C avec une seule exécution de all.bat ? Ou est-ce que Mingw ou Microsoft C s'excluent ? Devrions-nous définir une variable d'environnement pour pointer vers Mingw ou vers Microsoft, mais jamais les deux ? Je suppose que j'essaie de comprendre comment le code doit être structuré et testé. Cela déterminera également le nombre de constructeurs différents dont nous avons besoin.

Alexis

Je vais chercher à faire cuire les binaires dans l'image

Le changement https://golang.org/cl/112036 mentionne ce problème : env/windows: add visual studio tools to image

@johnsonj @bradfitz : Merci d'avoir mis cela dans le constructeur.

@alexbrainman @bradfitz @ianlancetaylor : Donc, en ce qui concerne la stratégie de test pour cela, je ne sais pas exactement quoi faire. Nous pouvons prendre le chemin de l'exécution du test dist pour les deux chaînes d'outils sur la fenêtre et effectuer chaque test deux fois, ou devrions-nous uniquement tester les tests cgo deux fois (une fois pour gcc, une fois pour msvc) ?

Donc, en ce qui concerne la stratégie de test pour cela, je ne sais pas exactement quoi faire. Nous pouvons prendre le chemin de l'exécution du test dist pour les deux chaînes d'outils sur la fenêtre et effectuer chaque test deux fois, ou devrions-nous uniquement tester les tests cgo deux fois (une fois pour gcc, une fois pour msvc) ?

@cchamplin je n'ai pas de réponse à ta question. Je soupçonne Ian de connaître la réponse.

Alexis

Quel est le coût d'exécution de tous les tests deux fois au lieu de simplement cgo ?

@mxplusb , nous pouvons simplement exécuter une nouvelle configuration de construction pour Windows et elle s'exécutera en parallèle avec notre 3. Une nouvelle configuration de constructeur est très bien. Nous les ajoutons régulièrement.

Dites-moi simplement comment le rendre différent : définissez une variable d'environnement différente/nouvelle et ensuite quelque chose s'en ira, je suppose ?

Il faudra probablement plusieurs choses pour que cela fonctionne.

Soit nous devons exécuter à l'intérieur d'un shell/environnement où le go test exécuté par dist test sera exécuté à l'intérieur après que le vsvars.bat approprié a été exécuté/appelé

Ou nous pouvons demander à dist d'exécuter les vsvars appropriés et d'extraire les variables d'environnement dont il a besoin, puis de les définir/transmettre pour procéder au test.

Nous voudrons également probablement qu'une variable d'environnement indique à dist ou make.bat que nous voulons exécuter les tests avec -compiler msvc set.

Soit nous devons exécuter à l'intérieur d'un shell/environnement où le go test exécuté par dist test sera exécuté à l'intérieur après que le vsvars.bat approprié a été exécuté/appelé

Ou nous pouvons demander à dist d'exécuter les vsvars appropriés et d'extraire les variables d'environnement dont il a besoin, puis de les définir/transmettre pour procéder au test.

Je préférerais que nous n'exécutions pas de fichiers batch à partir de dist.exe ou de go.exe. Il est difficile de traiter les fichiers batch.

Nous voudrons également probablement qu'une variable d'environnement indique à dist ou make.bat que nous voulons exécuter les tests avec -compiler msvc set.

J'espérais qu'Ian saurait quelle est la meilleure approche ici. D'après ce que je sais, nous prenons également en charge différents compilateurs C sur Unix (gcc ou clang). Notre processus de construction nous permet certainement de tester différents compilateurs C.

Alexis

Je n'avais pas remarqué avant que vous prévoyiez d'utiliser go build -compiler msvc . Cela n'a pas de sens. L'option go build -compiler prend le nom d'un compilateur Go (actuellement soit gc soit gccgo). Il ne prend pas le nom d'un compilateur C. Le compilateur C est passé dans la variable d'environnement CC . Le compilateur C par défaut est défini en définissant la variable d'environnement CC_FOR_TARGET lors de l'exécution de make.bat, comme indiqué dans les commentaires de make.bat.

Je m'attendrais à ce que nous ayons un constructeur pour lequel nous nous arrangeons pour définir la variable d'environnement CC_FOR_TARGET sur msvc avant d'exécuter all.bat. Je ne vois pas pourquoi nous devrions faire autre chose.

Le compilateur C est passé dans la variable d'environnement CC. Le compilateur C par défaut est défini en définissant la variable d'environnement CC_FOR_TARGET lors de l'exécution de make.bat, comme indiqué dans les commentaires de make.bat.

Merci Ian pour l'explication.

@cchamplin J'espère que vous pourrez ajuster vos modifications pour s'adapter au modèle existant. Faites-nous savoir, si vous avez des problèmes. Merci.

Je m'attendrais à ce que nous ayons un générateur pour lequel nous nous arrangeons pour définir la variable d'environnement CC_FOR_TARGET sur msvc avant d'exécuter all.bat.

Nous avons 3 constructeurs de fenêtres amd64 sur https://build.golang.org. Devrions-nous en remplacer un par un MSVC ? Voulons-nous le constructeur 386 MSVC ?

Alexis

@ianlancetaylor @alexbrainman Compris à propos de l'indicateur -compiler. Je ne pense pas qu'il existe un moyen simple de faire fonctionner simplement le paramètre CC="msvc" (ou vraiment CC="cl.exe" ). CC doit toujours pointer vers un emplacement GCC pour que les builds MSVC fonctionnent. L'ensemble d'outils du compilateur msvc n'a pas les outils disponibles pour permettre à CGO d'effectuer l'introspection dont il a besoin (recherche de définition, résolution de type), donc GCC est toujours requis sur les versions MSVC, GCC n'est tout simplement pas utilisé dans la phase de compilation/liaison réelle.

Est-ce que l'ajout d'un nouveau drapeau pour aller construire et tout serait acceptable (chaîne d'outils ou quelque chose du genre) ? J'ai déjà dû ajouter un indicateur de chaîne d'outils à cgo, je crois.

De plus, définir CC_FOR_TARGET avant all.bat semble avoir des conséquences négatives car cela affecterait le compilateur utilisé dans l'amorçage. Je ne crois pas que MSVC puisse être utilisé pendant le processus d'amorçage (je ne suis pas à 100% là-dessus, je n'ai pas vraiment essayé mais je doute fortement que cela fonctionne)

Je vois, pour MSVC, nous devons avoir à la fois GCC et MSVC ? Où GCC est utilisé uniquement par l'outil cgo ? Cela semble quelque peu malheureux, car cela signifie que nous nous appuierons absolument sur GCC et MSVC implémentant exactement la même ABI, mais je suppose que c'est assez probable.

Je suppose que nous pourrions ajouter une autre variable d'environnement CC_FOR_CGO , qui pourrait être définie sur GCC.

Le CC_FOR_TARGET utilisé par make.bat sera utilisé pour construire runtime/cgo. Je ne vois pas du tout comment cgo pourrait fonctionner si runtime/cgo n'est pas construit par le compilateur C que vous utilisez.

Peut-être devrions-nous commencer par faire fonctionner les choses lorsque make.bat est invoqué en définissant CC_FOR_TARGET à cl et CGO_ENABLED à 0 .

Merci @ianlancetaylor :

Je vois, pour MSVC, nous devons avoir à la fois GCC et MSVC ? Où GCC est utilisé uniquement par l'outil cgo ? Cela semble quelque peu malheureux, car cela signifie que nous nous appuierons absolument sur GCC et MSVC implémentant exactement la même ABI, mais je suppose que c'est assez probable.

Je suis d'accord que c'est malheureux, et je serais heureux d'apprendre une alternative, je n'en ai pas encore trouvé. Il y a certainement un risque à construire de cette façon (par exemple, le code cgo en cours de construction a différentes définitions ou définitions de type en fonction du compilateur par lequel il pense être construit). Ainsi, les builds peuvent ne pas toujours réussir ou fonctionner correctement sans quelques ajustements (il existe un mécanisme pour gérer cela dans mon implémentation, mais c'est un peu un processus manuel). Malheureusement, je pense que c'est un risque que les gens devront prendre s'ils veulent utiliser la chaîne d'outils MSVC et tout ce que nous pouvons faire est de le documenter pour le moment.

Sur une note similaire, il n'y a toujours pas de véritable voie à suivre pour fournir la prise en charge de complex64 et complex128 dans les programmes cgo construits par MSVC simplement parce que le compilateur MSVC n'est pas conforme à c99.

Je suppose que nous pourrions ajouter une autre variable d'environnement CC_FOR_CGO , qui pourrait être définie sur GCC.

Donc, l'implémentation actuelle que j'ai est si go build est chargé de construire avec MSVC, il recherchera par défaut cl.exe sur le chemin, mais cela peut être remplacé par la variable d'environnement MSCC. CGO continuera à utiliser la variable d'environnement CC en revenant à gcc/tout ce qui se trouve dans le zdefaultcc.go généré

Le CC_FOR_TARGET utilisé par make.bat sera utilisé pour construire runtime/cgo. Je ne vois pas du tout comment cgo pourrait fonctionner si runtime/cgo n'est pas construit par le compilateur C que vous utilisez.

Dans l'implémentation actuelle, cgo fonctionnera avec plaisir pour les binaires msvc même si l'ensemble de la chaîne d'outils go a été construit par gcc. par exemple, le code MSVC est ajouté à go/src. all.bat est exécuté en construisant l'environnement go à l'aide de gcc. Après cela, go/bin/go.exe peut être utilisé pour créer avec la chaîne d'outils msvc (en supposant que des indicateurs soient fournis). Je comprends peut-être mal ce que vous dites ici.

La complexité autour de cela, car dire à go que nous voulons construire avec msvc est plus compliquée que de simplement basculer le compilateur sur cl. La chaîne d'outils MSVC est très différente de la chaîne d'outils gcc. Dans MSVC, un environnement doit être configuré en s'exécutant dans un vcvars.bat (ou en faisant ce que fait v8, par exemple, en exécutant vcvars.bat et en extrayant toutes les informations dont il a besoin des variables d'environnement qu'il configure, puis en les utilisant dans leur build traiter). Une fois que nous sommes dans un environnement MSVC, la principale différence devient les outils eux-mêmes. cl.exe est utilisé pour compiler des fichiers C et C++, ml.exe et ml64.exe sont utilisés pour assembler des fichiers, et enfin link.exe (ms) est utilisé pour lier tout ensemble. Il ne s'agit donc pas simplement de définir CC=cl.exe et de lui transmettre les bons indicateurs. Cela a-t-il du sens/aide-t-il à clarifier les choses ?

Pour clarifier davantage sur

Le CC_FOR_TARGET utilisé par make.bat sera utilisé pour construire runtime/cgo. Je ne vois pas du tout comment cgo pourrait fonctionner si runtime/cgo n'est pas construit par le compilateur C que vous utilisez.

go build sélectionne les fichiers appropriés à partir de runtime/cgo pendant le processus de construction (par exemple go build / go test / go run -- pas le processus de construction) lorsque le La chaîne d'outils msvc a été sélectionnée.

Je suis ouvert aux suggestions sur la façon dont cela devrait fonctionner, mais cela ne devrait pas nécessiter une nouvelle option de ligne de commande pour l'outil go. Pouvons-nous écrire un programme Go pur qui agit comme GCC en ce qui concerne l'outil go mais qui exécute réellement MSVC ?

Pouvons-nous écrire un programme Go pur qui agit comme GCC en ce qui concerne l'outil go mais qui exécute réellement MSVC ?

Je crois que cela pourrait être réalisable, laissez-moi voir si je peux faire avancer quelque chose sur cette voie.

De plus, je suppose que je dois préciser si l'ajout d'indicateurs de ligne de commande à d'autres outils sera également un problème. Pour le moment, le correctif complet pour cela crée plusieurs nouveaux indicateurs de ligne de commande dans divers outils

• cmd/cgo
  
  
  
  • -toolchain [gcc,msvc] (par défaut gcc) Chaîne d'outils à utiliser lors de la création de fichiers de sortie cgo
  
  
• cmd/lien
  
  
  
  • -rlocbss (la valeur par défaut est false) Déplacer .bss vers .data
  
  
  • -toolchain [gcc,msvc] (par défaut gcc) Chaîne d'outils à utiliser pour les liens externes
  
  

nous créons également les options de construction/variables d'environnement cgo suivantes :

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

Après quelques minutes de réflexion, il y a quelques obstacles qui pourraient être difficiles à surmonter si nous nous contentons de proxy les commandes du compilateur en pensant à un programme différent tous ensemble

1. go build besoin de savoir quelle est la chaîne d'outils externe pour déterminer quels fichiers runtime/cgo construire, sinon cela finirait par transmettre les versions incompatibles de gcc à notre commande proxy. Nous pourrions peut-être contourner cela à l'intérieur du proxy lui-même, mais il serait cassant et susceptible de casser si des fichiers supplémentaires étaient ajoutés à runtime/cgo.
2. cmd/cgo doit savoir quel type de chaîne d'outils externe est utilisé pour choisir la version du code C de sortie à utiliser
3. Le programme proxy aurait besoin d'un mécanisme pour savoir s'il doit ou non exécuter gcc (comme lorsqu'il est appelé par cmd/cgo) ou pour exécuter cl.exe qui pourrait être transmis, mais cela signifie que l'appelant devrait savoir ce que la chaîne d'outils is ou nous aurions cmd/cgo passant des drapeaux inexistants à gcc.
4. go build appelle cmd/link qui a également besoin de connaître la chaîne d'outils afin qu'il puisse effectuer la relocalisation .bss vers .data et afin qu'il puisse passer des drapeaux spécifiques à l'éditeur de liens (nous pourrions être en mesure de gérer ce dernier partie dans le proxy lui-même cependant)

Would spécifiant une variable d'environnement pour avoir go build utiliser pour déterminer msvc builds travail? Bien que je pense que cela place la barre plus haut pour quelqu'un qui veut juste construire un programme avec msvc, car ils doivent maintenant définir plusieurs variables d'environnement en plus de s'exécuter à l'intérieur de vsvars.bat (au minimum CC et UNDECIDED_TURN_ON_MSVC_BUILD_VAR )

Une autre alternative serait d'avoir go build exécuter une fausse commande noop sur le CC spécifié, puis d'analyser le logo/en-tête pour détecter s'il s'agit de msvc ou gcc et de procéder aux ajustements appropriés de la chaîne d'outils à ce stade ... je ne sais pas à quel point c'est fragile ou comment cela fonctionnerait avec des chaînes d'outils compatibles msvc comme clang.

J'ai découvert ce problème Github récemment, et ce travail est très excitant pour moi. J'espère que cela atterrira quelque part dans un avenir proche.

Mon intention est d'utiliser CGo sur Windows comme wrappers pour un code tiers qui a été construit à l'aide de MSVC, que je ne peux pas simplement reconstruire à partir de sources en utilisant mingw-w64 . J'ai des cas de test relativement sérieux à exécuter, donc je peux assez bien le valider.

Quoi qu'il en soit, merci à @cchamplin et à tous ceux qui y travaillent, et faites-moi savoir de toute façon que je peux vous aider.

@cchamplin J'en sais assez pour être dangereux à propos des chaînes d'outils du compilateur dans Windows et cgo que je pourrais peut-être aider. Pourriez-vous me rattraper sur une partie de ce sur quoi vous avez travaillé ? Je vais voir ce que je peux faire pour aider. Je sais que le @deadprogram de cas d'utilisation a donc j'ai un bon banc d'essai avancé quand nous sommes prêts à tester.

Hé @mxplusb , le patch est en fait plus ou moins prêt à être

Le changement https://golang.org/cl/133937 mentionne ce problème : cmd/link: Add flag rlocbss to relocate .bss data to .data

Le changement https://golang.org/cl/133938 mentionne ce problème : runtime/cgo: MSVC toolchain support in cgo native code

Le changement https://golang.org/cl/133939 mentionne ce problème : cmd/cgo: Add toolchain flag to cgo command for MSVC support

Le changement https://golang.org/cl/133946 mentionne ce problème : cmd/compile: Add support for MSVC toolchain to go build

Il semble que j'ai tapé le problème dans certains des commits. Je laisserai le processus d'examen démarrer et déterminerai la meilleure façon de réparer.

Le changement https://golang.org/cl/133943 mentionne ce problème : cmd/cgo: Add support for CC_FOR_CGO environment variable

Le changement https://golang.org/cl/133942 mentionne ce problème : tests: Update various tests to prepare for MSVC compiler toolchain

Le changement https://golang.org/cl/133940 mentionne ce problème : misc/cgo: Adjust tests to be compatible with MSVC toolchain support

Le changement https://golang.org/cl/133941 mentionne ce problème : runtime: Add runtime.CompilerType to denote between host compiler type

Le changement https://golang.org/cl/133945 mentionne ce problème : cmd/link: Add external toolchain support for MSVC

Le changement https://golang.org/cl/133944 mentionne ce problème : cmd/compile, cgo: Add support for MSVC flags

@cchamplin pouvez-vous décrire quelle a été la décision finale ? À quoi ressemble la prise en charge de MSVC ? Quels indicateurs de ligne de commande seront ajoutés ? Qu'est-ce qu'un utilisateur devra faire à son environnement en plus de télécharger MSVC ? Merci

Aussi, comment pouvons-nous essayer ce patch? Je n'ai pas trouvé vos commits sur le repo.

@rasky C'est encore un peu en mouvement alors que les changements passent en revue. Il n'y aura probablement pas d'indicateurs de ligne de commande spécifiques à définir, il suffit de créer des applications cgo où la variable d'environnement CC pointe vers MSVC ou aucun CC n'est défini, un cl.exe est sur le chemin mais pas gcc.

@blizzardplus Semblable à ce qui précède, les choses sont en pleine évolution en ce moment avec l'examen, il est donc peut-être un peu tôt pour commencer à l'essayer (à vous de décider). Tous les changements associés ont été publiés dans ce numéro par gopherbot, vous pouvez les trouver ici.

@cchamplin existe-t-il un support pour la compilation croisée en utilisant soit gcc ou clang ? Si oui, sont-ils testés ?

@cchamplin Je ne vois aucune activité sur les CL depuis le 11 septembre, y a-t-il des progrès à ce sujet ou a-t-il besoin de ressources supplémentaires ?

@cchamplin pour que cela fonctionne pour c-archive, la section ctors doit être remplacée par .CRT$XCU (https://msdn.microsoft.com/en-us/library/bb918180.aspx) - Si cela n'est pas fait, le Le runtime golang ne sera pas initialisé. En outre, il s'avère que si vous le définissez sur cela, cela fonctionne également bien pour gcc - gcc prend toujours ces fonctions, les déplace vers une section de texte et modifie main pour les appeler avant le vrai main. Visual Studio peut comprendre les fichiers d'archive .a et, comme l'interface des fichiers pré-compilés/assemblés est C, il ne devrait y avoir aucun problème à avoir cela dans l'archive. Il y a un avertissement concernant 2 sections .text mais les cas simples semblent fonctionner correctement (il faut plus de tests pour confirmer qu'il n'y a pas de problèmes).

De plus, pour que cela fonctionne pour c-shared, les fonctions à exporter doivent être décorées __declspec(dllexport), mais je n'arrive pas à trouver où cette expansion de //export se produit.

@blizzardplus Il existe un correctif de suivi pour prendre en charge clang-MSVC. Je ne sais pas ce que vous entendez par compilation croisée dans ce cas ? Vous ne pourrez pas utiliser la chaîne d'outils MSVC sur des systèmes autres que Windows. Les autres fonctionnalités de compilation croisée ne devraient pas changer.

@kshelton Malheureusement, c'est une période de l'année très chargée pour moi car j'ai d'autres projets en cours et des conférences

@kshelton Merci. Je n'ai pas revérifié le correctif, je suppose que je l'ai développé en supposant que c-archive ne fonctionnerait pas sur MSVC, ou l'a spécifiquement désactivé? J'ai essayé de décorer correctement les exportations lorsque j'essayais de faire fonctionner le plug-in/partagé sur Windows. Il y a d'autres problèmes, je crois, mais je pourrais confondre deux problèmes. Il y a de vrais problèmes avec la façon dont le code est partagé dans le PLT/GOT pour ELF vs Windows .edata, idata et EAT. Je crois que la plupart des problèmes auxquels j'ai été confronté concernaient les délocalisations et l'impossibilité de les faire travailler. Si quelqu'un a une idée à ce sujet, ce serait formidable. Voir #19282

@cchamplin j'ai essayé de voir, si je peux construire Go sur votre CL

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

J'ai utilisé ce fichier batch pour définir mon environnement

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

et j'obtiens cette erreur lorsque je lance 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>

Qu'est-ce que j'oublie ici?

Merci.

Alexis

@alexbrainman

Qu'est-ce que j'oublie ici?

Vous devez probablement au minimum définir CC_FOR_CGO=gcc. De plus, je n'ai jamais personnellement essayé de créer Go avec MSVC. Je ne sais pas si cela fonctionnerait/devrait être pris en charge.

-C

Vous devez probablement au minimum définir CC_FOR_CGO=gcc.

Votre https://go-review.googlesource.com/c/go/+/133940 contient quelques tests. Comment puis-je vérifier la réussite des tests ? Quelles sont les étapes exactes ?

Les constructeurs Go https://build.golang.org exécutent également %GOROOT%\src\all.bat pour vérifier tous les tests (y compris ceux répertoriés dans https://go-review.googlesource.com/c/go/+/ 133940) passer. Comment proposez-vous de modifier le code Go pour que %GOROOT%\src\all.bat exécute vos tests ajustés à partir de https://go-review.googlesource.com/c/go/+/133940. All.bat peut peut-être tester les versions gcc et msvc des tests. Peut-être pouvons-nous utiliser une variable d'environnement qui indique à all.bat quelle version des tests exécuter - et nous pourrions alors avoir deux constructeurs différents pour exécuter des versions différentes des tests. As-tu pensé à tout ça ?

De plus, je n'ai jamais personnellement essayé de créer Go avec MSVC. Je ne sais pas si cela fonctionnerait/devrait être pris en charge.

Vous pouvez exécuter all.bat avec succès sans que gcc soit installé. La version actuelle de Go n'a besoin que d'une autre version de Go (au moins go1.4) pour être construite. Seul Cgo a besoin d'un compilateur C, j'avais l'impression que vos modifications implémentent la version Cgo construite par MSVC. Mais, peut-être, je me trompe. S'il vous plait corrigez moi si je me trompe.

Merci.

Alexis

@alexbrainman

Votre https://go-review.googlesource.com/c/go/+/133940 contient quelques tests. Comment puis-je vérifier la réussite des tests ? Quelles sont les étapes exactes ?

All.bat peut peut-être tester les versions gcc et msvc des tests. Peut-être pouvons-nous utiliser une variable d'environnement qui indique à all.bat quelle version des tests exécuter - et nous pourrions alors avoir deux constructeurs différents pour exécuter des versions différentes des tests. As-tu pensé à tout ça ?

Oui, ce mécanisme exact est utilisé dans https://go-review.googlesource.com/c/go/+/133946/. Comme tous les appels à run.bat sous Windows, le mécanisme d'appel des tests cgo a été placé là. Ainsi, vous ou le constructeur commenceriez avec une configuration normale CC=gcc. Ensuite, vous définiriez GOTESTMSVC=1 et GOVSVARSPATH=certain chemin vsvars.bat. Après cette construction avec all.bat, les tests gcc et msvc cgo devraient être exécutés.

Vous pouvez exécuter all.bat avec succès sans que gcc soit installé. La version actuelle de Go n'a besoin que d'une autre version de Go (au moins go1.4) pour être construite. Seul Cgo a besoin d'un compilateur C, j'avais l'impression que vos modifications implémentent la version Cgo construite par MSVC. Mais, peut-être, je me trompe. S'il vous plait corrigez moi si je me trompe.

Vous avez raison. Go lui-même devrait bien se construire. Il peut y avoir des problèmes lors du test, car run.bat a été modifié pour définir certaines variables d'environnement lorsque GOTESTMSVC=1. Nous pourrions probablement essayer de détecter si go est juste en train d'être construit avec msvc, puis définir les variables d'environnement dist appropriées afin que les tests n'échouent pas.

Ensuite, vous définiriez GOTESTMSVC=1 et GOVSVARSPATH=certain chemin vsvars.bat. Après cette construction avec all.bat, les tests gcc et msvc cgo devraient être exécutés.

J'ai essayé ça.

j'ai utilisé

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

J'exécute d'abord ce fichier batch :

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

puis exécutez all.bat . all.bat échoue avec

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

La définition de GOTESTMSVC et GOVSVARSPATH peut également fonctionner pour les personnes exécutant all.bat. Mais que feront les autres utilisateurs de votre modification lorsqu'ils auront besoin d'utiliser MSVC pour Cgo ? Quel est ton plan pour ça ?

Alexis

@alexbrainman
Je ne sais pas ce qui se passe. Ce test échoue pour moi sur le maître

> 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

Dans help.go https://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/internal/help/help.go#L37
il itère à travers base.Go.Commands. Qui est initialisé dans main.go https://github.com/golang/go/blob/c040786f37246f40ae29402fbdb6e97031a21713/src/cmd/go/main.go#L43
mais je ne sais pas comment cette fonction d'initialisation serait appelée dans un exécutable de test, donc je n'ai aucune idée de la façon dont master passe les tests en ce moment, car je pense que cela devrait échouer dans tous les domaines.

La définition de GOTESTMSVC et GOVSVARSPATH peut également fonctionner pour les personnes exécutant all.bat. Mais que feront les autres utilisateurs de votre modification lorsqu'ils auront besoin d'utiliser MSVC pour Cgo ? Quel est ton plan pour ça ?

Donc, dans une situation où vous voulez juste créer du code Cgo avec MSVC

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

devrait être tout ce dont tu as besoin je pense

Je ne sais pas comment cette fonction d'initialisation serait appelée dans un exécutable de test, donc je n'ai aucune idée de la façon dont master passe les tests en ce moment, car je pense que cela devrait échouer dans tous les domaines.

Lorsque vous utilisez go test avec un fichier dans cmd/go, l'outil go construira le package cmd/go, puis construira les tests, générera le pilote de test, le construira et liera le tout dans un nouveau package principal. Cela se produit même si cmd/go est lui-même un package principal. C'est-à-dire que le package principal dans cmd/go/*.go sera traité comme un package non principal à des fins de test. Cela permet aux tests d'appeler les fonctions définies dans le package principal, le cas échéant.

Désolé, je suis lent à répondre. Mais je n'avais pas de temps libre pour me pencher à nouveau sur la question.

Je ne sais pas ce qui se passe. Ce test échoue pour moi sur le maître

Je n'ai pas utilisé le maître. J'ai utilisé votre commit e56d52f66b95b87001867a2487a11bd961f40d4d. N'avez-vous pas exécuté all.bat sur ce commit avant de l'envoyer pour examen ? All.bat a-t-il réussi ? Pouvez-vous essayer d'exécuter à nouveau all.bat sur ce commit pour voir si cela a quelque chose à voir avec la configuration de mon système. Merci.

Donc, dans une situation où vous voulez juste créer du code Cgo avec MSVC

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

devrait être tout ce dont tu as besoin je pense

2 variables d'environnement est, probablement, trop compliqué pour l'utilisateur moyen. Et CC_FOR_CGO=gcc me semble étrange - pourquoi utilisons-nous gcc pour créer du code avec MSVC ?

Alexis

@alexbrainman

Je n'ai pas utilisé le maître. J'ai utilisé votre commit e56d52f66b95b87001867a2487a11bd961f40d4d. N'avez-vous pas exécuté all.bat sur ce commit avant de l'envoyer pour examen ? All.bat a-t-il réussi ? Pouvez-vous essayer d'exécuter à nouveau all.bat sur ce commit pour voir si cela a quelque chose à voir avec la configuration de mon système. Merci.

Je pense que c'était quelque chose à voir avec la configuration de mon système qui me donnait des résultats étranges lors de l'exécution des tests. Je pense avoir résolu le problème et poussé quelques mises à jour de l'ensemble de modifications.

2 variables d'environnement est, probablement, trop compliqué pour l'utilisateur moyen. Et CC_FOR_CGO=gcc me semble étrange - pourquoi utilisons-nous gcc pour créer du code avec MSVC ?

Il devrait en fait probablement être CC_FOR_CGO=gcc.exe, mon erreur. Mais pour répondre à votre question ; de gerrit :

PS1, ligne 1324 :
cgo a toujours besoin de gcc pour l'analyse de type. Si CC est défini sur un compilateur MSVC, cgo a besoin d'un moyen d'appeler GCC qui est fourni par CC_FOR_CGO. Malheureusement, la chaîne d'outils MSVC n'a pas de mécanisme pour fournir le même type d'informations que celles recueillies à partir de gcc. Théoriquement, un outil spécifique à go pourrait être créé pour collecter les informations de type utilisées par cgo, mais cela pourrait être hors de portée et peut-être un effort considérable (je n'ai personnellement jamais rien écrit pour effectuer une analyse de type statique du code C/C++).

Je semble également avoir cassé quelque chose avec le cache vide entre les exécutions pour GCC vs MSVC, je ne sais pas pourquoi certains tests agissent toujours comme s'ils étaient mis en cache.

Je pense avoir résolu le problème et poussé quelques mises à jour de l'ensemble de modifications.

Cette configuration https://github.com/golang/go/issues/20982#issuecomment -447618566 sur

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

m'emmène plus loin, mais échoue toujours avec

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

Il devrait en fait probablement être CC_FOR_CGO=gcc.exe, mon erreur.

Je ne suis pas préoccupé par .exe dans gcc.exe. Mes problèmes sont

• vous avez besoin des outils gcc et MSVC pour utiliser MSVC (il serait difficile de l'expliquer à nos utilisateurs), mais je comprends que rien ne peut être fait à ce sujet ;

• J'avais besoin des deux variables d'environnement CC_FOR_CGO=gcc et CC=cl.exe - peut-être pouvons-nous simplement supposer que CC_FOR_CGO est toujours défini sur gcc ?

Mais pour répondre à votre question ; de gerrit :

Merci d'avoir expliqué.

Alexis

@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

Je ne sais pas comment cet avertissement se produirait à moins que vous n'ayez une copie différente/ancienne de msvc_libinit_windows.c. Pouvez-vous confirmer qu'il contient cette ligne :

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

C4710 doit être supprimé pour l'inclusion stdio. Je vois que votre version de MSVC est légèrement différente de la mienne, ce qui pourrait également être un coupable. Je ne sais pas pourquoi ils ignoreraient activement cette suppression dans une version différente.

Vous pouvez également essayer d'apporter une modification pour inclure la suppression globalement, quoi qu'il arrive

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

J'avais besoin des deux variables d'environnement CC_FOR_CGO=gcc et CC=cl.exe - peut-être pouvons-nous simplement supposer que CC_FOR_CGO est toujours défini sur gcc ?

Je pense que gco vérifier si gcc existe si CC_FOR_CGO n'est pas défini serait bien. CC_FOR_CGO est plus pour les gens comme moi qui n'ont pas gcc sur leur chemin. Mon CC_FOR_CGO ressemble à ceci CC_FOR_CGO=I:\Development\tmd-gcc\bingcc.exe. Si nous ne voulons pas prendre en charge le cas d'utilisation de GCC qui n'est pas sur le chemin des versions MSVC, faites-le moi savoir et je peux me débarrasser de la variable d'environnement ensemble.

j'ai réessayé cette version

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

et j'obtiens la même erreur

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

Pouvez-vous confirmer qu'il contient cette ligne :

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

Ceci est le début de mon fichier 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>
...

Vous pouvez également essayer d'apporter une modification pour inclure la suppression globalement, quoi qu'il arrive

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

J'ai fait ce changement :

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>

mais je vois la même erreur

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

Alexis

J'essayais de reproduire cela hier soir et j'ai été incapable de le faire. Je me demande si vous rencontrez ceci : https://developercommunity.visualstudio.com/content/problem/35734/c-cannot-disable-specific-warnings-with-pragmas-wh.html

Est-il possible pour vous de mettre à jour vers le dernier SDK et Build Tools ? Je suis sur SDK 10.0.17763.0. et la version 15.9.28307.222 du build tools/devenv

J'essaie de créer une DLL Windows avec MSVC, mais il semble que Go tente de désactiver un avertissement avec un numéro supérieur à 65535 (ou pas un numéro), ce qui provoque l'arrêt de MSVC.

Non. Werror est une option GCC, pour traiter chaque avertissement comme une erreur.

Pour MSVC, vous devez utiliser WX .

@pravic bon point, comment ferais-je ? Je ne le configure pas, tout ce que je fais c'est :

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

@galich Malheureusement, je ne peux pas aider car je ne suis pas l'intégration MSVC.

Par exemple, où sont les correctifs liés à ce fil ? En master ou ailleurs ?

@pravic vous pouvez trouver les changements ici : https://go-review.googlesource.com/c/go/+/133946/5

@mxplusb merci pour le lien, il semble que mon problème particulier avec /Werror y soit résolu.
Savez-vous quand cela arrivera en version bêta/nuit/stable ?

Est-il possible pour vous de mettre à jour vers le dernier SDK et Build Tools ? Je suis sur SDK 10.0.17763.0. et la version 15.9.28307.222 du build tools/devenv

@cchamplin enfin j'ai réussi à mettre à jour mon MSVC. J'ai maintenant

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>

j'ai réessayé cette version

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

et all.bat se termine avec succès. Mais je reçois ces avertissements.

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

Et j'ai aussi remarqué que vous exécutez tous les tests deux fois.

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

Pourquoi?

Alexis

@alexbrainman Les avertissements peuvent probablement être supprimés pour ces tests, en particulier dans ce cas les avertissements de spectre.

Pour les tests exécutés deux fois, je pense que cela a été fait de cette façon pour le constructeur, exécutez les tests une fois avec la compilation gcc, puis exécutez-les à nouveau avec MSVC (lorsqu'il est activé) pour garantir que la compilation avec les deux chaînes d'outils fonctionne. Je ne suis pas sûr de ce qui est souhaité ici, donc je peux le changer de sorte que lorsque all.bat est appelé avec MSVC activé, nous n'exécutions les tests qu'avec MSVC, faites-le moi savoir. Dans ce cas, je suppose que des constructeurs supplémentaires devraient être ajoutés pour MSVC uniquement, par opposition à certains constructeurs qui construisent également avec MSVC ?

Il est convenu que sous Windows, il sera nécessaire d'exécuter un générateur à l'aide de la chaîne d'outils MinGW-W64 et un autre avec la chaîne d'outils MSVC afin de tester les deux scénarios.

Je pense que cela a été fait de cette façon pour le constructeur, exécutez les tests une fois avec la compilation gcc, puis exécutez-les à nouveau avec MSVC (lorsqu'il est activé) pour garantir que la compilation avec les deux chaînes d'outils fonctionne.

Je suis d'accord que cela devrait être le comportement préféré, donc il y a une garantie qu'il ne casse pas les charges de travail existantes si les deux chaînes d'outils sont présentes.

Les avertissements peuvent probablement être supprimés pour ces tests, en particulier dans ce cas les avertissements de spectre.

La commande Go n'affiche pas les avertissements, les avertissements ne doivent donc pas être affichés.

J'ai également remarqué que la commande go env n'affiche pas la variable CC_FOR_CGO. Si CC_FOR_CGO affecte le fonctionnement de go build, alors CC_FOR_CGO doit être affiché avec les autres. Avons-nous vraiment besoin de la variable CC_FOR_CGO ? Quoi d'autre, mais CC_FOR_CGO=gcc cela peut-il être ?

Pour les tests exécutés deux fois, je pense que cela a été fait de cette façon pour le constructeur, exécutez les tests une fois avec la compilation gcc, puis exécutez-les à nouveau avec MSVC (lorsqu'il est activé) pour garantir que la compilation avec les deux chaînes d'outils fonctionne.

De nombreux tests n'utilisent pas gcc. C'est une perte de temps pour les gens / l'ordinateur lorsque les tests de packages s'exécutent deux fois sans raison. Comme vous pouvez le voir sur https://github.com/golang/go/issues/20982#issuecomment -480569880 archive/zip les tests de package ont été exécutés deux fois - je ne vois pas la nécessité d'une deuxième exécution.

Je ne sais pas comment organiser cela, mais vous devriez peut-être remplacer votre appel de go tool dist test dans run.bat pour faire juste une sélection de tests qui sont nécessaires pour tester la construction MSVC. Voir, par exemple, go tool dist test -h sur la façon dont vous pouvez sélectionner quelques tests spécifiques. @bradfitz nous pourrions peut-être créer un indicateur ou une variable d'environnement qui indiquera à la commande dist d'exécuter des tests spécifiques à MSVC.

Mais en général, votre https://go-review.googlesource.com/c/go/+/133946/5 crée un exécutable pour moi. Par exemple, je peux construire un exécutable avec 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>

et ensuite je peux construire l'exécutable avec 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>

Ainsi, la construction avec MSVC nécessitera que les utilisateurs exécutent le fichier de commandes MS pour définir toutes les variables d'environnement (voir GOVSVARSPATH dans ma sortie) - et cela, je suppose, est standard et n'a rien à voir avec Go. Et set CC=cl . Assez simple.

Le seul problème que je vois avec cette approche est que les utilisateurs de MSVC auront toujours besoin d'installer gcc. gcc est utilisé par cmd/cgo pour découvrir toutes les interfaces C - cette partie n'est pas implémentée à l'aide de MSVC. Cela semble inhabituel pour les personnes qui ne savent pas comment fonctionne cmd/cgo, mais c'est ce que c'est.

@ianlancetaylor et @bradfitz est-ce que tout cela semble raisonnable pour faire avancer les

Les constructeurs sur lesquels MSVC est déjà installé peuvent tester tout nouveau code. D'autres constructeurs sauteront simplement les tests.

Alexis

gcc est utilisé par cmd/cgo pour découvrir toutes les interfaces C - cette partie n'est pas implémentée à l'aide de MSVC.

Comment cela peut-il être surmonté? Idéalement, ce serait génial s'il n'y avait pas d'exigence pour gcc, juste MSVC.

Comment cela peut-il être surmonté?

Les parties de cmd/cgo qui utilisent gcc doivent être réécrites pour utiliser MSVC. Si c'est possible.

Alexis

Je me demandais si cette fonctionnalité était plus proche d'être mise en production ? Je vois qu'il a été étiqueté pour 1.13, et cela vient de sortir. J'essaie de créer des extensions Python à l'aide d'une version Go c-archive liée au code d'extension, mais Python nécessite MSVC.

Je ne sais pas où en est ce problème. Il a été avancé d'une version à l'autre, je vais donc le déplacer vers imprévu. S'il entre en 1.14, tant mieux.

Même avec l'exigence de double compilateur, j'aimerais voir l'implémentation actuelle faire partie de la prochaine version. Il permet au moins de compiler des exécutables/bibliothèques en utilisant MSVC, ce qui est mieux que rien.

Même avec l'exigence de double compilateur, j'aimerais voir l'implémentation actuelle faire partie de la prochaine version.

Je pense que ce serait une bonne implémentation "bêta". Cela permettrait d'éliminer les bogues et de commencer à mûrir l'implémentation. Que reste-t-il à faire avant qu'il ne fasse l'objet d'un examen sérieux ?

Donc, de mon point de vue et de ce dont je me souviens de la dernière fois que j'ai examiné cela (il y a environ 6 mois), il y avait une douzaine d'éléments de nettoyage qui devaient être terminés pour le processus de révision du code. Un travail supplémentaire peut également être nécessaire pour dédupliquer certains tests qui ont été essentiellement copiés avec des modifications très mineures pour fonctionner avec une chaîne d'outils différente. Il est également nécessaire de revoir et de désactiver certains avertissements msvc.

Les principaux problèmes en suspens comprennent :

Nous ne pouvons pas faire d'analyse de type sans gcc, il n'y a pas de solution simple ou immédiate à cela.

Finaliser la configuration et comment tout va fonctionner pour les constructeurs.

Je crois qu'il y a eu des changements assez importants au compilateur et à l'éditeur de liens au cours des 6 derniers mois qui peuvent avoir un impact sévère sur le travail actuel effectué pour cela, mais je n'ai pas été en mesure de le confirmer. En raison de la complexité et de la courbe d'apprentissage élevée de la navigation dans le compilateur / l'éditeur de liens / la chaîne d'outils de Go, il me faudra peut-être un temps considérable pour me mettre à niveau suffisamment pour comprendre l'impact éventuel des changements sur ce corpus de travail.

Les types numériques complexes ne sont pas pris en charge. MSCVs C lib est tout simplement incompatible. Je pense qu'il existe probablement un moyen de le caler avec C++, mais je ne suis pas sûr, peut-être que quelqu'un de MS familier avec les chaînes d'outils MSVC peut intervenir.

Malheureusement, la vie et d'autres projets m'empêchent de consacrer plus de temps à cela, mais je vais essayer d'y consacrer du temps dans les semaines à venir.

@manbearian ce problème concerne l'ajout du support MSVC à golang. Qui dans l'équipe MSVC serait bon à consulter pour les questions MSVC ?

@kesmit13 et @mxplusb

Cette

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

est le dernier code de @cchamplin qui fonctionne.

Ma préoccupation actuelle avec le code, c'est qu'il n'est pas clair comment l'utiliser. Quelle commande exécutez-vous ? Comment mon environnement doit-il être configuré ?

Je pense que la prochaine étape consiste pour quelqu'un à essayer d'utiliser ce code et à voir s'il peut réellement l'utiliser. Si cela fonctionne, les étapes doivent être documentées afin que d'autres puissent également utiliser le code. C'est peut-être trop compliqué ou ça ne marche pas. Ensuite, nous devons ajuster le code en conséquence.

Une fois que nous sommes satisfaits de l'état actuel du code, nous devons le rebaser sur master. Il a modifié trop de fichiers différents, il ne sera donc pas facile de rebaser. Peut-être que nous pourrions ajuster le changement pour faire moins de changements, il est donc plus facile de rebaser.

Alexis

@mxplusb @kesmit13 L'implémentation actuelle a été rebasée par rapport au maître et peut être trouvée ici : https://go-review.googlesource.com/c/go/+/133946/6

@alexbrainman

Ma préoccupation actuelle avec le code, c'est qu'il n'est pas clair comment l'utiliser. Quelle commande exécutez-vous ? Comment mon environnement doit-il être configuré ?

Je suis d'accord que la documentation doit être ajoutée sur la façon d'utiliser cela. Je ne sais pas trop où le mettre, faites-moi savoir si vous avez des idées. Idk s'il doit passer sous la documentation cmd/go pour la construction/l'exécution via MSVC, ou s'il doit vivre sous la documentation CGO, ou peut-être ailleurs ?

De nombreux tests n'utilisent pas gcc. C'est une perte de temps pour les gens / l'ordinateur lorsque les tests de packages s'exécutent deux fois sans raison. Comme vous pouvez le voir à partir de # 20982 (commentaire), les tests de package archive/zip ont été exécutés deux fois - je ne vois pas la nécessité d'une deuxième exécution.

Je ne sais pas comment organiser cela, mais vous devriez peut-être remplacer votre appel de test de dist d'outil go dans run.bat pour faire juste une sélection de tests qui sont nécessaires pour tester la construction MSVC. Voir, par exemple, go tool dist test -h pour savoir comment sélectionner quelques tests spécifiques. @bradfitz nous pourrions peut-être créer un indicateur ou une variable d'environnement qui indiquera à la commande dist d'exécuter des tests spécifiques à MSVC.

Le changement inclut déjà une variable d'environnement ajoutée à dist pour lui faire savoir que nous faisons des choses MSVC "GO_TEST_TESTINGMSVC" je crois. Ce dont je ne suis pas sûr, c'est de savoir comment nous allons filtrer les tests à exécuter sur des éléments que seul MSVC pourrait avoir un impact si nous n'exécutons pas tous les tests deux fois. Potentiellement limité aux tests liés aux CGO, mais je pense qu'il existe des tests CGO partout et je ne sais pas si dist dispose d'un mécanisme pour les filtrer?

Je ne sais pas trop où le mettre, faites-moi savoir si vous avez des idées.

Je pense qu'avant de mettre à jour toute documentation, vous devriez simplement décrire ici comment créer du code Cgo avec MSVC. Pour @mxplusb et @kesmit13 afin qu'ils puissent essayer vos modifications.

Par exemple, pour utiliser gcc pour créer du code Cgo, je

1. ajuster mon %PATH% pour inclure gcc.exe
2. build Allez d'abord en exécutant make.bat à partir du répertoire %GOROOT%\src
3. utiliser les commandes standard go build et go install

Comment faire de même avec MSVC ?

Ce dont je ne suis pas sûr, c'est de savoir comment nous allons filtrer les tests à exécuter sur des éléments que seul MSVC pourrait avoir un impact si nous n'exécutons pas tous les tests deux fois. Potentiellement limité aux tests liés aux CGO, mais je pense qu'il existe des tests CGO partout et je ne sais pas si dist dispose d'un mécanisme pour les filtrer?

Je commencerais par le répertoire %GOROOT%\misc\cgo. Quelle que soit la source que vous pouvez y construire, vous devriez la construire. Tout ce qui précède dépend de vous.

Alexis

@cchamplin désolé pour les retards à ce sujet, je ferai de mon mieux pour le tester cette semaine et je vous dirai comment ça se passe.

Salut, désolé d'être en retard à la fête... je peux essayer de répondre aux questions sur les fonctionnalités de MSVC ou vous diriger vers des personnes qui le peuvent. J'ai lu la conversation, mais malheureusement, je ne suis pas assez familiarisé avec go pour comprendre la fonctionnalité GCC requise qui peut ou non être absente de MSVC.

Salut les gens,
Cette fonctionnalité est-elle sortie dans Go 1.14 ?
S'il est publié, veuillez partager tous les documents disponibles pour en faire usage.
S'il n'est pas encore sorti, y a-t-il une idée de quand il sortira ?
J'attends avec impatience le support MSVC.
Merci d'avance :)

Salut, personne n'a jamais répondu à ma demande d'informations, donc je ne sais pas ce qu'il faut. Quelqu'un peut-il me renseigner s'il vous plait ?

Malheureusement, je ne sais pas si quelqu'un travaille activement sur cette question.

Bonjour, personne n'a jamais répondu à ma demande d'informations, ...

Bonjour @manbearian

De quelle requête s'agit-il ? De quelle information as-tu besoin?

Alexis

J'ai été tagué plus tôt dans ce fil pour plus d'informations, mais je ne sais pas ce que les gens recherchent et je n'ai pas pu aider. Si aucune aide n'est nécessaire, c'est parfait. S'il vous plaît laissez-moi savoir.

S'il vous plaît laissez-moi savoir.

@manbearian

Merci pour votre offre. Je ne sais pas qui t'a tagué. S'ils ont encore besoin d'aide, ils vous tagueront à nouveau.

Alexis

S'il n'est pas encore sorti, y a-t-il une idée de quand il sortira ?
J'attends avec impatience le support MSVC.

@dhinesherode91

Le code est là et complet ; Je pense que la seule chose qui freine vraiment cela, ce sont les gens qui testent les changements et fournissent des commentaires afin qu'ils puissent ensuite être correctement examinés et approuvés. J'hésite cependant à rebaser les modifications sur le maître actuel. Je l'ai fait 5 à 6 fois et cela prend énormément de temps, puis je ne reçois aucun test/rétroaction. À moins que d'autres parties ne soient disposées à participer aux tests, le problème pourrait être mort dans l'eau.

À moins que d'autres parties ne soient disposées à participer aux tests, le problème pourrait être mort dans l'eau.

@cchamplin compte sur moi pour tester/déboguer vos modifications. Je n'ai pas d'expérience avec la chaîne d'outils to go mais j'ai examiné vos commits et ils semblent être assez bien structurés et documentés.

@cchamplin Super d'apprendre que la partie implémentation est terminée.
Je suis intéressé à participer à la partie test, mais je suis un débutant en GoLang et aussi un bon apprenant en Windows apis (commencé quelques semaines auparavant). J'avais l'intention de travailler avec Windows API dans MS C++ car il semble que de nombreuses ressources officielles soient disponibles pour cela. Mais ensuite, j'ai commencé à chercher un langage (pour ma programmation système) où je pourrais l'utiliser pour ma programmation système multiplateforme et je suis impressionné par GoLang. Toujours prêt pour la contribution de ma part et a grandement besoin de conseils.

@cchamplin si vous rebase, j'essaierai de construire dessus. J'aimerais supprimer l'exigence mingw64 de certains de mes projets au travail. Mes outils de construction sont tous configurés pour MSVC, je n'aurais donc rien d'autre à faire que d'utiliser votre correctif.

@cchamplin aussi, j'ai parcouru vos CL et je n'en ai pas vu pour l'outil cgo, alors j'ai commencé sur mon propre patch. Y a-t-il des travaux antérieurs ?

@ericlagergren

@cchamplin aussi, j'ai parcouru vos CL et je n'en ai pas vu pour l'outil cgo, alors j'ai commencé sur mon propre patch. Y a-t-il des travaux antérieurs ?

Je ne sais pas si je comprends bien, sur https://go-review.googlesource.com/c/go/+/133946/6, de nombreux commits associés touchent directement la partie cgo de Go dans une certaine mesure.

@ccahoon d' accord, j'ai dû les manquer. Si l'outil cgo n'avait pas été mis à jour, j'allais proposer de le faire.

@ericlagergren

J'aimerais supprimer l'exigence mingw64 de certains de mes projets au travail

Juste FYI. Les

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

le changement a encore besoin de Mingw pour fonctionner. Vous aurez besoin des outils Mingw et MSVC installés pour utiliser le changement @cchamplin .

Alexis

@cchamplin , pourquoi Mingw est-il encore nécessaire ? Que faudrait-il pour supprimer cette dépendance ?

@alexbrainman Je ce serait fantastique. Mais aussi comme l' a dit

@ericlagergren @cglong CGO doit rassembler et disposer d'informations de type sur le code C avec lequel il est compilé. GCC a un indicateur qui produira des données de type dans un format facilement analysable. Pour autant que je sache, MSVC n'a pas la fonctionnalité pour fournir les mêmes informations. Construire l'outillage dans go nécessiterait non seulement du code pour analyser/analyser le code C et C++, mais aussi pour comprendre et évaluer les directives du préprocesseur. Ce serait une entreprise assez importante de construire une telle chose à Go. Peut-être existe-t-il déjà une bibliothèque quelque part que nous pourrions adopter ?

@cchamplin gotcha, c'est ce que je pensais. Je connais des bibliothèques tierces comme libclang et cznic/cc. Mais malheureusement, libclang est gigantesque et cznic/cc n'a pas été testé sur Windows ou macOS. L'APB ne fournit-elle pas suffisamment d'informations ?

CGO doit rassembler et disposer d'informations de type sur le code C avec lequel il est compilé. GCC a un indicateur qui produira des données de type dans un format facilement analysable. Pour autant que je sache, MSVC n'a pas la fonctionnalité pour fournir les mêmes informations.

Peut-être que @manbearian pourra-

Je ne dirais pas que GCC émet des données de type de sortie dans un format spécial. Il émet des données de débogage DWARF destinées aux débogueurs, et cgo lit ces données à l'aide du package debug/dwarf. MSVC a vraisemblablement également un format de débogage. Si ce format est documenté n'importe où, nous pourrions le lire en utilisant cgo tout comme nous le faisons avec les données DWARF.

@ianlancetaylor MSVC peut émettre des fichiers PDB. Voir https://github.com/Microsoft/microsoft-pdb

FWIW, la lecture de la sortie de débogage de MSVC est ce dont je parlais lorsque j'ai mentionné l'outil cgo dans https://github.com/golang/go/issues/20982#issuecomment -648462003

Je ne dirais pas que GCC émet des données de type de sortie dans un format spécial. Il émet des données de débogage DWARF destinées aux débogueurs, et cgo lit ces données à l'aide du package debug/dwarf. MSVC a vraisemblablement également un format de débogage. Si ce format est documenté n'importe où, nous pourrions le lire en utilisant cgo tout comme nous le faisons avec les données DWARF.

@ericlagergren @ianlancetaylor
Nous avons donc besoin des données DWARF, qui en constituent une grande partie. Cependant, nous pourrions théoriquement obtenir les mêmes informations à partir des données PDB.

Ce à quoi je faisais spécifiquement référence, cependant, n'était pas seulement les données DWARF que GCC produit, mais la sortie de gcc -E -dM qui génère tous les #define après le prétraitement. Il est possible que PDB à lui seul puisse fournir les mêmes informations... ce dont je suis sceptique, c'est si nous serions en mesure de contraindre MSVC à vider les informations de débogage/les informations de type à quelque titre que ce soit sans qu'il ait besoin de compiler réellement le code. À l'heure actuelle, CGO fait exactement cela avec GCC.

De mémoire, /EP /d1PP devrait émettre quelque chose de similaire à -E -dM.

De mémoire, /EP /d1PP devrait émettre quelque chose de similaire à -E -dM.

Si c'est le cas, ce serait excellent, je suppose que /d1PP est un indicateur non documenté ? Je ne l'ai jamais vu auparavant. Cela laisserait simplement obtenir des informations de type équivalentes à l'avance.

@cchamplin ouais, c'est sans papiers. Beaucoup d'indicateurs /dXXX le sont, apparemment. L'utilisation d'indicateurs non documentés est regrettable, mais (IMO) cela ne semble pas être un si grave péché sous Windows, au moins. J'ai vu des développeurs MSVC STL en parler sur un fil de discussion reddit, mais c'est aussi partout sur Internet.

Quelqu'un peut-il me donner un bref résumé de l'état actuel du support MSVC ? Je ne comprends pas grand-chose à tous ces trucs de compilateur de bas niveau. C'est juste que j'ai une bibliothèque go que je veux utiliser à partir de C#/UWP - et qui fonctionne déjà avec go build et le buildmode c-shared. MAIS : cette application ne sera jamais acceptée par le Windows Store car la DLL générée à partir de go manque des indicateurs de compilation/linker qui (je suppose) ne peuvent être définis que par la chaîne d'outils MSVC.

Alors : comment pourrais-je tester cela ici ? Tout conseil est apprécié ! Merci!

cette application ne sera jamais acceptée par le Windows Store car la DLL générée à partir de go manque certains indicateurs de compilateur/éditeur de liens qui (je suppose) ne peuvent être définis que par la chaîne d'outils MSVC.

@TopperDEL Windows Store vous indique-t-il quels indicateurs de compilateur manquent ? Si mingw-64 les prend en charge, vous pouvez toujours utiliser -extldflags avec les bons indicateurs lors de la construction de la dll.

@qmuntal Oui, ils le font :
"Appliquez les options d'éditeur de liens requises - SAFESEH, DYNAMICBASE, NXCOMPAT et APPCONTAINER - lorsque vous liez l'application."

j'ai déjà essayé
go build -ldflags="-s -w '-extldflags=-Wl,--dynamicbase,--high-entropy-va'" -o storj_uplink.dll -buildmode c-shared

Mais cela n'a rien changé à la soumission en magasin. Et d'après ma compréhension, au moins SAFESEH est une chose spécifique à MSVC, n'est-ce pas ?

"Appliquez les options d'éditeur de liens requises - SAFESEH, DYNAMICBASE, NXCOMPAT et APPCONTAINER - lorsque vous liez l'application."

Je ne connais aucun moyen simple d'activer les indicateurs SAFESEH ou APPCONTAINER dans Mingw-w64, peut-être que ce projet https://github.com/status-im/mingw-windows10-uwp peut vous donner quelques conseils.

D'un autre côté, DYNAMICBASE et NXCOMPAT seront activés par défaut dans go 1.16 (voir #41421) mais peuvent déjà être utilisés avec -extldflags comme mentionné, en fait je le fais pour certains projets.

@qmuntal Merci ! Donc au moins mes extldflags ci-dessus devraient être corrects?
Je vais jeter un œil au mingw pour Windows 10-uwp.