-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows Support [$30] #228
Comments
Wow that sounds fantastic. martell [email protected] schrieb:
|
Thank you! |
"C:\msys64\mingw32\pkg\tool\windows_386\8l.exe" -o "C:\msys64\tmp\go-build836004963\lime\3rdparty\libs\gopy_test\gopy.test.exe" -L "C:\msys64\tmp\go-build836004963\lime\3rdparty\libs\gopy_test" -L "C:\msys64\tmp\go-build836004963" "C:\msys64\tmp\go-build836004963\lime\3rdparty\libs\gopy_test\main.a" Great success :) |
Wow, that's awesome! |
what do I do after gopy? The guide was changed awhile back because cmake was added. I already have onig build in gcc and obviously python3.3 with .a libs EDIT: It's okay I'll just follow the steps in the cmakelists manually :) |
It would be nice if you tell us how to reproduce the python build. |
I'm using msys2 and pacman. mingw-w64-x86_64-python3 is a package for it. I recently added go itself but we are working out the issues with it. |
I am also on msys2. I played around yesterday with it. How did you generate the static python lib? Did you you use 32bit or 64bit toolchain, go? |
Is the mentioned crt fix already online? |
https://github.com/martell/MINGW-packages Just "pacman -Syu" to update the crt |
But python3 is build as a shared lib by default isn't it? With mingw (not w64) they used pexports. How did you handle that? What is wrong with the CFLAGS? |
Python3 is compiled with mingw64 so we don't need to do the exports. We don't use visual studio for anything. Nor do we rely on visual studio builds of any library The equivalent to pexports would be gendef. We don't need it here though |
Okay so I have successfully build the termbox frontend with mingw64. The qml build gives me this error after setting up the bindings. |
https://www.dropbox.com/s/2ibydge1x8k9s1w/lime.7z I have successfully built the termbox, html and I dropped back in the qt5 main.go as the qml one wouldn't link Termbox seems the best so far. look in build/bin for exe's and don't move them as they are folder structure relevant |
@martell: did you try running the termbox frontend from Windows command prompt instead of mintty? |
@EdVanDance |
@martell I can't get it to run. I installed i686 python3 (I'm on x86_64). Opened a cmd:
And I get:
|
You shouldn't have to set PYTHONHOME as I've included he python dll's Now I maybe wrong but I didn't do that anyways. The patch has been merged into the mingw64-crt and alexey will be doing an update soon ;) |
If I do not set the PYTHONPATH. I get:
Do you start the command prompt from within msys? I started it directly via |
No I directly went to cmd like you did, PYTHONHOME is not defined on my system. This could explain why it crashes at a certain point also, maybe I'm using the wrong python files Did you install mingw python3 or msys2 python3 they are very different |
Hmm that could be the reason. But I dont't understand why it complains after setting up the PYTHONPATH. |
I got it.
Without |
Nice ;) and your output? |
Shows the file content, but does not react on key presses. And complains about 256 color mode. |
In the zip I uploaded I have all my cgo.go files for reference if you want to build from source ;) Can you pastebin it please :) I get as far as here [2014/01/25 04:08:33 GMT] INFO Python sez: Loading plugin Vintageous.jump_list_cmds |
Same here: |
Okay Well I'll try and get alexey to merge my go package and onig shared package. |
Thanks a lot. That definitely helps a lot. Did you also try a 64bit build? |
I didn't but it should be the same. |
Ok nice. Could you tell me the difference between the msys2 and msys64 base downloads on sourceforge? |
Are the Python features required for a working Lime? I tried commenting out import of gopy & sublime (and three lines that depend on it) in both frontend/html and frontend/termbox, and also replaced import of rubex with
any ideas? :) |
About the termbox you can get information from log file that is created with every build and you should know we have vintageous plugin that gives some vim features so you should press |
@zoli we weren't able to build for quite awhile as msys updated mingw python to 3.4 which gopy and go 1.3.1 has only just fixed. Now that the python3.4 issues have been resolved I am looking at using msys2 and mingw-64 and go to build lime text. Here is my current error
It seems this commit breaks gopy on windows Want to back this issue? Place a bounty on it! We accept bounties via Bountysource. |
If I comment them out i get this error here is the build guide for building limetext in msys2 on windows a go 1.3.3 package will hit the servers tomorrow hopefully :) |
|
Yes it finds the libraries correctly. |
Okay so here are my results. without: with: Edit: seems 32bit go on windows prints a more meaningful error
|
to solve this link error I must link against the visual studio runtime unfortunately i have to pick a c++ runtime also like v110 or v110 which is annoying for a mingw-w64 application. okay so now I can actually build :) EDIT: I can build the termbox but qml front end gives me this $ go build |
Here is my termbox output: Seems a bit better than a few months ago but it still crashes
|
Nice work! What's the backtrace for the crash? If you launch it with "./termbox main.go" does it try and display this file correctly? If you comment out the gopy import + calls, does it still crash? If not, it might be one of the standard Go mingw issues. |
@quarnster: I have no idea about the back trace :( I don't get to see the output here is the log though
I will try removing the gopy imports and see |
@martell, Backtrace should be dumped to the terminal normally, except in this case we are hijacking the terminal to render some UI so it won't work ;) Try this patch and see if you get something useful in the log: diff --git a/frontend/termbox/main.go b/frontend/termbox/main.go
index 4ff2426..bdecd51 100644
--- a/frontend/termbox/main.go
+++ b/frontend/termbox/main.go
@@ -711,7 +711,9 @@ func main() {
termbox.Close()
log4go.Debug(util.Prof)
if err := recover(); err != nil {
- log4go.Crash(err)
+ log4go.Debug(err)
+ log4go.Debug("%s", string(debug.Stack()))
+ time.Sleep(time.Second) // TODO: see issue #260
}
}() |
Can this thread be reset into new issue with status update? |
@techtonik No need to close :) |
Okay so it seems that currently we are still at the same stage where part of the go language itself does not work properly on windows. I am exploring 2 different possible solutions to this. |
Week is passed. This issue needs to be reticketed with short summary - for now it is impossible to take action on it given all the limitation of real life and free time. |
martell, which part of the go language fails to work properly on windows? Also I think you mean the go implementation rather than the language itself? |
Hi! What news about porting on windows? Do you have any progress? |
I don't entirely know what the problems used to be, but Lime-QML builds and runs fine for me in Windows. Here's my instructions: https://github.com/ricochet1k/lime-qml/wiki/Building-on-Windows-using-MSYS2 |
The year is 2017, the month is June, i.e. 1250 days passed since issue was created. |
have discovered linking errors with mingw64 and go lang and a patch |
unsub me from this |
hey @quarnster,
I'm going to take on the task of the windows port.
I should have it done fairly soon.
I have discovered linking errors with mingw64 and go lang and a patch should be pushed in to the mingw64-crt soon to resolve the last linking error of pygo and other c binded depends.
--- There is a **[$30 open bounty](https://www.bountysource.com/issues/1439455-windows-support?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github).The text was updated successfully, but these errors were encountered: