Under Linux, when using soft links in gopath scenarios, compilation and debugging cannot be performed normally.

[MainPoser]

What version of Go, VS Code & VS Code Go extension are you using?

Version Information

• Run go version to get version of Go from the VS Code integrated terminal.
  • go version go1.21.5 linux/amd64
• Run gopls -v version to get version of Gopls from the VS Code integrated terminal.
  • golang.org/x/tools/gopls (0.15.1)
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.
  • 1.87.0
  • 019f4d1419fbc8219a181fab78923bccf7ee29a2
  • x64
• Check your installed extensions to get the version of the VS Code Go extension
  • 0.41.1
• Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > Go: Locate Configured Go Tools command.
  • >

Share the Go related settings you have added/edited

Run Preferences: Open Settings (JSON) command to open your settings.json file.
Share all the settings with the go. or ["go"] or gopls prefixes.

settings.json

launch.json

Describe the bug

After soft-linking projects in other directories to gopath and starting debugging, compilation fails and dependent packages cannot be found when an error is reported.
The gopath mode is used, and the dependent packages are placed in the vendor directory under the parent directory of the soft link directory.

It is expected that compilation and debugging can be performed normally in the directory after soft connection. Instead of the real directory corresponding to the soft link

Steps to reproduce the behavior:

1. I save the project under /home/user/document/project/core,
2. Create gopath path /home/user/go
3. Soft link the project to /home/user/go/src/xxxx.com/mcp/platform
4. First create a vendor and place dependencies in the /home/user/go/src/xxxx.com/mcp directory
5. When I started debugging, I found that the dlv program was compiled in /home/user/document/project/core, and then in /home/user/document/project/core and all its parent directories, gopath, and goroot. Dependency package not found.

Screenshots or recordings

If applicable, add screenshots or recordings to help explain your problem.

[MainPoser]

What I expected was to recursively search for dependencies under the vendor in the path of the program I specified, but I mistakenly searched for dependencies in the real directory corresponding to the program path, resulting in the failure to find the corresponding dependencies.

I tried reading the source code of the plugin and found a problem at extension/src/goDebugConfiguration.ts:495.
Here it is forced to pass . to the dlv program. As a result, the dlv is not compiled and debugged based on the program parameters configured in launch.json. I manually changed . to the value of the original passed-in program variable, and I can compile and debug normally, but I don’t know if this modification is appropriate.

I don't understand why the passed in program value is not used here, but "." is forced to be used.

[hyangah]

@MainPoser Can you build your binary from the program directory? (i.e. cd ; go build .)
The debugged binary is built from the directory of the program (dirname) using the "go build ." command. That is because in module mode (which is the default and used by most of Go and VS Code Go users), go build must run inside a module and running from the main package directory is the easiest way to ensure the command is running inside the package's module. Since GOPATH mode is not actively maintained, I am reluctant to adjust this any further at this moment. A workaround would be to configure a task that builds your program as you wish and then configure it as a pretask of the exec mode debugging launch configuration.

[MainPoser]

@hyangah okay, thank you. I know exactly what you want to express. For me, I directly modified this piece of code, not using ".", but using the passed in program. I think it is possible to set the compilation directory according to whether GOModule is turned on or not. This should be a way.

[findleyr]

@MainPoser am I understanding correctly that you want VS Code to detect that there's a symlink in GOPATH pointing to your project? Did you open the GOPATH directory itself? If not, I don't think VS Code Go is ever going to build in the heuristics you describe, to look for symlinks in GOPATH. As @hyangah said, GOPATH mode is not actively maintained.