[Bug go/105302] New: gccgo for Windows using MinGW-w64

[Bug go/105302] New: gccgo for Windows using MinGW-w64

[brechtsanders at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302

            Bug ID: 105302
           Summary: gccgo for Windows using MinGW-w64
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: brechtsanders at users dot sourceforge.net
                CC: cmang at google dot com
  Target Milestone: ---

I thought I's give building gccgo for Windows using MinGW-w64 another try.

First of all I had to change `configure` to allow me to do that:
```
patch -ulbf configure << EOF
@@ -3577,3 +3577,3 @@
 case "\${target}" in
-*-*-darwin* | *-*-cygwin* | *-*-mingw* | bpf-* )
+*-*-darwin* | *-*-cygwin* | bpf-* )
     unsupported_languages="\$unsupported_languages go"
@@ -3609,3 +3609,3 @@
        ;;
-    *-*-cygwin* | *-*-mingw*)
+    *-*-cygwin*)
        noconfigdirs="\$noconfigdirs target-libgo"
EOF
```

Then I added `go` to `--enable-languages=` and I added `--enable-libgo` to the
`./configure` line.

It got pretty far this time, and I actually go a working `gccgo.exe`, but libgo
wasn't such a success:
```
libtool: compile: 
/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/./gcc/gccgo
-B/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/./gcc/
-L/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/lib
-L/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/mingw/lib -isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/include
-isystem /R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/mingw/include
-B/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/bin/
-B/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/lib/
-isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/include
-isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/sys-include
--sysroot=/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/mingw-w64
-minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/bytealg
../../../libgo/go/internal/bytealg/bytealg.go
../../../libgo/go/internal/bytealg/compare_native.go
../../../libgo/go/internal/bytealg/count_generic.go
../../../libgo/go/internal/bytealg/equal_generic.go
../../../libgo/go/internal/bytealg/equal_native.go
../../../libgo/go/internal/bytealg/gccgo.go
../../../libgo/go/internal/bytealg/index_native.go
../../../libgo/go/internal/bytealg/indexbyte_native.go  -DDLL_EXPORT -o
internal/.libs/bytealg.o
../../../libgo/go/internal/bytealg/bytealg.go:8:21: warning: ./internal/cpu:
Permission denied
    8 |         "internal/cpu"
      |                     ^
../../../libgo/go/internal/bytealg/bytealg.go:8:21: error: error in import data
at 2329: invalid magic string
```

I feel we're getting closer. Any idea what caused this error?

[Bug go/105302] gccgo for Windows using MinGW-w64

[brechtsanders at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302

--- Comment #1 from Brecht Sanders <brechtsanders at users dot sourceforge.net> ---
P.S.: This attempt was with snapshot version 12-20220417

[Bug go/105302] gccgo for Windows using MinGW-w64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302

--- Comment #2 from Ian Lance Taylor <ian at airs dot com> ---
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

[brechtsanders at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302

--- Comment #3 from Brecht Sanders <brechtsanders at users dot sourceforge.net> ---
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

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302

--- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
> 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

[brechtsanders at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302

--- Comment #5 from Brecht Sanders <brechtsanders at users dot sourceforge.net> ---
The generated internal/cpu.gox looks like the below dump. Can you see what the
issue is with the magic string?
```
00000000: 6486 0100 0000 0000 5809 0000 0200 0000  d.......X.......
00000010: 0000 0500 2f34 0000 0000 0000 0000 0000  ..../4..........
00000020: 0000 0000 1c09 0000 3c00 0000 0000 0000  ........<.......
00000030: 0000 0000 0000 0000 4000 3040 7633 3b0a  ........@.0@v3;.
00000040: 7061 636b 6167 6520 6370 750a 706b 6770  package cpu.pkgp
00000050: 6174 6820 696e 7465 726e 616c 2f63 7075  ath internal/cpu
00000060: 0a69 6e69 7420 6370 7520 696e 7465 726e  .init cpu intern
00000070: 616c 5f31 6370 752e 2e69 6d70 6f72 740a  al_1cpu..import.
00000080: 7479 7065 7320 3134 2032 2033 3120 3130  types 14 2 31 10
00000090: 2032 3220 3435 2034 3031 2032 3539 2031   22 45 401 259 1
000000a0: 3531 2038 3920 3131 3220 3530 3320 3235  51 89 112 503 25
000000b0: 2032 3120 3232 0a74 7970 6520 3120 2243   21 22.type 1 "C
000000c0: 6163 6865 4c69 6e65 5061 6422 203c 7479  acheLinePad" <ty
000000d0: 7065 2034 3e0a 7479 7065 2032 2028 290a  pe 4>.type 2 ().
000000e0: 7479 7065 2033 2028 3f20 3c74 7970 6520  type 3 (? <type
000000f0: 2d31 363e 290a 7479 7065 2034 2073 7472  -16>).type 4 str
```

[Bug go/105302] gccgo for Windows using MinGW-w64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302

--- Comment #6 from Ian Lance Taylor <ian at airs dot com> ---
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

[brechtsanders at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302

--- Comment #7 from Brecht Sanders <brechtsanders at users dot sourceforge.net> ---
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

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302

--- Comment #8 from Ian Lance Taylor <ian at airs dot com> ---
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.