cmd/link: source paths in binary distribution assume installation to specific directory #5533
Comments
Why would I need to fiddle with gdb? I have GOROOT set when I build the executable. Shouldn't "go build" use GOROOT value and set all debug info accordingly? As far as I can see, it uses whatever values were set when package binaries were created. That is the purpose of GOROOT_FINAL. Isn't it? But it doesn't work very well in this situation. Perhaps, we could just make linker smarter and drop GOROOT_FINAL altogether. I suspect I miss something here. So help me please. Tank you. Alex |
I probably don't understand the problem. You seem to be saying that the Windows installer permits the user to select the directory where Go should be installed. If that directory is not /usr/local/go, then gdb is unable to find runtime-gdb.py, and it is unable to find the source code for the standard library. Is that an accurate description of the problem? |
What about my proposal to rewrite these path during build process? You suggested to use "pack -P" for that, but I don't think this will work. "pack -P" allows only single replacement, and "go" command uses it to replace $WORK path while it builds executables. Also, looking at the source code for "pack -P", I don't see that it can handle windows paths. I am surprised we didn't see any complains about that, but I logged an issue https://golang.org/issue/5550. What about making linker do the job? Alex |
rsc, There are 2 problems here: 1) when building binary windows distro, we have C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist357622851/go instead of c:\go written into all lib files - this is because GOROOT -> GOROOT_FINAL substitution logic does not work for windows paths in [568][acg]; 2) dwarf source paths cannot be used if windows binary distro is installed anywhere but c:\go - I reported it separately https://golang.org/issue/5533 Perhaps we should create a new issue for 1) and close this one. Or change this issue subject to 1). Pick what you like. Alex |
The binary distributions expect to be installed in /usr/local/go. We're very upfront about that. If they are installed elsewhere then things don't work as well. In particular, source line information is wrong for the compiled packages. I don't think we intend to change that. I just wrote godoc.org/code.google.com/p/rsc/cmd/editpcln that edits the pcln tables for Go 1.3 archives. You could use it to download a binary Go 1.3 distribution and replace /usr/local/go with a different prefix. Since we're just shipping tar files, I doubt we would include this in the Unix distributions, but perhaps it would make sense in the Windows distributions. (Or perhaps not.) If nothing else, something to keep in mind for Go 1.4. Labels changed: removed os-windows. |
I am fine with requiring to install into /usr/local/go. But then our Windows Install package shouldn't provide option to "install into directory of your choice". Because not everyone installs into c:\go, and when they install into different directory, things get out of place. gdb would be broken then. Alex |
rsc
changed the title
|
I have (presumably) the same problem on linux: i installed go in |
|
@kormat if you are building Go from source, it is recommended to build Go in it's final destination. If that is not possible you should set |
|
@davecheney - i'm just using the tarball directly from https://golang.org/dl/ |
|
@kormat in that case I appolgise, I have no workaround for the gdb issue. |
|
I prepared a CL to use $GOROOT for the location of the gdb script. That will help with finding the gdb script. The source line information for the standard library will still point at /usr/local/go but maybe that's not as big a deal. |
|
CL https://golang.org/cl/18200 mentions this issue. |
Here to demonstrate: $ mkdir ~/tmp $ cd ~/tmp $ zcat /tmp/go1.1.linux-386.tar.gz | tar x $ export GOROOT=~/tmp/go $ export PATH=$PATH:$GOROOT/bin/ $ mkdir a $ cd a $ cat >a.go package main import ( "fmt" ) func main() { fmt.Printf("Hello\n") } $ go build a.go $ gdb a GNU gdb (Gentoo 7.3.1 p2) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>; This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.gentoo.org/>;... Reading symbols from /home/brainman/tmp/a/a...done. warning: /usr/local/go/src/pkg/runtime/runtime-gdb.py (referenced in .debug_gdb_scripts): No such file or directory (gdb) br main.main Breakpoint 1 at 0x8048c00: file /home/brainman/tmp/a/a.go, line 5. (gdb) r Starting program: /home/brainman/tmp/a/a Breakpoint 1, main.main () at /home/brainman/tmp/a/a.go:5 5 func main() { (gdb) s 6 fmt.Printf("Hello\n") (gdb) fmt.Printf (format=..., a=..., n=405032960, err=...) at /usr/local/go/src/pkg/fmt/print.go:222 222 /usr/local/go/src/pkg/fmt/print.go: No such file or directory. in /usr/local/go/src/pkg/fmt/print.go (gdb) q A debugging session is active. Inferior 1 [process 17239] will be killed. Quit anyway? (y or n) y $ We could stress that only /usr/local/go destination is supported. But this does not work on windows, because our windows installer allows other path (then c:\go) to be specified. Perhaps we could change our linker, so it rewrites these paths correctly. AlexThe text was updated successfully, but these errors were encountered: