buildmode plugin issue of package not found

[cytown]

The files as follows:

go.mod

module test.com/plugin

go 1.14

dll/dll.go

package dll

import (
	"fmt"
)

type DllInfo struct {
	Name string `json:"name"`
	Id   int32  `json:"id"`
}

func TestDll(name string, id int32) {
	fmt.Printf("check : %v\n", &DllInfo{name, id})
}

main.go

package main

import (
	"test.com/plugin/dll"
)

var TestDll = dll.TestDll

func main() {
	TestDll("asdasfas %v", 111)
}

Then run command:

garble build -buildmode=plugin -o dll.so main.go

Get the errors:

# command-line-arguments
main.go:7:15: undefined: dll.TestDll
exit status 2
exit status 2

It really weird... Seems can not find the package.

[cytown]

@mvdan Another strange issue was:
When I run command:

go build -buildmode=plugin -o dll.so main.go

# command-line-arguments
main.go:7:15: undefined: dll.TestDll

it will run garble as well, just like I run garble directly, but it's way faster...

Yes it didn't have:

exit status 2
exit status 2

But in another clean machine without garble installed, it looks fine without any issue.

[mvdan]

I cannot reproduce this at all:

$ go version
go version go1.14.3 linux/amd64
$ cat go.mod
module test.com/plugin

go 1.14
$ cat main.go 
package main

import (
	"test.com/plugin/dll"
)

var TestDll = dll.TestDll

func main() {
	TestDll("asdasfas %v", 111)
}
$ cat dll/dll.go 
package dll

import (
	"fmt"
)

type DllInfo struct {
	Name string `json:"name"`
	Id   int32  `json:"id"`
}

func TestDll(name string, id int32) {
	fmt.Printf("check : %v\n", &DllInfo{name, id})
}
$ garble build -buildmode=plugin -o dll.so main.go

[cytown]

Confirm again in LInux. Before was in MacOS.

p.s. garble version is retrieved from https://github.com/mvdan/garble and build with "go build .".

$ go version
go version go1.14.2 linux/amd64
$ garble build -buildmode=plugin -o dll.so main.go
# command-line-arguments
./main.go:8:15: undefined: dll.TestDll
exit status 2
exit status 2

[mvdan]

Maybe try giving me a script I can run inside a golang Docker image. Otherwise I'll have to spend hours trying to guess what's causing the failure for you.

[cytown]

@mvdan OK, I'll try.

[cytown]

Please unzip the attached file and then run:

docker run -v $PWD/gotest:/tmp/go --name golang -it golang bash
# cd /tmp/go
# cd garble/
# go build .
# cd ../a
# ../garble/garble build -buildmode=plugin -o dll.so main.go

gotest.zip

[cytown]

@mvdan how about the progress?

[mvdan]

This is an open source side project that I do for free on my spare time. If you want me to work faster, consider becoming a sponsor.

[cytown]

Can you reproduce the issue now? I just wonder whether my info is enough.

[mvdan]

I haven't tried yet.

[cytown]

Got it, if need any further informations, please let me know.

[mvdan]

OK, I was able to repro like so:

docker run -it golang:1.14.3 <<-SCRIPT

        set -ex

        apt update && apt install unzip

        wget https://github.com/mvdan/garble/files/4649834/gotest.zip
        unzip gotest.zip

        GO111MODULE=on go get mvdan.cc/garble@v0.0.0-20200518174757-3c97725ccc06

        cd gotest/a
        garble build -buildmode=plugin -o dll.so main.go

SCRIPT

This seems to be an error on your part; when you build a package, you should specify a package path, not a file. The first command works, but yours does not:

root@14603a165251:/go/gotest/a# garble build -buildmode=plugin -o dll.so
root@14603a165251:/go/gotest/a# garble build -buildmode=plugin -o dll.so main.go
# command-line-arguments
./main.go:8:15: undefined: dll.TestDll
exit status 2
exit status 2

[mvdan]

It's not clear why garble build -buildmode=plugin -o dll.so main.go works on my machine outside Docker. In any case, you should not rely on building lone Go files to work when they import other packages from modules, or when other Go files are involved in the build.

[mvdan]

OK, I can finally reproduce this without Docker. I still think you should be building the entire package instead of a single file, but there's still a weird bug at play here that we should fix.

[mvdan]

Also, the reason I wasn't reproducing this on my laptop is because I had already set GOPRIVATE for a different project, and wasn't actually obfuscating anything. My bad. I've filed #20 for that.

[cytown]

Hmm, yes, it's fine to build without specified main.go. But if there are more than one main.go in this package sub-directory the build should be wrong or mixed, so in common we should name the main entry here. Also the pure go will support this kind of build without any problem.

Anyway, it works in your way, thank you.

[cytown]

Looks garble won't obfuscate imported 3rd party packages, or just some misconfiguration?

[mvdan]

https://github.com/mvdan/garble#options

[cytown]

In my test, garble don't obfuscate the sub dir name of package, in above case, "dll" would remain the original name, but the func name and struct name have been obfuscated. Should the sub dir name be obfuscated as well?

[mvdan]

https://github.com/mvdan/garble/issues/13

[cytown]

Looks garble won't obfuscate imported 3rd party packages, or just some misconfiguration?

Thanks, this question explained.

In my test, garble don't obfuscate the sub dir name of package, in above case, "dll" would remain the original name, but the func name and struct name have been obfuscated. Should the sub dir name be obfuscated as well?

But I don't understand why the sub-dir of GOPRIVATE package remain same?

[mvdan]

That's https://github.com/mvdan/garble/issues/13. Package paths are not obfuscated yet.

[cytown]

That's #13. Package paths are not obfuscated yet.

So it's a pending implementation, right?

[mvdan]

Yes, that's why the issue is still open.