This doesn't seem right. Setting dupok=1 means that when the linker sees two copies of ...
11 years, 8 months ago
(2013-07-12 04:33:04 UTC)
#4
This doesn't seem right. Setting dupok=1 means that when the linker sees two
copies of the symbol it will just throw one away. There should be two copies,
just treated distinctly.
The static-ness should cause "version" to be used in the lookup, so that the two
lookups use different versions and get different Sym* symbols.
On 2013/07/12 04:33:04, rsc wrote: > This doesn't seem right. Setting dupok=1 means that when ...
11 years, 8 months ago
(2013-07-12 06:05:28 UTC)
#5
On 2013/07/12 04:33:04, rsc wrote:
> This doesn't seem right. Setting dupok=1 means that when the linker sees two
> copies of the symbol it will just throw one away. There should be two copies,
> just treated distinctly.
i reused the dupok as the symbol in question will only appear as external
symbols,
thus our linker won't touch its content.
the version is only incremented for different object files, however, in the
current
cgo build procedure, all external object files are linked together by "gcc
-Wl,-r"
into one _all.o before sending to the linker, so statics with the same name
actually
end up in the same _all.o, so version won't help here.
as you can see in my test, i specifically tested that the linker doesn't drop
one of
the definitions.
> The static-ness should cause "version" to be used in the lookup, so that the
two
> lookups use different versions and get different Sym* symbols.
On 2013/07/12 06:05:28, minux wrote: > On 2013/07/12 04:33:04, rsc wrote: > > This doesn't ...
11 years, 8 months ago
(2013-07-16 06:03:56 UTC)
#6
On 2013/07/12 06:05:28, minux wrote:
> On 2013/07/12 04:33:04, rsc wrote:
> > This doesn't seem right. Setting dupok=1 means that when the linker sees two
> > copies of the symbol it will just throw one away. There should be two
copies,
> > just treated distinctly.
> i reused the dupok as the symbol in question will only appear as external
> symbols,
> thus our linker won't touch its content.
>
> the version is only incremented for different object files, however, in the
> current
> cgo build procedure, all external object files are linked together by "gcc
> -Wl,-r"
> into one _all.o before sending to the linker, so statics with the same name
> actually
> end up in the same _all.o, so version won't help here.
>
> as you can see in my test, i specifically tested that the linker doesn't drop
> one of
> the definitions.
> > The static-ness should cause "version" to be used in the lookup, so that the
> two
> > lookups use different versions and get different Sym* symbols.
After applied the patch I stopped to get duplicate symbol problems on the link
of a static library of mruby project. Now I'm getting runtime error on Mac OS .
This compilation and link is working fine with Ubuntu and Go 1.1.
SIGSEGV: segmentation violation
PC=0x1363d6
signal arrived during cgo execution
runtime.asmcgocall(0xfecc6, 0x6efad0, 0x100000000, 0xffffffffffffffff, 0x0, ...)
/Users/luisbebop/Documents/go/go/src/pkg/runtime/asm_amd64.s:515 +0x2d
fp=0x6efa70
runtime.cgocall(0xfecc6, 0x6efad0)
/Users/luisbebop/Documents/go/go/src/pkg/runtime/cgocall.c:166 +0x15b
fp=0x6efab8
_/Users/luisbebop/Documents/go/packages/src/github.com/luisbebop/gomruby._Cfunc_mrb_open(0x8)
_/Users/luisbebop/Documents/go/packages/src/github.com/luisbebop/gomruby/_obj/_cgo_defun.c:252
+0x31 fp=0x6efad0
_/Users/luisbebop/Documents/go/packages/src/github.com/luisbebop/gomruby.New(0x6efb90)
_/Users/luisbebop/Documents/go/packages/src/github.com/luisbebop/gomruby/_obj/_cgo_gotypes.go:387
+0x1e fp=0x6efb18
github.com/luisbebop/gomruby_test.(*F).SetUpTest(0xc21000a3a0, 0xc210013320)
/Users/luisbebop/Documents/go/packages/src/github.com/luisbebop/gomruby/gomruby_test.go:23
+0x1e fp=0x6efb40
----- stack segment boundary -----
Issue 10345046: code review 10345046: cmd/ld: handle duplicate static symbols in COFF files.
(Closed)
Created 11 years, 9 months ago by minux1
Modified 11 years, 6 months ago
Reviewers:
Base URL:
Comments: 0