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

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

Comments

Projects
None yet
6 participants
@gopherbot

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

This comment has been minimized.

Show comment
Hide comment
@alexbrainman

alexbrainman Aug 26, 2013

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.

Member

alexbrainman commented Aug 26, 2013

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

This comment has been minimized.

Show comment
Hide comment
@alexbrainman

alexbrainman Aug 29, 2013

Member

Comment 2:

Issue #6274 has been merged into this issue.

Member

alexbrainman commented Aug 29, 2013

Comment 2:

Issue #6274 has been merged into this issue.

@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Sep 1, 2013

Comment 3 by emilliken:

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

Comment 3 by emilliken:

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

This comment has been minimized.

Show comment
Hide comment
@alexbrainman

alexbrainman Sep 12, 2013

Member

Comment 4:

Issue #6371 has been merged into this issue.

Member

alexbrainman commented Sep 12, 2013

Comment 4:

Issue #6371 has been merged into this issue.

@minux

This comment has been minimized.

Show comment
Hide comment
@minux

minux Sep 12, 2013

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Sep 12, 2013

Comment 6 by lubos.pintes:

I would vote for removing as many bloat as possible.
Dňa 12. 9. 2013 5:44 go@googlecode.com wrote / napísal(a):

Comment 6 by lubos.pintes:

I would vote for removing as many bloat as possible.
Dňa 12. 9. 2013 5:44 go@googlecode.com wrote / napísal(a):
@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Sep 12, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@josharian

josharian Sep 12, 2013

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.
Contributor

josharian commented Sep 12, 2013

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

This comment has been minimized.

Show comment
Hide comment
@niemeyer

niemeyer Sep 17, 2013

Contributor

Comment 9:

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

niemeyer commented Sep 17, 2013

Comment 9:

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

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Sep 17, 2013

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.
Contributor

davecheney commented Sep 17, 2013

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

This comment has been minimized.

Show comment
Hide comment
@alexbrainman

alexbrainman Sep 17, 2013

Member

Comment 11:

Issue #6411 has been merged into this issue.

Member

alexbrainman commented Sep 17, 2013

Comment 11:

Issue #6411 has been merged into this issue.

@minux

This comment has been minimized.

Show comment
Hide comment
@minux

minux Sep 20, 2013

Member

Comment 12:

This issue was closed by revision 0d85d54.

Status changed to Fixed.

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.