Closed Menelion closed 6 years ago
I will have a check about Go 1.9
It seems that we are already compatible with Go 1.9 . Updated appveyor and travis-ci settings.
I saw that you are using 32 bit windows, which is actually not tested and may be not supported, as it will consume (probably) more than 4GB memory when compiling.
However, using the binary-only-package on 32bit windows is fine
But still no way to build under Windows 32 bit?
Actually I don't think it can build on 32bit OS because of the memory limitation. Could you provide detailed error log?
Sorry, I haven't even tried yet, after having read Readme. What I did
try to do was simply to build the tapedon
example using a released
.a version of the package. And then I got those reference errors (see
above).
Ah, the errors are caused by the incompatibility between MinGW and wxWidgets 3.1. See https://github.com/dontpanic92/wxGo/issues/23
So in my case it is go build -tags mingw_workaround
, right?
Yes
No dice:
D:\dev\gocode\src\github.com\Oire\dapeton>go build -tags mingw_workaround
# github.com/Oire/dapeton
C:\Go\pkg\tool\windows_386\link.exe: running gcc failed: exit status 1
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-uuid.o):uuid.c:(.rdata+0x90): multiple
definition of `CLSID_StdURLMoniker'
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-extras-uuid.o):extras-uuid.c:(.rdata$CL
SID_StdURLMoniker[_CLSID_StdURLMoniker]+0x0): first defined here
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-uuid.o):uuid.c:(.rdata+0xa0): multiple
definition of `CLSID_MkProtocol'
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-extras-uuid.o):extras-uuid.c:(.rdata$CL
SID_MkProtocol[_CLSID_MkProtocol]+0x0): first defined here
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-uuid.o):uuid.c:(.rdata+0xb0): multiple
definition of `CLSID_HttpSProtocol'
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-extras-uuid.o):extras-uuid.c:(.rdata$CL
SID_HttpSProtocol[_CLSID_HttpSProtocol]+0x0): first defined here
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-uuid.o):uuid.c:(.rdata+0xc0): multiple
definition of `CLSID_HttpProtocol'
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-extras-uuid.o):extras-uuid.c:(.rdata$CL
SID_HttpProtocol[_CLSID_HttpProtocol]+0x0): first defined here
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-uuid.o):uuid.c:(.rdata+0xd0): multiple
definition of `CLSID_GopherProtocol'
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-extras-uuid.o):extras-uuid.c:(.rdata$CL
SID_GopherProtocol[_CLSID_GopherProtocol]+0x0): first defined here
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-uuid.o):uuid.c:(.rdata+0xe0): multiple
definition of `CLSID_FtpProtocol'
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-extras-uuid.o):extras-uuid.c:(.rdata$CL
SID_FtpProtocol[_CLSID_FtpProtocol]+0x0): first defined here
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-uuid.o):uuid.c:(.rdata+0xf0): multiple
definition of `CLSID_FileProtocol'
C:/MinGW/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-ming
w32/lib/../lib/libuuid.a(lib32_libuuid_a-extras-uuid.o):extras-uuid.c:(.rdata$CL
SID_FileProtocol[_CLSID_FileProtocol]+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
Please try installing wxGo first: go install -tags mingw_workaround github.com/dontpanic92/wxGo/wx
, I'm not sure whether the tags can be passed to wxGo when directly build an application
Interesting. I tried go get
on my Win32 machine, and it didn't say "out of memory". Unfortunately I don't know how to log everything that is output (>
piping does not work for go get
, it seems), but it threw a bunch of deprecation warnings from WXWidgets 3.1, and then the following:
# github.com/dontpanic92/wxGo/wx
C:\Users\Andre\AppData\Local\Temp\go-build520743906\github.com\dontpanic92\wxGo\
wx\_obj\wx_wrap_windows.cxx.o: In function `wrap_ListCtrl_SortItems_wx_d5626d6e5
7cb98ce':
D:/dev/gocode/src/github.com/dontpanic92/wxGo/wx/wx_wrap_windows.cxx:46137: unde
fined reference to `wxListCtrl::SortItems(int ( stdcall*)(long, long, long), lon
g)'
collect2.exe: error: ld returned 1 exit status
Sorry to bother you so much but I really would like to make this work. I liked WXPython very much, but I would like to migrate to Go in my development, and I have huge reasons to proceed with WX rather than change my framework. Thank you!
It's a little weird. I will get a 32bit windows virtual machine to have a test.
Did you manage to look at this?
I have tried compiling on 32bit Windows, and did not encounter your problem. But I still can't manage to build it successfully, maybe because I used a MinGW version that different from what I used to build the wxWidgets library. (I'm having a headache on making all different MinGW distributions work. Perhaps I will only focus on the MinGW-w64 distributed with MSYS2 in the near future).
A workaround is that let AppVeyor build and save a 32bit binary-only-package, if you can't find a 64bit Windows system to build it, then you can use the binary-only-package on 32bit systems. I'm going to have a try.
I made a test of build recently on Win7 64 bit and it failed. I have not keeped the logs. There are also a problem of config it seems me. I could try yet another build.
Hello and thank you for your work!
Is it planned to support Go 1.9.x?