I wrote a very simple program in Go using using a 2D game library.
package main
import (
"github.com/hajimehoshi/ebiten"
"github.com/hajimehoshi/ebiten/ebitenutil"
)
const screenWidth, screenHeight = 320, 240
func update(screen *ebiten.Image) error {
ebitenutil.DebugPrint(screen, "Game test")
return nil;
}
func main() {
if err := ebiten.Run(update, screenWidth, screenHeight, 2, "Test"); err != nil {
panic(err)
}
}
This, however, relies on GCC to compile. When running, I'm prompted with this message:
# github.com/go-gl/glfw/v3.2/glfw
cc1.exe: sorry, unimplemented: 64-bit mode not compiled in
# github.com/go-gl/gl/v2.1/gl
cc1.exe: sorry, unimplemented: 64-bit mode not compiled in
I attempted to download MinGW-w64 to rectify the issue, but it hasn't been successful.
How would I go about resolving this?
So your C compiler does not support 64 bit compilation. One way to resolve this is to build in 32 bit mode. Go will by default try to build for the system architecture that you are on but you can modify that behavior by setting the environment variable GOARCH=386 before building. On Windows you can type this into your cmd:
set GOARCH=386
go build
You could create a simple .bat batch script with this content and run that when you want to build.
Note that 64 bit systems will run 32 bit programs just fine. This is also a nice way to make sure that when you give the .exe to someone else, it will run on their system (not considering other dependencies).
If you want to upgrade your C compiler instead to build 64 bit applications, see this SO thread, maybe that helps.
Related
I have the following piece of code:
#include <stdio.h>
#include "S:\fftw\fftw3.h"
int main()
{
fftw_complex* in;
fftw_complex* out;
fftw_plan p;
in = (fftw_complex*)fftw_malloc(sizeof(fftw_complex));
out = (fftw_complex*)fftw_malloc(sizeof(fftw_complex));
p = fftw_plan_dft_1d(1, in, out, FFTW_FORWARD, FFTW_ESTIMATE);
fftw_execute(p);
fftw_destroy_plan(p);
fftw_free(in);
fftw_free(out);
printf("test!\n");
return 0;
}
when I compile with
gcc -g .\test.c -o test S:\fftw\libfftw3-3.dll
and execute the generated
test.exe
it does execute without errors but doesn't show the printf message. If I use gdb and simply run the program there, no matter what I try, gdb freezes and just gives the following output:
Starting program: S:\Notes\C\numerics\src\test.exe
[New Thread 8244.0x2a80]
[New Thread 8244.0x1668]
[New Thread 8244.0x4790]
[Thread 8244.0x1668 exited with code 3221225781]
This happens from the exact moment I call a function that has to be linked to the .dll, everything works fine if I don't.
I am using
gcc.exe (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project) 8.1.0
and
GNU gdb (GDB) 8.1, This GDB was configured as "x86_64-w64-mingw32".
from MingW64 and I simply downloaded the fftw .dlls from the mainpage.
Can anyone help? I have absolutely no clue what this is about.
From the debugger, you can see the exit code 3221225781, which is 0xC0000135 in hexadecimal. If you look it up on MS-ERREF, it means "STATUS_DLL_NOT_FOUND" and "{Unable To Locate Component} This application has failed to start because %hs was not found. Reinstalling the application might fix this problem."
Likely, the application can't find libfftw3-3.dll. You need to either put it in the same directory of the executable, or in one of the other DLL search paths.
If you start the application from explorer (double clicking), it should also tell you that message, including the DLL name it couldn't find if you continue to get the same exit code.
I had compiled a simple hello world program in C with the MinGW compiler using the command line. As it had finished compiling, windows defender popped up and detected a virus (Trojan:Win32/Fuery.C!cl).
#include <stdio.h>
#include <stdlib.h>
int main() {
printf("Hello World");
return 0;
}
https://imgur.com/a/05yDjw5
I had taken action on this (Removed) as windows defender suggested, but when I compile again the same happened, multiple times.
I had downloaded an AntiVirus (Malwarebytes) and scanned my whole system and it detected some registry key errors, but not this.
I've tried compiling C++ files too, but windows defender did not detect any virus there. This only happens when I compile in C.
I've also tried checking the compiled executable at VirusTotal.
https://www.virustotal.com/gui/file/476d47215dad80db49c9fd508ab5e10e5aeb5b623248ca156830a28b70affe5f/detection
I tried CodeBlock's MinGW compiler and 0 engines detected it. (Same C file)
https://www.virustotal.com/gui/file/8ba4b0fa24b1b6b69152acce2353fcca8447bbecbfc4e5ec48d33cc75d94f2f1/detection
EDIT: I deleted the path variable of C:/MinGW and added CodeBlock's MinGW compiler. I then used the command line to compile the same C file again and had uploaded the .exe file to VirusTotal. This time, 0 engines detected. So I have come to the conclusion that, the MinGW compiler that I had installed was creating this problem.
https://www.virustotal.com/gui/file/34d383f6c09f897d8c9a44ed0e7850574320e50fdf439eeb1f06705fdcc95386/detection
I don't know why this happens. Is there a malware in my computer that affects my C programs or is this a false detection?
There is no malware, it is a false positive. The executable generated by your version of MinGW looks very similar to a particular virus.
To avoid the problem, add the directory where you build your code to the list of exclusion in the antivirus.
Also consider using mingw-w64 instead of mingw.org .
I came across with the same problem, compiler tdm gcc v9.2.
The following compilation triggers a warning (kaspersky).
gcc temp.c -o temp.exe
The following does not
gcc -O3 temp.c -o temp.exe
Where temp.c is
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
int main() {
int a, b;
scanf("%d %d", &a, &b);
printf("mod %4d, %4d is %4d\n", a, b, a%b);
return 0;
}
The same code with g++ passes the test with both compilations. The antivirus software does not detect the same virus elsewhere but only in temp.exe (first compilation).
I may have solved my problem.
This is what I did: I removed the PATH Variable of C:\MinGW and added CodeBlock's MinGW compiler (CodeBlocks/MinGW/bin). I used the command line to compile the same C file, and had uploaded the .exe to VirusTotal. No engines detected this file!
https://www.virustotal.com/gui/file/34d383f6c09f897d8c9a44ed0e7850574320e50fdf439eeb1f06705fdcc95386/detection
So I have come to a conclusion that, MinGW was the compiler that was causing this problem. I have removed it.
However, I am not quite sure if this problem is FULLY solved. There is still a possibility of malware affecting my executable (or perhaps not). I cannot be sure.
If anyone has any answers, please comment or answer
I ran into this after installing MinGW on 01-08-20(dd-mm-yy).
For me it was also Windows Defender, the way to - hopefully temporarily- get rid of this is to add an exception for the folder your compilation output will reside in.
The Microsoft website states these steps to add an exclusion:
Go to Start > Settings > Update & Security > Windows Security > Virus & threat protection.
Under Virus & threat protection settings, select Manage settings, and then under Exclusions, select Add or remove exclusions
I had a similar problem. I figured out that the following dll was missing: mingw32-libmingwex-dll. Once I installed it via "MinGW Installation Package", I didn't have the problem anymore.
I hope this can help others.
Since you wrote that program and you know it isn't actually a Trojan, it's obviously a false positive. You should submit the file to them at https://www.microsoft.com/wdsi/filesubmission so they can figure out why it's triggering the false positive and fix it. (If it happens with everything you compile, just sending them one will suffice.) In the meantime, you should add an exclusion to Windows Defender for the folder that you compile your executables in.
I'm brand new to Go and am not experienced in compilation issues or with C++. So starting from zero, I'm trying to compile a dll in Go and call a function in VBA. I'm developing the Go in Linux, and switching computers to try it in Windows. The VBA part may not be essential. It does serve as a way for me to test the dll call.
Here's the simple Go code:
package main
import (
"C"
"fmt"
)
func main() {
var x int
x = Test()
fmt.Println(x)
}
func Test() int {
return 666
}
It works for go build, go install, and calling main from the console.
I compile with these two commands, which both run without error, in this order. Should I be running both of them? (I'm way out of my depth here.) The target system is Windows 10, 64 bit with Office 365 ProPlus (but is Excel fundamentally 32 bit?):
env GOOS=windows GOARCH=386 CGO_ENABLED=1 CC=i686-w64-mingw32-gcc go build -buildmode=c-shared -o hello.dll hello.go
env GOOS=windows GOARCH=amd64 CGO_ENABLED=1 CC=x86_64-w64-mingw32-gcc go build -buildmode=c-shared -o hello.dll hello.go
I copy the file, hello.dll, to System32 and in VBA I declare:
Public Declare Function Test Lib "C:\Windows\System32\hello.dll" () as Long
I get the error of Run-time error '53': File Not Found, which I understand may be caused by a missing dependency.
So I run Dependency Walker. This shows me a top level of HELLO.DLL and 4 levels under it of KERNEL32.DLL, MSVCRT.DLL, WINMM.DLL, WS2_32.DLL. And it gives:
Error: At least one required implicit or forwarded depende3ncy was not found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresovled import due to a missing export function in a a delay-load dependent module.
There's a huge number of yellow question marks. And dozens of Modules with Error opening file, with names like API-MS-WIN-CORE-... and EXT-MS-WIN-NTUSER-... as well as HVSIFILETRUST.DLL and IESHIMS.DLL and EMCLIENT.DLL
So I've got a few moving parts in my lap and I'm way out of my depth. I'm hoping I'm just missing a simple step (maybe put the dll in a different folder??). If this should be an ambitious or difficult task, I should probably let it go.
I compile the following Go program on a linux/amd64 box:
package main
import (
"fmt"
"os/user"
)
func main() {
fmt.Println(user.Current())
}
This works fine. But when I cross compile it from a Mac box, I get the following error when I run that program on my linux box:
user: Current not implemented on linux/amd64
How can I cross compile and use the Current function in package os/user?
Edit 1:
I should add that these are the instructions I've used to setup cross compiling on my Mac box: https://code.google.com/p/go-wiki/wiki/WindowsCrossCompiling
Edit 2: cross compiling for windows/386 works fine.
This is due to Issue 6376: user.Current panic in darwin-amd64 when crosscompiled from linux-amd64:
os/user relies on cgo, and cgo is disabled for cross compiling,
thus this is expected.
if you use os/user, you must compile natively on OS X.
even if we enable cross compilation cgo support, I doubt everybody have
a working OS X cross toolchain on their linux machine.
Status: WorkingAsIntended
so, I'm trying to compile Gwen in Windows, for use with a project I have coming up. I downloaded the source from Garry's GitHub, and followed his instructions on building the compilation before importing it to Code::Blocks to compile. I import the .cbp file, start compiling, and after a few minutes I get:
Error: '_asm' was not declared in this scope.
The error comes from some code after a line containing #ifdef _WIN32.
Exact file: gwen.cpp, line 49.
More information:
OS: Windows 7 64bit.
Compiler: Latest gcc from the MinGW, 4.7.2 (MinGW32)
I think it is because MinGW doesn't understand the assembler, it should be asm for that compiler. I think this is cause by using _WIN32 instead of WIN32. The former is the platform and the latter is API.
Try changing it to:
void AssertCheck(bool b, const char* strMsg)
{
if (!b)
{
Msg("Assert: %s\n", strMsg);
#ifdef WIN32
MessageBoxA(NULL, strMsg, "Assert", MB_ICONEXCLAMATION|MB_OK);
_asm { int 3 }
#endif
}
}
EDIT: Alternatively you could try Gwork, which is a tidied up version of GWEN.