Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/ld: A program cannot run when linker flag "-s" is used. #6245

Closed
gopherbot opened this issue Aug 25, 2013 · 12 comments
Closed

cmd/ld: A program cannot run when linker flag "-s" is used. #6245

gopherbot opened this issue Aug 25, 2013 · 12 comments

Comments

@gopherbot
Copy link
Contributor

by lubos.pintes:

When I build a program with -ldflags "-s", and then run it, the following
error is generated:
runtime: function symbol table header: 0x0x0 0x0x0
fatal error: invalid function symbol table

OSis Windows 7 64-bit, Go built from source as 32-bit application.
go version devel +bb2db1e233b2 Sun Aug 25 23:50:44 2013 +1000 windows/386

Also tried with several random previous builds.
@alexbrainman
Copy link
Member

Comment 1:

Same on linux. We need to either remove "-s" linker flag, or make runtime to handle "no
symbols" situation. I think the former.
Alex

Status changed to Accepted.

@alexbrainman
Copy link
Member

Comment 2:

Issue #6274 has been merged into this issue.

@gopherbot
Copy link
Contributor Author

Comment 3 by emilliken:

The -s linker flag is very useful for creating lean executables.  Please keep this
feature.

@alexbrainman
Copy link
Member

Comment 4:

Issue #6371 has been merged into this issue.

@minux
Copy link
Member

minux commented Sep 12, 2013

Comment 5:

yeah, perhaps the best solution is to remove the feature.
the runtime needs the symbols for precise stack GC (it needs stack walking), for example.
we can remove some info in the symbol table (for example, function name and
pc<->line
table?), but not the entire symbol table.

Labels changed: added priority-later, removed priority-triage.

@gopherbot
Copy link
Contributor Author

Comment 6 by lubos.pintes:

I would vote for removing as many bloat as possible.
Dňa 12. 9. 2013 5:44 [email protected] wrote / napísal(a):

@gopherbot
Copy link
Contributor Author

Comment 7 by Michael.Henke.42:

And I would like to be able to remove bloat I don't need in go produced executables.
I vote to keep the -s flag.

@josharian
Copy link
Contributor

Comment 8:

Being able to trim down executables is very valuable for me.
Regarding the immediate question of what to do with -s, how about something like:
(1) Make passing -s a noop right now
(2) Update the documentation for -s
(3) Add a basic test that fails when -s produces broken binaries, so that we get CI
watching over it
(4) Revisit safe ways to shrink binaries after 1.2
With a bit of steering in the right direction, I'd be happy to submit a CL for 1-3. At
the very least, the docs should get updated. Feedback requested.

@niemeyer
Copy link
Contributor

Comment 9:

Note that running "strip" on Go binaries hopefully still works (it should, unless there
are new bugs in the ELF definition).

@davecheney
Copy link
Contributor

Comment 10:

FWIW we (Canonical) had to disable stripping (dh_strip) when we build software on our
armhf builders because it does produce strangely broken binaries.

@alexbrainman
Copy link
Member

Comment 11:

Issue #6411 has been merged into this issue.

@minux
Copy link
Member

minux commented Sep 20, 2013

Comment 12:

This issue was closed by revision 0d85d54.

Status changed to Fixed.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants