[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #8 from Andrew Pinski --- Using -Wl,-E (or -Wl,--export-dynamic) fixes the problem. And here is why: If you use "dlopen" to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the program itself.
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 --- Comment #7 from Walt Karas --- I see this problem running in a Docker container on a MacBook. When I try it on the Mac (clang, Darwin kernel), the output is 2.
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 Richard Biener changed: What|Removed |Added Target||x86_64-*-linux --- Comment #6 from Richard Biener --- Which also means the version of the dynamic linker is interesting (glibcs version or alternatively the exact OS version).
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 --- Comment #5 from Alexander Monakov --- GCC is emitting static_local as @gnu_unique_object, so it should be unified by the Glibc dynamic linker. You can use 'nm -CD' to check its type after linking for the main executable and the library to make sure ld keeps it unique, and LD_DEBUG=all (see 'man ld.so') to see how it gets resolved at runtime.
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 --- Comment #4 from Walt Karas --- (conanrunenv) [root@d761696b8abf VagueDynLink]# cc -O2 -Wall -Wextra -pedantic -std=c++17 -fno-strict-aliasing -fwrapv -S main.cc (conanrunenv) [root@d761696b8abf VagueDynLink]# cat main.s .file "main.cc" .text .section .text._ZNSt11char_traitsIcE6lengthEPKc,"axG",@progbits,_ZNSt11char_traitsIcE6lengthEPKc,comdat .p2align 4,,15 .weak _ZNSt11char_traitsIcE6lengthEPKc .type _ZNSt11char_traitsIcE6lengthEPKc, @function _ZNSt11char_traitsIcE6lengthEPKc: .LFB419: .cfi_startproc jmp strlen .cfi_endproc .LFE419: .size _ZNSt11char_traitsIcE6lengthEPKc, .-_ZNSt11char_traitsIcE6lengthEPKc .section.rodata.str1.1,"aMS",@progbits,1 .LC0: .string "./lib.a" .LC1: .string "dlopen() failed: " .LC2: .string "lib" .LC3: .string "lib() not found\n" .LC4: .string "dlsym() fail: " .section.text.startup,"ax",@progbits .p2align 4,,15 .globl main .type main, @function main: .LFB1854: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movl$2, %esi movl$.LC0, %edi pushq %rbx .cfi_def_cfa_offset 24 .cfi_offset 3, -24 subq$24, %rsp .cfi_def_cfa_offset 48 calldlopen testq %rax, %rax je .L9 movl$.LC2, %esi movq%rax, %rdi movq%rax, %rbx calldlsym testq %rax, %rax je .L5 call*%rax leaq15(%rsp), %rbp .L6: movl_ZZ3foovE12static_local(%rip), %eax movl$_ZSt4cout, %edi leal1(%rax), %esi movl%esi, _ZZ3foovE12static_local(%rip) call_ZNSolsEi movq%rbp, %rsi movl$1, %edx movb$10, 15(%rsp) movq%rax, %rdi call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l movq%rbx, %rdi calldlclose addq$24, %rsp .cfi_remember_state .cfi_def_cfa_offset 24 xorl%eax, %eax popq%rbx .cfi_def_cfa_offset 16 popq%rbp .cfi_def_cfa_offset 8 ret .L5: .cfi_restore_state calldlerror movq%rax, %rbp testq %rax, %rax je .L10 movl$.LC4, %edi call_ZNSt11char_traitsIcE6lengthEPKc movl$.LC4, %esi movl$_ZSt4cout, %edi movq%rax, %rdx call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l movq%rbp, %rsi movl$_ZSt4cout, %edi leaq15(%rsp), %rbp call_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc movl$1, %edx movq%rbp, %rsi movb$10, 15(%rsp) movq%rax, %rdi call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l jmp .L6 .L10: movl$.LC3, %esi movl$_ZSt4cout, %edi leaq15(%rsp), %rbp call_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc jmp .L6 .L9: movl$.LC1, %edi call_ZNSt11char_traitsIcE6lengthEPKc movl$.LC1, %esi movl$_ZSt4cout, %edi movq%rax, %rdx call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l calldlerror movl$_ZSt4cout, %edi movq%rax, %rsi call_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc movl$1, %edx leaq15(%rsp), %rsi movb$10, 15(%rsp) movq%rax, %rdi call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l movl$1, %edi callexit .cfi_endproc .LFE1854: .size main, .-main .p2align 4,,15 .type _GLOBAL__sub_I_main, @function _GLOBAL__sub_I_main: .LFB2309: .cfi_startproc subq$8, %rsp .cfi_def_cfa_offset 16 movl$_ZStL8__ioinit, %edi call_ZNSt8ios_base4InitC1Ev movl$__dso_handle, %edx movl$_ZStL8__ioinit, %esi movl$_ZNSt8ios_base4InitD1Ev, %edi addq$8, %rsp .cfi_def_cfa_offset 8 jmp __cxa_atexit .cfi_endproc .LFE2309: .size _GLOBAL__sub_I_main, .-_GLOBAL__sub_I_main .section.init_array,"aw" .align 8 .quad _GLOBAL__sub_I_main .weak _ZZ3foovE12static_local .section .bss._ZZ3foovE12static_local,"awG",@nobits,_ZZ3foovE12static_local,comdat .align 4 .type _ZZ3foovE12static_local, @gnu_unique_object .size
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 --- Comment #3 from Walt Karas --- (conanrunenv) [root@d761696b8abf setup-work]# cc -v Using built-in specs. COLLECT_GCC=cc COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-8/root/usr --mandir=/opt/rh/devtoolset-8/root/usr/share/man --infodir=/opt/rh/devtoolset-8/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-8.3.1-20190311/obj-x86_64-redhat-linux/isl-install --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC)
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- Please show output of 'cc -v' and attach assembly for main.cc. Providing vague linkage semantics with dynamic linking is a tricky area, especially when dlopen is in play, moreso with RTLD_LOCAL as in this example. For example, if you wanted vague-linkage objects to be unified across multiple dlopen'ed libraries (each with RTLD_LOCAL), you'd need special support from the toolchain and the dynamic linker. At some point GNU toolchain invented a new special ELF symbol binding type, STB_GNU_UNIQUE, but it turned out to cause other issues. It can be disabled in the compiler with --disable-gnu-unique-object, in which case the outcome you show here is expected. I think on non-GNU systems you'll likely get "1" rather than "2".
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-11-19 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Do you think that 'foo' can be interposed? Your bug lacks some description.
