[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #8 from Ian Lance Taylor --- Thanks. Those suggested changes aren't going to make any difference as those are text files anyhow. One is a generated C header that #include'd by C files, and the other is a dump file intended for human inspection. The .gox files are not generated directly by the Go frontend. They are generated by writing out an object file in the usual way, and then using objcopy to create the .gox file. Ths form of .gox file is an object file that only contains a single section.
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #7 from Brecht Sanders --- I'm still trying to understand how it all works, but to avoid \n versus \r\n issues on Windows I would already recommend these changes: ``` patch -ulbf gcc/go/gofrontend/gogo.cc << EOF @@ -5252,3 +5252,3 @@ std::ofstream out; - out.open(this->c_header_.c_str()); + out.open(this->c_header_.c_str(), std::ios_base::binary); if (out.fail()) EOF patch -ulbf gcc/go/gofrontend/ast-dump.cc << EOF @@ -197,3 +197,3 @@ dumpname += ".dump.ast"; - out.open(dumpname.c_str()); + out.open(dumpname.c_str(), std::ios_base::binary); EOF ``` Unfortanately this doesn't solve the issue though. I couldn't figure out yet where the code is that makes go_read_export_data in gcc/go/go-backend.cc skip the part before the magic string...
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #6 from Ian Lance Taylor --- The magic string itself is fine: it's the "v3;\n". Perhaps there is some problem locating it in the file. Some of the relevant code is go_read_export_data in gcc/go/go-backend.cc. Try to find out what it returns.
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #5 from Brecht Sanders --- The generated internal/cpu.gox looks like the below dump. Can you see what the issue is with the magic string? ``` : 6486 0100 5809 0200 d...X... 0010: 0500 2f34 /4.. 0020: 1c09 3c00 <... 0030: 4000 3040 7633 3b0a @.0@v3;. 0040: 7061 636b 6167 6520 6370 750a 706b 6770 package cpu.pkgp 0050: 6174 6820 696e 7465 726e 616c 2f63 7075 ath internal/cpu 0060: 0a69 6e69 7420 6370 7520 696e 7465 726e .init cpu intern 0070: 616c 5f31 6370 752e 2e69 6d70 6f72 740a al_1cpu..import. 0080: 7479 7065 7320 3134 2032 2033 3120 3130 types 14 2 31 10 0090: 2032 3220 3435 2034 3031 2032 3539 2031 22 45 401 259 1 00a0: 3531 2038 3920 3131 3220 3530 3320 3235 51 89 112 503 25 00b0: 2032 3120 3232 0a74 7970 6520 3120 2243 21 22.type 1 "C 00c0: 6163 6865 4c69 6e65 5061 6422 203c 7479 acheLinePad" .type 2 (). 00e0: 7479 7065 2033 2028 3f20 3c74 7970 6520 type 3 (? ).type 4 str ```
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #4 from Ian Lance Taylor --- > What exactly would be the file(s) being opened in this case? The file that should be opened is the file internal/cpu.gox in the libgo build directory. > When can we expect the libgo cleanup needed for MinGW(-w64) support? I don't know of anybody who is working on this.
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #3 from Brecht Sanders --- What exactly would be the file(s) being opened in this case? When can we expect the libgo cleanup needed for MinGW(-w64) support?
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #2 from Ian Lance Taylor --- I have no idea why you would get a "Permission denied" error opening an import package. That said I would not expect this to work. Somebody would have to clean up libgo to support Windows.
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #1 from Brecht Sanders --- P.S.: This attempt was with snapshot version 12-20220417
