I'm looking to give the 'Go' programming language a try but I'm having trouble getting even a simple test example to work. I think it's probably an issue with the port so I've submitted a ticket under issues in gomingw project page.
What steps will reproduce the problem?
Create any simple go test program
compile it with 8g. ie. 8g hello.go
link it with 8l. ie. 8l hello.8
What is the expected output? What do you see instead?
I expect 8l to link successfully with no errors. Instead I see the follow errors output followed with a crash.
> goos is not known: mingw
> warning: uanble to find runtime.a
> runtime.morestack not defined
What version of the product are you using? On what operating system?
This is on windows 7 with gowin32_2010-12-02.zip
Please provide any additional information below.
I have set the 4 standard go variables on my environment as follows:
goos = mingw, gobin = G:\oss\go\bin, goarch = 386, goroot = G:\oss\go
From looking at the error, I'm going to say it looks like it needs something from mingw gcc toolset? Though I see no mention of this requirement anywhere, neither in the readme or install. What is the runtime.a that is missing? Is it part of mingw? I've also tried one version before this latest one and the problem is present on that version as well.
Has anyone else that's tried Go's port of windows encountered an issue like this? What could be causing this?
Thanks
The reason for the failure is stated in the error message: goos is not known: mingw. Read the instructions for setting the GOOS environment variable. Set GOOS=windows.
You should also be using the latest release of the Go Windows port binary.
Related
I am attempting to compile a go program. The code is a small x11 window manager, found HERE. (The code is 98 lines, too long to post here)
Here is the command I run, on x86-64 Ubuntu:
GOOS=linux GOARCH=386 go build littlewm.go
This command works fine on other files in the same directory. However, when I try to compile this one, I get the following error:
can't load package: package main: no buildable Go source files in /home/ubuntu/workspace/Go
This does not involve the gopath variable, as I have successfully compiled other programs in the same directory. I have a suspicion it involves the code itself or some option I am lacking. As such, this is not really a duplicate of an existing question and is quite possibly unique, since I am not getting the answer I want from other similar questions. Any help is appreciated greatly.
Thanks!
I encountered a similar problem when trying to build my own go program.
I had just added GCO to interface with some native C code in a library.
It built for me for the native platform (the machine I was coding on), but not when I tried to target another platform (using GOOS and GOARCH as you're doing).
Setting CGO_ENABLED to 1 (as mentioned in david's comment) fixed the problem for me:
CGO_ENABLED=1 GOOS=linux GOARCH=386 go build littlewm.go
I was using a makefile to build for multiple platforms using multiple rules, so for me, I put
export CGO_ENABLED = 1
near the top of my makefile so that I didn't need to specify it for each platform.
I recently started trying go to program some web based applications. At first, everything went fine, until I wanted to cross compile a binary for a different platform. I'm running MacOS and I wanted to compile a binary for linux, so I changed GOOS to linux and GOARCH to amd64. Since then, I always get the error message
go tool: no such tool "compile"
I'm using GoClipse, but running the compile manually by
go install hello.go
I get the same error. When changing back to compiling for darwin architecture, I get the same error now, so basically I'm totally unable to compile any code written in Go at the moment.
I installed it via the binary packages provided by google. In the end I actually got it back to work by just reinstalling it. Sometimes I'm just blind to the easy solution.
After that, I succeeded in cross compiling for linux machine after compiling the necessary cross-compilers by running env GOOS=linux GOARCH=arm GOROOT_BOOTSTRAP=/usr/local/go ./make.bash --no-clean from the Go sources directory.
Thanks for all you efforts, sorry to have kept you busy on such a simple matter.
You have the wrong x64 or x386 package installed most likely. I had 32 installed running 64 bit. Reinstall fixed. Good luck.
You might be able to get away with that if you install Go 1.5, however if you use anything that depends on cgo, you will have to install a cross-compiler linker or install Linux on a virtual machine to be able to cross compile for Linux.
In my case is due to the fact that GOPATH and GOROOT are not set correctly, maybe you can check go env. Here is a discussion may be useful.
The way I figured-out what file is read and caused Go to look for the compile binary in the wrong place can be solved using:
$ strace go tool -n compile 2>&1 |grep openat
openat(AT_FDCWD, "/home/nwaizer/.config/go/env", O_RDONLY|O_CLOEXEC) = 3
In that file, the IDE Goland, add a path to some project, causing the havoc.
On a Windows system, currently I'm trying a waf configure on a directory of code, and it spits out the error "could not configure a C compiler."
Now, I'm 100% certain that I have gcc and g++ installed and in my path because when I type gcc --version, it gives me the current version information. (I'm using mingw and the gcc/g++ are in the /bin subdirectory).
In the author's code directory there is a wscript file which looks like
C_COMPILER = 'gcc-4.7'
CPLUSPLUS_COMPILER = 'g++-4.7'
Now, I have tried changing the strings to simply gcc as well as gcc-4.8.1 (since my current version is 4.8.1), but it still says could not configure compiler.
I tried reading one solution on this same site that looks related, but the solution was on ubuntu and trying to work through those commands didn't help
could not configure a c compiler
I'm at the end of my common sense here after making sure I have gcc and g++ installed, trying different strings in the wscript file trying to get it to recognize I have them installed, and could use some help, thanks.
Edit: I've now tried simply deleting the lines in the wscript file where it changes the compiler name, and suddenly waf configure goes through, but the waf build fails saying things like it can't find really basic things like include vector. The output says it's defaulting to msvs (microsoft visual studio) whereas the author says gcc/g++ is needed; maybe this is the issue but how do I get waf configure/build to use g++/gcc as default?
I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application
I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.
After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)
Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).
If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!
I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.
I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue.
So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it.
That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237
To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.
I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:
Open CMD
cd C:\MinGW\bin to navigate to the bin directory of mingw
now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe
alternatively if u want to automate the process u can make a batch file to automatically do it for you.
here's the batch file if anyone needs it
#echo off
C:
cd \MinGW\bin\
gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!
pause
I had a similar error but over came it by editing my environment variables.
I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared
I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.
My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.
Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:
Path=c:\msys64\mingw64\bin;%PATH%
The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.
I was able to cabal install text-icu without errors. (I used --extra-lib-dirs and --extra-include-dirs to point to the lib and include directories in the binary distribution of icu4c.)
I was also able to build the following simple program that uses text-icu, by doing ghc --make icu.hs:
-- icu.hs
import Data.Text.ICU
main = print $ Locale "tr-TR"
No errors or warnings in either of these steps. But when I try to run the compiled program, icu.exe, I get no output at all. I expected to get a line with Locale "tr-TR", but instead I get nothing -- not even an error or warning. This remains the case if I try
main = do
print $ Locale "tr-TR"
print "Done"
so using the text-icu stuff seems to cause the program to silently fail. echo $? yields False.
Does anyone have text-icu up and running on Windows? Can you tell me what I'm doing wrong?
Stack includes a copy of msys2 on Windows, which contains the pacman package manager, so we can run:
stack exec -- pacman -Sy mingw64/mingw-w64-x86_64-icu
stack build text-icu
I managed it by doing:
Download the binaries from http://site.icu-project.org/download/56#TOC-ICU4C-Download, specifically http://download.icu-project.org/files/icu4c/56.1/icu4c-56_1-Win32-msvc10.zip.
Extract the contents of icu/bin into the directory C:\bin which is on my %PATH%. Extract the contents of icu into the directory C:\bin\icu.
Use Stack to run stack ghci text-icu --extra-lib-dirs=c:\bin --extra-include-dirs=c:\bin\icu\include.
In GHCi, run import Data.Text.ICU.Normalize, then :set -XOverloadedStrings, then normalize None "test".
For each dll that is reported as cannot be found, e.g. icuuc.dll, take the C:\bin\icuuc56.dll and make a copy at C:\bin\icuuc.dll. For me, there were three relevant dlls.
After all that, I can normalise a string in ghci.
This is how windows reacts to a missing static dependency. When the operating system starts a process it looks for static dependencies. If one is missing, then program is not started.
Use depends.exe to find out what import is missing. That could be a missing dll or one that is the wrong version.
Depends is available with
1. Visual Studio
2. The Microsoft Platform SDK
3. Other microsoft packages
4. http://www.dependencywalker.com
It pretty indispensable when tracking down what is happening in this case.
you should check if there are some DLL missing with cygcheck.check the path and the windows enviroment variables too with it is right. Or try to reinstall following the haskell procedure.
http://www.haskell.org/haskellwiki/Windows#Tools_for_compilation
good luck