I made a Go fyne project, which works fine with go run ., and builds to Linux as expected with go build ..
However, when I try cross-compiling to windows using env GOOS=windows GOARCH=arm64 go build . it prints this error:
go: downloading github.com/tevino/abool v1.2.0
package playground.com/colors
imports fyne.io/fyne/v2/app
imports fyne.io/fyne/v2/internal/driver/glfw
imports fyne.io/fyne/v2/internal/driver/common
imports fyne.io/fyne/v2/internal/painter/gl
imports github.com/go-gl/gl/v3.1/gles2: build constraints exclude all Go files in /home/mohamed/code/go/pkg/mod/github.com/go-gl/gl#v0.0.0-20211210172815-726fda9656d6/v3.1/gles2
I tried a clean install of Go, tried using go clean -modcache, tried creating a separate new module.
The code for error replication:
package main
import (
"fmt"
"image/color"
"fyne.io/fyne/v2"
"fyne.io/fyne/v2/app"
"fyne.io/fyne/v2/canvas"
"fyne.io/fyne/v2/container"
"fyne.io/fyne/v2/widget"
)
func main() {
app := app.NewWithID("Color Mixer")
window := app.NewWindow("Color")
red := widget.NewSlider(0, 255)
green := widget.NewSlider(0, 255)
blue := widget.NewSlider(0, 255)
red_value := widget.NewLabel("0")
green_value := widget.NewLabel("0")
blue_value := widget.NewLabel("0")
red_label := widget.NewLabel("Red")
green_label := widget.NewLabel("Green")
blue_label := widget.NewLabel("Blue")
colorx := color.NRGBA{R: 0, G: 0, B: 0, A: 255}
rect := canvas.NewRectangle(colorx)
rect.SetMinSize(fyne.NewSize(300, 300))
red.OnChanged =
func(f float64) {
_, g, b, a := rect.FillColor.RGBA()
rect.FillColor = color.NRGBA{R: uint8(f),
G: uint8(g),
B: uint8(b),
A: uint8(a)}
rect.Refresh()
red_value.SetText(fmt.Sprintf("%.0f", f))
}
green.OnChanged =
func(f float64) {
r, _, b, a := rect.FillColor.RGBA()
rect.FillColor = color.NRGBA{R: uint8(r),
G: uint8(f),
B: uint8(b),
A: uint8(a)}
rect.Refresh()
green_value.SetText(fmt.Sprintf("%.0f", f))
}
blue.OnChanged =
func(f float64) {
r, g, _, a := rect.FillColor.RGBA()
rect.FillColor = color.NRGBA{R: uint8(r),
G: uint8(g),
B: uint8(f),
A: uint8(a)}
rect.Refresh()
blue_value.SetText(fmt.Sprintf("%.0f", f))
}
box := container.NewGridWithRows(
2,
container.NewGridWithRows(3, red_label, green_label, blue_label, red, green, blue, red_value, green_value, blue_value),
rect)
window.SetContent(box)
window.ShowAndRun()
}
IIRC, cross-compilation by default disables cgo, and since all the files in that github.com/go-gl/gl/v3.1/gles2 package make use of it, the building process naturally excludes them all, and produces the error you're seeing.
Hence try building while having CGO_ENABLED=1 in your environment.
A simple
CGO_ENABLED=1 GOOS=windows go build
should do the trick.
Note that in order for the build process to actually produce the expected outcome you need to have the C cross-compiler for your target GOOS/GOARCH combo installed, and probably communicated to the go tool via setting the CC environment variable—see the docs.
For instance, on Debian and its derivatives you will probably need to have the following packages installed:
gcc-mingw-w64-x86-64-win32 — for building for windows/amd64.
gcc-mingw-w64-i686-win32 — for building for windows/386.
The values to set the CC variable will be /usr/bin/i686-w64-mingw32-gcc and /usr/bin/x86_64-w64-mingw32-gcc, correspondingly.
I have no idea whether there's a MinGW cross-compiler package to target windows/arm64 which you seem to require, though, as I have zero experience with Windows on ARM devices.
Also note that in order to produce a sensible Windows executable image file while cross-compiling you will probably want to also have CGO_LDFLAGS=-static-libgcc in your environment as well—this will produce a binary not dependent on libgcc.dll, and maybe you will even want to have CGO_LDFLAGS=-static-libgcc -static to have a fully-static build.
The previous answer is correct. However you may like to use the “fyne package” command or fyne-cross - these tools aim to avoid all the manual setup.
Related
I've tried many times to set up a REAL go package with the modules system and store code in pkg. All the tutorials I've found are too basic, creating a module with go files stores at the top level, and I keep getting no Go files in /usr/local/go/github.com/me/mypackage.
I've tried a bunch of different things, but I can't get it to work properly...
GOROOT is set to /usr/local/go. I created a package here /usr/local/go/github.com/me/mypackage.
go.mod
module github.com/me/mypackage
go 1.18
pkg/main.go
package mypackage
// Add is our function that sums two integers
func Add(x, y int) (res int) {
return x + y
}
// Subtract subtracts two integers
func Subtract(x, y int) (res int) {
return x - y
}
pkg/main_test.go
package mypackage
import "testing"
func TestAdd(t *testing.T){
got := Add(4, 6)
want := 10
if got != want {
t.Errorf("got %q, wanted %q", got, want)
}
}
And I run: go test
What am I doing wrong? I find Go so frustrating to set up because languages/runtimes like Rust and NodeJS have very friendly package managers and are real easy to setup.
I'm trying to structure a library as described in this guidance for structuring go packages.
Don't confuse modules with packages.
One module might hold many packages.
Like this:
module_dir/package1_dir
module_dir/package2_dir
Try this layout:
Repository: github.com/me/mymodule
mymodule/mypkg
mymodule/mypkg/mypkg_test.go
mymodule/mypkg/mypkg.go
mymodule/go.mod
In mypkg.go and mypkg_test.go declare package mypkg.
Otherwise, run this script and it will create a correct layout for you:
https://gist.github.com/udhos/695d3be51fb4c7d151b4e252cdec3c63
I am attempting to create named loggers automatically for HTTP handlers that I'm writing, where I am passed a function (pointer).
I'm using the code mentioned in this question to get the name of a function:
package utils
import (
"reflect"
"runtime"
)
func GetFunctionName(fn interface{}) string {
value := reflect.ValueOf(fn)
ptr := value.Pointer()
ffp := runtime.FuncForPC(ptr)
return ffp.Name()
}
I'm using this in my main function to try it out like so:
package main
import (
"github.com/naftulikay/golang-webapp/experiments/functionname/long"
"github.com/naftulikay/golang-webapp/experiments/functionname/long/nested/path"
"github.com/naftulikay/golang-webapp/experiments/functionname/utils"
"log"
)
type Empty struct{}
func main() {
a := long.HandlerA
b := path.HandlerB
c := path.HandlerC
log.Printf("long.HandlerA: %s", utils.GetFunctionName(a))
log.Printf("long.nested.path.HandlerB: %s", utils.GetFunctionName(b))
log.Printf("long.nested.path.HandlerC: %s", utils.GetFunctionName(c))
}
I see output like this:
github.com/naftulikay/golang-webapp/experiments/functionname/long.HandlerA
This is okay but I'd like an output such as long.HandlerA, long.nested.path.HandlerB, etc.
If I could get the Go module name (github.com/naftulikay/golang-webapp/experiments/functionname), I can then use strings.Replace to remove the module name to arrive at long/nested/path.HandlerB, then strings.Replace to replace / with . to finally get to my desired value, which is long.nested.path.HandlerB.
The first question is: can I do better than runtime.FuncForPC(reflect.ValueOf(fn).Pointer()) for getting the qualified path to a function?
If the answer is no, is there a way to get the current Go module name using runtime or reflect so that I can transform the output of runtime.FuncForPC into what I need?
Once again, I'm getting values like:
github.com/naftulikay/golang-webapp/experiments/functionname/long.HandlerA
github.com/naftulikay/golang-webapp/experiments/functionname/long/nested/path.HandlerB
github.com/naftulikay/golang-webapp/experiments/functionname/long/nested/path.HandlerC
And I'd like to get values like:
long.HandlerA
long.nested.path.HandlerB
long.nested.path.HandlerC
EDIT: It appears that Go does not have a runtime representation of modules, and that's okay, if I can do it at compile time that would be fine too. I've seen the codegen documentation and I'm having a hard time figuring out how to write my own custom codegen that can be used from go generate.
The module info is included in the executable binary, and can be acquired using the debug.ReadBuildInfo() function (the only requirement is that the executable must be built using module support, but this is the default in the current version, and likely the only in future versions).
BuildInfo.Path is the current module's path.
Let's say you have the following go.mod file:
module example.com/foo
Example reading the build info:
bi, ok := debug.ReadBuildInfo()
if !ok {
log.Printf("Failed to read build info")
return
}
fmt.Println(bi.Main.Path)
// or
fmt.Println(bi.Path)
This will output (try it on the Go Playground):
example.com/foo
example.com/foo
See related: Golang - How to display modules version from inside of code
If your goal is to just have the name of the module available in your program, and if you are okay with setting this value at link time, then you may use the -ldflags build option.
You can get the name of the module with go list -m from within the module directory.
You can place everything in a Makefile or in a shell script:
MOD_NAME=$(go list -m)
go build -ldflags="-X 'main.MODNAME=$MOD_NAME'" -o main ./...
With main.go looking like:
package main
import "fmt"
var MODNAME string
func main() {
fmt.Println(MODNAME) // example.com
}
With the mentioned "golang.org/x/mod/modfile" package, an example might look like:
package main
import (
"fmt"
"golang.org/x/mod/modfile"
_ "embed"
)
//go:embed go.mod
var gomod []byte
func main() {
f, err := modfile.Parse("go.mod", gomod, nil)
if err != nil {
panic(err)
}
fmt.Println(f.Module.Mod.Path) // example.com
}
However embedding the entire go.mod file in your use case seems overkill. Of course you could also open the file at runtime, but that means you have to deploy go.mod along with your executable. Setting the module name with -ldflags is more straightforward IMO.
Is there an idiomatic way to read a file from the system starting from a (file scheme) url and not a path?
I tried this first:
fileUrlStr := "file:///path/to/file.json"
jsonBuffer, _ := ioutil.ReadFile(fileUrlStr)
This is my current (mostly working version) but I'm concerned there are some gotchas that I'm missing, so I'm hoping there's a more tried and true way to do it:
fileUrlStr := "file:///path/to/file.json"
fileUrl, _ := url.Parse(fileUrlStr)
jsonBuffer, _ := ioutil.ReadFile(fileUrl.Path)
(Bonus if I can support both file:///Users/jdoe/temp.json and file:///c:/WINDOWS/clock.json without having to add code-paths accounting for them)
Using net/url, the solution that you were using, is the correct one.
It's properly deals with hostnames and paths across platforms and also gives you a chance to check the url scheme is the file scheme.
package main
import (
"fmt"
"net/url"
)
func main() {
for _, path := range []string{
"file:///path/to/file.json",
"file:///c:/WINDOWS/clock.json",
"file://localhost/path/to/file.json",
"file://localhost/c:/WINDOWS/clock.avi",
// A case that you probably don't need to handle given the rarity,
// but is a known legacy win32 issue when translating \\remotehost\share\dir\file.txt
"file:////remotehost/share/dir/file.txt",
} {
u, _ := url.ParseRequestURI(path)
fmt.Printf("url:%v\nscheme:%v host:%v Path:%v\n\n", u, u.Scheme, u.Host, u.Path)
}
}
I have two files within one package named db, one of which has a few unexported variables defined. Another one is a test file and would need to use these variables like so:
(This is the structure of the project)
$GOPATH/src/gitlab.com/myname/projectdir
├── main.go
└── db
├── add.go
└── add_test.go
(Here is a terse variation of the files)
db/add.go
package db
func Add(x, y int) int {
return x + y
}
// some other functions that use a and b from `add_test.go`
db/add_test.go
package db
import (
"testing"
)
var (
a = 1
b = 2
)
// test function use variables from add.go
func testAdd(t *testing.T) {
result := add(a, b)
if result != 3 {
t.Error(err)
}
}
Running go test within db/ directory passed, but once I ran go run main go it produced the following error:
db/add.go:: undefined: a
db/add.go:: undefined: b
Seems like add.go cannot find a and b from add_test.go during the build.
main.go
package main
import (
"fmt"
"gitlab.com/myname/projectdir/db"
)
func main() {
res := db.Add(1, 2)
fmt.Println(res)
}
Is this because add_test.go is not included during the build?
This is just the way how go tool works.
_test.go files are compiled only when you run go test. When a package is imported from another package any code from its _test.go files is not used.
Try running go build or go install from inside db package. It will fail.
Relative paths are touchy in Go. For one, I think you need to prefix them with import "./db". Another thing is that you should be in your $GOPATH/src location.
Try this:
move your files under the $GOPATH/src/project and $GOPATH/src/project/db directories.
prefix your import path with ./db for the DB package.
As for the IDE, that's all up to whatever plugins you are using. Try running the tools yourself: golint, go vet, oracle, etc to see the actual go warnings and errors.
Test functions should start with Test. that is what the documentation says.
func TestAdd(t *testing.T) {
result := Add(a, b)
if result != 3 {
t.Errorf("expected 3, got %d ", result)
}
}
Cheers.
Is there is a cross-platform way to capture the screen in Google's Go? Or any way for that matter, but cross platform would be preferred.
Now there is:
https://github.com/vova616/screenshot
go get github.com/vova616/screenshot
Example:
package main
import "github.com/vova616/screenshot"
func main() {
img, err := screenshot.CaptureScreen() // *image.RGBA
myImg := image.Image(img) // can cast to image.Image, but not necessary
}
If you need macOS support as well (until the pull request is merged), get:
https://github.com/kesarion/screenshot
Unfortunately, there is no library to do this. There are a couple of bindings for magickwand (C programming language and the ImageMagick image processing libraries), see http://go-lang.cat-v.org/library-bindings but these are incomplete and do not have the screen capture feature.
Meanwhile as GeertJohan suggested, you can use os.exec to run an external program and capture the screen (see sample code below). For example, you can use import command from imagemagick to capture screen (should work on a platform that can run imagemagick)
package main
import (
"bytes"
"fmt"
"log"
"os/exec"
)
func main() {
var buf bytes.Buffer
path, err := exec.LookPath("import")
if err != nil {
log.Fatal("import not installed !")
}
fmt.Printf("import is available at %s\n", path)
cmd := exec.Command("import", "-window", "root", "root.png")
cmd.Stdout = &buf
cmd.Stderr = &buf
err = cmd.Run()
if err != nil {
panic(err)
}
fmt.Println(buf.String())
}
I don't know of any cross-platform library, but you can do this with the xgbutil library when an X server is present. You can see an example of how to capture a screenshot here.
If you wanted to get this working on Mac/Windows systems, I'd probably start by examining the source for go.wde, which includes backends for Windows and Mac. I doubt you'll directly find code to capture a screenshot in there, but it might give you some hints or a path to follow.
There is no cross-platform way to capture the screen in Google's Go, because capturing screen relies on a specific API of underlying operating systems. But there are libraries for Go that do this.
For example https://github.com/vova616/screenshot
This library seems to meet your needs:
https://godoc.org/github.com/kbinani/screenshot
captures screen-shot image as image.RGBA. Mac, Windows, Linux, FreeBSD, OpenBSD, NetBSD, and Solaris are supported.
func Capture(x, y, width, height int) (*image.RGBA, error)
func CaptureDisplay(displayIndex int) (*image.RGBA, error)
func CaptureRect(rect image.Rectangle) (*image.RGBA, error)
func GetDisplayBounds(displayIndex int) image.Rectangle
func NumActiveDisplays() int
I cannot find a library to do this. Stable cross-platform screen-capturing requires a lot of work. Screen capturing requires interfacing with the operating systems' display manager/server or frame-buffer, which is different for a lot of operating systems and Linux distributions. You would have to write interfaces for each OS API (or wrap the libraries that provide the functionality), and then abstract all the different methods in a single package so it works cross-platform.
Another way to do this would be to run a existing screen capture application (command-line) to do the screen-capture work for you, including saving to a file. Then read the file in your go application. To make a Go application run a third-party application, use the os/exec package, it is in the standard library. For Linux you might use fbgrab to save the frame-buffer to a png file.
It is. It's a 2-step process:
Study https://github.com/ShareX/ShareX/tree/master/ShareX.ScreenCaptureLib to see which win32 API calls to make to capture the screen/window
Translate that logic to Go. You can use one of few existing win32 api Go bindings (e.g. https://github.com/AllenDang/w32). If they're missing needed functionality, you can add more wrappers.
For a native Windows solution, there is an example in C from the official Windows docs:
https://learn.microsoft.com/en-gb/windows/win32/gdi/capturing-an-image
Now, from this example, this is the code using Windigo library:
package main
import (
"runtime"
"unsafe"
"github.com/rodrigocfd/windigo/win"
"github.com/rodrigocfd/windigo/win/co"
)
func main() {
runtime.LockOSThread()
cxScreen := win.GetSystemMetrics(co.SM_CXSCREEN)
cyScreen := win.GetSystemMetrics(co.SM_CYSCREEN)
hdcScreen := win.HWND(0).GetDC()
defer win.HWND(0).ReleaseDC(hdcScreen)
hBmp := hdcScreen.CreateCompatibleBitmap(cxScreen, cyScreen)
defer hBmp.DeleteObject()
hdcMem := hdcScreen.CreateCompatibleDC()
defer hdcMem.DeleteDC()
hBmpOld := hdcMem.SelectObjectBitmap(hBmp)
defer hdcMem.SelectObjectBitmap(hBmpOld)
hdcMem.BitBlt(
win.POINT{X: 0, Y: 0},
win.SIZE{Cx: cxScreen, Cy: cyScreen},
hdcScreen,
win.POINT{X: 0, Y: 0},
co.ROP_SRCCOPY,
)
bi := win.BITMAPINFO{
BmiHeader: win.BITMAPINFOHEADER{
BiWidth: cxScreen,
BiHeight: cyScreen,
BiPlanes: 1,
BiBitCount: 32,
BiCompression: co.BI_RGB,
},
}
bi.BmiHeader.SetBiSize()
bmpObj := win.BITMAP{}
hBmp.GetObject(&bmpObj)
bmpSize := bmpObj.CalcBitmapSize(bi.BmiHeader.BiBitCount)
rawMem := win.GlobalAlloc(co.GMEM_FIXED|co.GMEM_ZEROINIT, bmpSize)
defer rawMem.GlobalFree()
bmpSlice := rawMem.GlobalLock(int(bmpSize))
defer rawMem.GlobalUnlock()
hdcScreen.GetDIBits(hBmp, 0, int(cyScreen), bmpSlice, &bi, co.DIB_RGB_COLORS)
bfh := win.BITMAPFILEHEADER{}
bfh.SetBfType()
bfh.SetBfOffBits(uint32(unsafe.Sizeof(bfh) + unsafe.Sizeof(bi.BmiHeader)))
bfh.SetBfSize(bfh.BfOffBits() + uint32(bmpSize))
fo, _ := win.FileOpen("C:\\users\\rodrigo\\desktop\\a.bmp", co.FILE_OPEN_RW_OPEN_OR_CREATE)
defer fo.Close()
fo.Write(bfh.Serialize())
fo.Write(bi.BmiHeader.Serialize())
fo.Write(bmpSlice)
println("Done")
}