how to get gcc

[buzzersdad]

I installed ui-master to run a gui using golang, and I am trying to run the demo via command prompt. I get the message "# ui-master exec: "gcc": executable file not found in %PATH%". Where/how can I get that? I found a gcc written in perl, but that can't be it, right?

[andlabs]

You will need to install MinGW-w64.

[buzzersdad]

Thanks. I downloaded the mingw-w64-master package (zip) and put it into my go/src folder, but when I try to run the gui.go demo I still get the same message. I thought maybe I need to do go install mingw-w64-master, but that comes back with: "can't load package: package mingw-w64-master: no buildable Go source files in C:\installed programs\go\src\mingw-w64-master". I looked into the mingw-w64-master folder, and there is no gcc executable there.

[andlabs]

That's not how you install MinGW-w64. You'll need to extract that somewhere global, such as in C:\MinGW or C:\MinGW32 or C:\MinGW64, and add its \bin to your $PATH. (If there's no \bin or no *gcc.exe in \bin, you don't have a pre-buit MinGW-w64 download.) Alternatively, you can use msys2, which makes maintaining MinGW-w64 installations somewhat easier and get other third-party libraries (though package ui won't need any).

[buzzersdad]

OK, Thanks. So @i installed msys32, All went well (very verbose), exactly as the msys32 install instructions say. I now have a mingw64 folder, whose bin folder I added to my 'path' in my environment variables. Still, when I try to run the gui demo I get " # ui-master exec: "gcc": executable file not found in %PATH%". When I look in the mingw64 folder with windows explorer, it turns out the folder is empty. (The mingw64.exe is in the msys32 folder.)

[rxa1031]

You will need to install MinGW-w64.

I want to understand more about above. I want to understand why is it needed, when cgo.exe already exists in (some sub-folder of) go directory.

Also why cannot we tell go to use tool "cgo" rather than using gcc?

I have installed Go version 1.10.3

C:\Users\xxxx>go version
go version go1.10.3 windows/amd64

I know there is some issue about cgo / gcc mentioned on below links:
https://github.com/golang/go/issues/26307
https://github.com/docker-library/golang/issues/230

I however feel using the Go tools provided with the Go installer is much better than using a modified or a third part executable.

Is it possible for anyone on this group to help set the right paths (as it is quite possible that most of them might not be set) and suggest the right commands to first test building code with command-line commands and then using GoClipse?

Test code that I gathered from various places (including from folders within C;\Go):

package main

// #cgo CFLAGS: -DPNG_DEBUG=1
// #cgo amd64 386 CFLAGS: -DX86=1
// #cgo LDFLAGS: -lpng
// #cgo pkg-config: png cairo

// cmpout -tags=use_go_run

// +build test_run

// #include <png.h>

// #include <stdio.h>
// #include <stdlib.h>

import "C"

import "unsafe"


import (
"fmt"
)

func Print(s string) {
	cs := C.CString(s)
	defer C.free(unsafe.Pointer(cs))
	C.fputs(cs, (*C.FILE)(C.stdout))
}

func main() {
	Print("RAJ")
	fmt.Println("Check")
}

func main1() {
	stdio.Stdout.WriteString(stdio.Greeting + "\n")
}

[andlabs]

cgo is not a C compiler; it uses your C compiler to turn C code into binary objects that are linked together with the binary objects that Go produces from your Go files. The C compiler is separate entirely.

[rxa1031]

@andlabs I am referring to book THE WAY TO GO - A Thorough Introduction to the Go Programming Language by Ivo Balbaert, copyright year 2012:

On page 43 following pints are mentioned:

Point 1:
C is not a package from the standard library, it is simply a special name interpreted by cgo as a reference to C's namespace. Within this namespace exists the C types denoted as C.unit, C.long, etc. and functions like C.random() from libc can be called.

Point 2:
The cgo program provides the mechanism for FFI-support (foreign function interface) to allow safe calling of C libraries from Go code: http://golang.org/cmd/go is primary cgo document..."
cgo replaces the normal Go-compilers, it outputs Go and C files that can be combined into a single Go package.

Observation
If I use MinGW any C.xxx type and functions are not recognized.

Also why would the book use the words:

special name interpreted by cgo

if it invokes gcc for compiling c code?

[rxa1031]

Test code to find various System Variable and other variable settings:

package main

// +build

import (
	"fmt"
	"runtime"
	"go/build"
	"strconv"
)

func main() {
	var cntxt = build.Default
	fmt.Println("GOROOT = "+runtime.GOROOT());
	fmt.Println("GOARCH = "+ runtime.GOARCH);
	fmt.Println("GOOS = "+ runtime.GOOS);
	fmt.Println("CgoEnabled = "+strconv.FormatBool(cntxt.CgoEnabled))
}

Observed output:

GOROOT = C:\Go\
GOARCH = amd64
GOOS = windows
CgoEnabled = true

[rxa1031]

When import for c and unsafe are not included reported compiler is
Compiler = gc

But with below import included:

// #include <png.h>
// #include <stdio.h>
// #include <stdlib.h>
import "C"
import "unsafe"

build is terminated with:

exec: "gcc": executable file not found in %PATH%
   ^^^ Terminated, exit code: 2 ^^^

[andlabs]

That book is either being misleading or flat out wrong (cgo does NOT replace the standard Go compilers). cgo interprets the names because cgo programs are syntactically valid Go programs that can be parsed with a Go parser; cgo just parses the program and changes every instance of C.xxxx into special symbols made by figuring out what the types of xxxx are. To figure those types out, it needs to invoke your normal C compiler. You also need the C compiler to build those temporary C files, and to do the final link.

Also Go already provides your test code as go env.

What errors do you get with MinGW installed? Is this vanilla MinGW or MinGW-w64? You'll need the latter.

[rxa1031]

Yes, I have installed the latest MinGW-w64.

I have added path for C:\mingw-w64\x86_64-8.1.0-win32-sjlj-rt_v6-rev0\mingw64\bin to System Variable PATH. I am not sure whether path to any other MinGW-x64 need to be added. Folder msys is not present inside any of the main or sub folders associated with MinGW-w64

On building code, I observe below output along with errors:

====================  Starting Go build  ====================
Cleared problem markers for RunTimeValues.
************  Building Go project: RunTimeValues  ************
  with GOPATH: C:\goPackagePath;C:\GoClipseWsp\RunTimeValues
>> Running: C:\Go\bin\go.exe install -v -gcflags "-N -l" ./...
code
# code
code\RunTimeVars.go:23:16: could not determine kind of name for C.FILE
code\RunTimeVars.go:23:2: could not determine kind of name for C.fputs
code\RunTimeVars.go:22:8: could not determine kind of name for C.free
code\RunTimeVars.go:23:24: could not determine kind of name for C.stdout
   ^^^ Terminated, exit code: 2 ^^^
************  Build terminated.  ************

Build code stated below for reference purpose:

package main

// +build

// #include <png.h>

// #include <stdio.h>
// #include <stdlib.h>

import "C"

import "unsafe"
import (
	"fmt"
	"runtime"
	"go/build"
	"strconv"
)

func Print(s string) {
	cs := C.CString(s)
	defer C.free(unsafe.Pointer(cs))
	C.fputs(cs, (*C.FILE)(C.stdout))
}


func main() {
	var cntxt = build.Default
	fmt.Println("GOROOT = "+runtime.GOROOT());
	fmt.Println("GOARCH = "+ runtime.GOARCH);
	fmt.Println("GOOS = "+ runtime.GOOS);
	fmt.Println("CgoEnabled = "+strconv.FormatBool(cntxt.CgoEnabled))
	fmt.Println("Compiler = "+cntxt.Compiler)
	
	Print("C function output");
}

I am not aware why the word "code" appears in build information instead of "main".

The src folder has folder with name code. Inside code folder file "RunTimeVard.go" exists, which has the shared code init.

I had accidentally built / compiled the empty project (i,e, when only "package code" existed inside the go file). I later changed "package code" to "package main" but I still observe the word "code" in Build output.

[rxa1031]

I am using GoClipse for building code.

[andlabs]

Oh, the newline between the #includes and import "C" means cgo isn't seeing the #includes at all. The import "C" has to be on the line immediately after the comment.

[andlabs]

Are there still issues?

[buzzersdad]

No.Thanks.

…

On Friday, January 4, 2019, Pietro Gagliardi ***@***.***> wrote: Are there still issues? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#245 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APvuYgk0k1VrpH6XNXCc0Fl5b-QMY_spks5u_45XgaJpZM4PmMR1> .