[Bug 1182252] New: [binutils2.36] nuspell build failure
http://bugzilla.opensuse.org/show_bug.cgi?id=1182252 Bug ID: 1182252 Summary: [binutils2.36] nuspell build failure Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs@suse.de Reporter: martin.liska@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- The build fails here: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:C... with many failures like: [ 66s] due to unexpected exception with message: [ 66s] Unknown error -1 That seems to be related to libicuuc.so.67 library. When I copy the system libicuuc.so.67 into the chroot build root, tests are fine. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1182252 http://bugzilla.opensuse.org/show_bug.cgi?id=1182252#c1 Martin Li��ka <martin.liska@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS CC| |matz@suse.com, | |rguenther@suse.com Assignee|screening-team-bugs@suse.de |martin.liska@suse.com --- Comment #1 from Martin Li��ka <martin.liska@suse.com> --- So it's related to icu package where libicuuc.so.67 is built: $ g++ -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -DICU_DATA_DIR=\"/usr/share/icu/67.1/\" -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11 -flto=auto -shared -Wl,-Bsymbolic -Wl,-soname -Wl,libicuuc.so.67 -o ../lib/libicuuc.so.67.1 errorcode.o putil.o umath.o utypes.o uinvchar.o umutex.o ucln_cmn.o uinit.o uobject.o cmemory.o charstr.o cstr.o udata.o ucmndata.o udatamem.o umapfile.o udataswp.o utrie_swap.o ucol_swp.o utrace.o uhash.o uhash_us.o uenum.o ustrenum.o uvector.o ustack.o uvectr32.o uvectr64.o ucnv.o ucnv_bld.o ucnv_cnv.o ucnv_io.o ucnv_cb.o ucnv_err.o ucnvlat1.o ucnv_u7.o ucnv_u8.o ucnv_u16.o ucnv_u32.o ucnvscsu.o ucnvbocu.o ucnv_ext.o ucnvmbcs.o ucnv2022.o ucnvhz.o ucnv_lmb.o ucnvisci.o ucnvdisp.o ucnv_set.o ucnv_ct.o resource.o uresbund.o ures_cnv.o uresdata.o resbund.o resbund_cnv.o ucurr.o localebuilder.o localeprioritylist.o messagepattern.o ucat.o locmap.o uloc.o locid.o locutil.o locavailable.o locdispnames.o locdspnm.o loclikely.o locresdata.o lsr.o loclikelysubtags.o locdistance.o localematcher.o bytestream.o stringpiece.o bytesinkutil.o stringtriebuilder.o bytestriebuilder.o bytestrie.o bytestrieiterator.o ucharstrie.o ucharstriebuilder.o ucharstrieiterator.o dictionarydata.o edits.o appendable.o ustr_cnv.o unistr_cnv.o unistr.o unistr_case.o unistr_props.o utf_impl.o ustring.o ustrcase.o ucasemap.o ucasemap_titlecase_brkiter.o cstring.o ustrfmt.o ustrtrns.o ustr_wcs.o utext.o unistr_case_locale.o ustrcase_locale.o unistr_titlecase_brkiter.o ustr_titlecase_brkiter.o normalizer2impl.o normalizer2.o filterednormalizer2.o normlzr.o unorm.o unormcmp.o loadednormalizer2impl.o chariter.o schriter.o uchriter.o uiter.o patternprops.o uchar.o uprops.o ucase.o propname.o ubidi_props.o characterproperties.o ubidi.o ubidiwrt.o ubidiln.o ushape.o uscript.o uscript_props.o usc_impl.o unames.o utrie.o utrie2.o utrie2_builder.o ucptrie.o umutablecptrie.o bmpset.o unisetspan.o uset_props.o uniset_props.o uniset_closure.o uset.o uniset.o usetiter.o ruleiter.o caniter.o unifilt.o unifunct.o uarrsort.o brkiter.o ubrk.o brkeng.o dictbe.o filteredbrk.o rbbi.o rbbidata.o rbbinode.o rbbirb.o rbbiscan.o rbbisetb.o rbbistbl.o rbbitblb.o rbbi_cache.o serv.o servnotf.o servls.o servlk.o servlkf.o servrbf.o servslkf.o uidna.o usprep.o uts46.o punycode.o util.o util_props.o parsepos.o locbased.o cwchar.o wintz.o dtintrv.o ucnvsel.o propsvec.o ulist.o uloc_tag.o icudataver.o icuplug.o sharedobject.o simpleformatter.o unifiedcache.o uloc_keytype.o ubiditransform.o pluralmap.o static_unicode_sets.o restrace.o -L../lib -L../stubdata -licudata -lpthread -ldl -lm what makes a difference is that: $ readelf -d ../lib/libicuuc.so.67.1 Dynamic section at offset 0x1e6cc0 contains 34 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libicudata.so.67] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] while the same library from my TW looks like: readelf -d /usr/lib64/libicuuc.so.67.1 Dynamic section at offset 0x1e6ca0 contains 35 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libicudata.so.67] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] 0x000000000000000e (SONAME) Library soname: [libicuuc.so.67] So we miss for some reason dependency on libpthread.so.0. Note that "-lpthread" is present at the command line. @Michael, Richard: Can one --as-needed automagic happen here? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1182252 http://bugzilla.opensuse.org/show_bug.cgi?id=1182252#c2 --- Comment #2 from Martin Li��ka <martin.liska@suse.com> --- Two more observations: 1) -fno-lto preserves the 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 2) similarly for ld.gold So it's very likely another inconsistency of BFD when LTO is used :/ -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1182252 http://bugzilla.opensuse.org/show_bug.cgi?id=1182252#c10 --- Comment #10 from Martin Li��ka <martin.liska@suse.com> ---
Our comments crossed, sorry.
Never mind.
At least pthread_mutex_unlock is also defined in libc.so.
Ah, I see!
But __pthread_key_create is defined only in libpthread.so, so the linker should record libpthread.so.0 as dependency indeed and not doing so would be a bug.
Well, there might be not a usage of libpthread.so-specific symbol: objdump -d ../lib/libicuuc.so.67.1 | grep __pthread 6c5e6: 48 83 3d 7a b9 17 00 cmpq $0x0,0x17b97a(%rip) # 1e7f68 <__pthread_key_create> 6c600: 48 83 3d 60 b9 17 00 cmpq $0x0,0x17b960(%rip) # 1e7f68 <__pthread_key_create> 6c61a: 48 83 3d 46 b9 17 00 cmpq $0x0,0x17b946(%rip) # 1e7f68 <__pthread_key_create> 6c644: 48 83 3d 1c b9 17 00 cmpq $0x0,0x17b91c(%rip) # 1e7f68 <__pthread_key_create> 6c65e: 48 83 3d 02 b9 17 00 cmpq $0x0,0x17b902(%rip) # 1e7f68 <__pthread_key_create> 6c688: 48 83 3d d8 b8 17 00 cmpq $0x0,0x17b8d8(%rip) # 1e7f68 <__pthread_key_create> 6e75e: 48 83 3d 02 98 17 00 cmpq $0x0,0x179802(%rip) # 1e7f68 <__pthread_key_create> 6e8ab: 48 83 3d b5 96 17 00 cmpq $0x0,0x1796b5(%rip) # 1e7f68 <__pthread_key_create> 6e8f2: 48 83 3d 6e 96 17 00 cmpq $0x0,0x17966e(%rip) # 1e7f68 <__pthread_key_create> 6e96a: 48 83 3d f6 95 17 00 cmpq $0x0,0x1795f6(%rip) # 1e7f68 <__pthread_key_create> 6ea60: 48 8b 2d 01 95 17 00 mov 0x179501(%rip),%rbp # 1e7f68 <__pthread_key_create> 141dbe: 48 83 3d a2 61 0a 00 cmpq $0x0,0xa61a2(%rip) # 1e7f68 <__pthread_key_create> 141dde: 48 83 3d 82 61 0a 00 cmpq $0x0,0xa6182(%rip) # 1e7f68 <__pthread_key_create> 141e30: 48 83 3d 30 61 0a 00 cmpq $0x0,0xa6130(%rip) # 1e7f68 <__pthread_key_create> 141e54: 48 83 3d 0c 61 0a 00 cmpq $0x0,0xa610c(%rip) # 1e7f68 <__pthread_key_create> 1464f0: 48 83 3d 70 1a 0a 00 cmpq $0x0,0xa1a70(%rip) # 1e7f68 <__pthread_key_create> 146520: 48 83 3d 40 1a 0a 00 cmpq $0x0,0xa1a40(%rip) # 1e7f68 <__pthread_key_create> 146550: 48 83 3d 10 1a 0a 00 cmpq $0x0,0xa1a10(%rip) # 1e7f68 <__pthread_key_create> 14657d: 48 83 3d e3 19 0a 00 cmpq $0x0,0xa19e3(%rip) # 1e7f68 <__pthread_key_create> 146890: 48 83 3d d0 16 0a 00 cmpq $0x0,0xa16d0(%rip) # 1e7f68 <__pthread_key_create> 1468c6: 48 83 3d 9a 16 0a 00 cmpq $0x0,0xa169a(%rip) # 1e7f68 <__pthread_key_create> 14691d: 48 83 3d 43 16 0a 00 cmpq $0x0,0xa1643(%rip) # 1e7f68 <__pthread_key_create> 146947: 48 83 3d 19 16 0a 00 cmpq $0x0,0xa1619(%rip) # 1e7f68 <__pthread_key_create> 146c3a: 48 83 3d 26 13 0a 00 cmpq $0x0,0xa1326(%rip) # 1e7f68 <__pthread_key_create> 146c63: 48 83 3d fd 12 0a 00 cmpq $0x0,0xa12fd(%rip) # 1e7f68 <__pthread_key_create> 146d61: 48 83 3d ff 11 0a 00 cmpq $0x0,0xa11ff(%rip) # 1e7f68 <__pthread_key_create> 146dbf: 48 83 3d a1 11 0a 00 cmpq $0x0,0xa11a1(%rip) # 1e7f68 <__pthread_key_create> 146eaa: 48 83 3d b6 10 0a 00 cmpq $0x0,0xa10b6(%rip) # 1e7f68 <__pthread_key_create> 146f43: 48 83 3d 1d 10 0a 00 cmpq $0x0,0xa101d(%rip) # 1e7f68 <__pthread_key_create> -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1182252 http://bugzilla.opensuse.org/show_bug.cgi?id=1182252#c11 --- Comment #11 from Martin Li��ka <martin.liska@suse.com> ---
So I wonder why -pthread works around the problem, considering that for linking it should effectively be the same as -lpthread.
I would expect the same, but it differs that -pthread is kept in: COLLECT_GCC_OPTIONS='-O2' '-D' '_FORTIFY_SOURCE=2' '-fstack-protector-strong' '-funwind-tables' '-fasynchronous-unwind-tables' '-fstack-clash-protection' '-Werror=return-type' '-flto=auto' '-g' '-D' 'ICU_DATA_DIR="/usr/share/icu/67.1/"' '-Wextra' '-Wall' '-Wpedantic' '-Wpointer-arith' '-Wwrite-strings' '-Wno-long-long' '-std=c++11' '-flto=auto' '-shared' '-o' '../lib/libicuuc.so.67.1' '-L../lib' '-L../stubdata' '-pthread' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' and I see ld is executed with -plugin-opt=-pass-through=-lpthread But I'm not sure why it hurts. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1182252 http://bugzilla.opensuse.org/show_bug.cgi?id=1182252#c12 --- Comment #12 from Richard Biener <rguenther@suse.com> --- For sure in case the shared object dlopens plugins for example that use pthreads it's wrong to elide -lpthread. --as-needed is prone to breaking this kind of special links. Note that libpthread is actually a linker script: /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib64/libpthread.so.0 /usr/lib64/libpthread_nonshared.a ) so it should eventually be possible to elide --as-needed here in the script in some way? Or simply add SUSE_ASNEEDED=0 in the spec file (or drop this long-standing patch). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1182252 http://bugzilla.opensuse.org/show_bug.cgi?id=1182252#c13 --- Comment #13 from Martin Li��ka <martin.liska@suse.com> --- (In reply to Richard Biener from comment #12)
For sure in case the shared object dlopens plugins for example that use pthreads it's wrong to elide -lpthread. --as-needed is prone to breaking this kind of special links.
All right, I've made a submit request that does that.
Note that libpthread is actually a linker script:
/* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib64/libpthread.so.0 /usr/lib64/libpthread_nonshared.a )
so it should eventually be possible to elide --as-needed here in the script in some way?
Or simply add SUSE_ASNEEDED=0 in the spec file (or drop this long-standing patch).
Do you mean dropping the binutils-build-as-needed.diff patch completely? Btw. why did we start using it? What was the motivation, a smaller number of package dependencies? Looking at openSUSE:Factory, the number of packages that disable the feature is following: $ grep ASNEEDED * | wc -l 87 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1182252 http://bugzilla.opensuse.org/show_bug.cgi?id=1182252#c14 Jan Engelhardt <jengelh@inai.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jengelh@inai.de --- Comment #14 from Jan Engelhardt <jengelh@inai.de> --- One case is that `pkg-config xyz --libs` (or older xyz-config --libs) sometimes emit, due to xyz developer error/lazyness, extraneous -l options that should only be emitted when --static is in use. Another case is that xyz is a library with inline functions, which may warrant adding -l to .pc files at all times because you can't know whether or not a xyz-using source actually included the particular inline function. That would be two casess I can think of why openSUSE, and relatedly Debian, use --as-needed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1182252 http://bugzilla.opensuse.org/show_bug.cgi?id=1182252#c17 --- Comment #17 from Martin Li��ka <martin.liska@suse.com> --- I've just created an upstream issue for the case where GOLD and BFD behave differenly: https://sourceware.org/bugzilla/show_bug.cgi?id=27441 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1182252 http://bugzilla.opensuse.org/show_bug.cgi?id=1182252#c18 Martin Li��ka <martin.liska@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #18 from Martin Li��ka <martin.liska@suse.com> --- I tend to close this issue as upstream claims BFD behaves well. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1182252 http://bugzilla.opensuse.org/show_bug.cgi?id=1182252#c22 Martin Li��ka <martin.liska@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #22 from Martin Li��ka <martin.liska@suse.com> --- Fixed now. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com