Comment 1:

The -s option does work, in the sense that it removes the debug info read by gdb.
Stripping the file name information means that stack traces and functions like
runtime.Caller do not work, meaning that basic packages like log do not work.  Doing
that amounts to a way to silently break Go programs.  See issue #6245.
What is the actual problem you are trying to solve?  The pack program used to have an
option to remove prefixes from file names, but we may have lost that feature when we
added the -pack option to gc and rewrote the pack program in Go.  Would restoring that
feature fix your problem?

Labels changed: added repo-main, release-none.

Comment 2 by czapkofan:

Quoting the original poster's comments from the original thread:
> I ship my binary to users and I use the -s option to strip out information like the
full path of my build environment, the home directory, unix username etc. I'm still
using go 1.1 specifically for this reason. I feel being able to strip this information
is important to anyone who is distributing their binaries to other people.
https://groups.google.com/d/msg/golang-nuts/d-t_CfWFxhQ/F83J-Oyde-AJ
>> A workaround is just to build in a VM with generic username and home directory.
> It's not just the username and home directory. The path for different packages are
also inserted which may leak some of the project names and internal package names.
https://groups.google.com/d/msg/golang-nuts/d-t_CfWFxhQ/esLu0TIndYMJ

Comment 3:

If the actual problem is defined as "leaking project names and internal package names"
then I'm not particularly sympathetic.  If it were harmless, sure, but it is not.
I'm certainly open to compromise solutions that do not break runtime.Caller, which is
why I mentioned the old pack option.

Comment 4 by chetan.hs:

Thanks for updating this issue with my comments form the thread.
Yes, restoring the pack feature would solve my problem as long as it strips out $GOPATH
file prefixes. Leaking project/package names is not the biggest concern (although
preventing it is desirable).

Comment 5:

In Go 1.2 the P option to pack was documented as
    [P prefix]
    The new option 'P' causes pack to remove the given prefix
    from file names in the line number information in object files
    that are already stored in or added to the archive.

Labels changed: added release-go1.5, removed release-none.

Comment 6 by czapkofan:

Sorry if that's not on topic, but just wanted to comment, that with regards to "leaking
project/package names", a "solution" could be probably an external "source code mangler"
(probably utilizing the AST tools).

Comment 7 by chetan.hs:

How is this pack tool supposed to work? I was trying it in go v1.2.2 but couldn't figure
out how it works.
$ go version
go version go1.2.2 linux/amd64
$ go tool pack -P $GOPATH pkg/linux_amd64/foo.a
pack: bad option `-'
> with regards to "leaking project/package names", a "solution" could be probably an
external "source code mangler"
Thanks for the suggestion. I'll check if any such tools exist.

Comment 8:

The Go 1.2 pack program, unlike the Go 1.3 pack program, works like the Unix ar program.
 You need to write something like "go tool pack rP $GOPATH foo.a".

There is a -trimpath option to cmd/compile already. You just need to use it (go build -gcflags '-trimpath prefix' your-targets). It's documented in the output of go tool compile -help but not go doc compile. I'll fix the latter. If you have assembly in your packages you also need to pass -trimpath to the assembler, with -asflags.

There is no option in the linker: it's too late by then.

CL https://golang.org/cl/16918 mentions this issue.