Subscribing doko, as I'm not sure if there's a subtle glibc bug here
(with the ordering of libraries in the libc.so linker script).

I can only reproduce this on trusty's toolchain in any case, so not
particularly important. And only on x86 (the compiler doesn't appear to
emit calls to stack_chk_fail_local on x86-64).

** Also affects: thunderbird (Ubuntu Trusty)
   Importance: Undecided
       Status: New

** Changed in: thunderbird (Ubuntu)
       Status: New => Invalid

** Changed in: thunderbird (Ubuntu Trusty)
       Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/1690445

Title:
  Link failure in trusty/i386

Status in thunderbird package in Ubuntu:
  Invalid
Status in thunderbird source package in Trusty:
  Fix Committed

Bug description:
  Thunderbird fails to link on trusty/i386 with the following error:
  
/<<BUILDDIR>>/thunderbird-52.1.0+build2/obj-i686-linux-gnu/_virtualenv/bin/python
 /<<BUILDDIR>>/thunderbird-52.1.0+build2/mozilla/config/expandlibs_exec.py 
--uselist --  /usr/bin/g++ -std=gnu++11  -Wall -Wc++11-compat -Wempty-body 
-Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare 
-Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof 
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations 
-Wno-error=array-bounds -fno-exceptions -fno-strict-aliasing -fno-rtti 
-ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread 
-pipe  -g -freorder-blocks -Os -fomit-frame-pointer -fPIC -shared -Wl,-z,defs 
-Wl,--gc-sections -Wl,-h,libprldap60.so -o libprldap60.so  ldappr-dns.o 
ldappr-error.o ldappr-io.o ldappr-public.o ldappr-threads.o   -lpthread  
-Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id    
-Wl,-rpath-link,/<<BUILDDIR>>/thunderbird-52.1.0+build2/obj-i686-linux-gnu/dist/bin
 -Wl,-rpath-link,/usr/lib   ../../../../config/exter
 nal/nspr/libnspr.a  ../../../../ldap/c-sdk/libraries/libldap/libldap60.so 
../../../../config/external/nspr/pr/libnspr4.so 
../../../../config/external/nspr/libc/libplc4.so 
../../../../config/external/nspr/ds/libplds4.so    -ldl  
  Executing: /usr/bin/g++ -std=gnu++11 -Wall -Wc++11-compat -Wempty-body 
-Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare 
-Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof 
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations 
-Wno-error=array-bounds -fno-exceptions -fno-strict-aliasing -fno-rtti 
-ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread 
-pipe -g -freorder-blocks -Os -fomit-frame-pointer -fPIC -shared -Wl,-z,defs 
-Wl,--gc-sections -Wl,-h,libprldap60.so -o libprldap60.so 
/<<BUILDDIR>>/thunderbird-52.1.0+build2/obj-i686-linux-gnu/ldap/c-sdk/libraries/libprldap/tmpPoM9m_.list
 -lpthread -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id 
-Wl,-rpath-link,/<<BUILDDIR>>/thunderbird-52.1.0+build2/obj-i686-linux-gnu/dist/bin
 -Wl,-rpath-link,/usr/lib ../libldap/libldap60.so 
../../../../config/external/nspr/pr/libnspr4.so 
../../../../config/external/nspr/libc/libplc4.so 
../../../../config/external/nspr/ds/libpl
 ds4.so -ldl
  
/<<BUILDDIR>>/thunderbird-52.1.0+build2/obj-i686-linux-gnu/ldap/c-sdk/libraries/libprldap/tmpPoM9m_.list:
      INPUT("ldappr-dns.o")
      INPUT("ldappr-error.o")
      INPUT("ldappr-io.o")
      INPUT("ldappr-public.o")
      INPUT("ldappr-threads.o")

  /usr/lib/i386-linux-gnu/libc_nonshared.a(stack_chk_fail_local.oS): In 
function `__stack_chk_fail_local':
  (.text+0x10): undefined reference to `__stack_chk_fail'
  collect2: error: ld returned 1 exit status
  make[5]: *** [libprldap60.so] Error 1
  make[5]: Leaving directory 
`/<<BUILDDIR>>/thunderbird-52.1.0+build2/obj-i686-linux-gnu/ldap/c-sdk/libraries/libprldap'
  make[4]: *** [ldap/c-sdk/libraries/libprldap/target] Error 2
  make[4]: *** Waiting for unfinished jobs....

  I've worked around this in the past by exporting "LIBS=-lc", but
  without really understanding what the issue is. So I've taken a proper
  look at this issue now.

  Firstly, "-lc" is passed to the linker without the previous
  workaround. This can be observed by adding --verbose to the link
  command:

  COLLECT_GCC_OPTIONS='-std=gnu++11' '-Wall' '-Wc++0x-compat' '-Wempty-
  body' '-Wignored-qualifiers' '-Woverloaded-virtual' '-Wpointer-arith'
  '-Wsign-compare' '-Wtype-limits' '-Wwrite-strings' '-Wno-invalid-
  offsetof' '-Wno-error=maybe-uninitialized' '-Wno-error=deprecated-
  declarations' '-Wno-error=array-bounds' '-fno-strict-aliasing' '-fno-
  rtti' '-ffunction-sections' '-fdata-sections' '-fno-exceptions' '-fno-
  math-errno' '-pthread' '-pipe' '-g' '-freorder-blocks' '-Os' '-fomit-
  frame-pointer' '-fPIC' '-shared' '-o' 'libprldap60.so' '-v' '-shared-
  libgcc' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-linux-
  gnu/4.8/collect2 --sysroot=/ --build-id --eh-frame-hdr -m elf_i386
  --hash-style=gnu --as-needed -shared -z relro -o libprldap60.so
  /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crti.o
  /usr/lib/gcc/i686-linux-gnu/4.8/crtbeginS.o -L/usr/lib/gcc/i686-linux-
  gnu/4.8 -L/usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu
  -L/usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib -L/lib/i386-linux-
  gnu -L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib
  -L/usr/lib/gcc/i686-linux-gnu/4.8/../../.. -z defs --gc-sections -h
  libprldap60.so /build/thunderbird-52.1.1+build1/obj-i686-linux-
  gnu/ldap/c-sdk/libraries/libprldap/tmpPrXe8H.list -lpthread -z
  noexecstack -z text --build-id -rpath-link
  /build/thunderbird-52.1.1+build1/obj-i686-linux-gnu/dist/bin -rpath-
  link /usr/lib ../libldap/libldap60.so
  ../../../../config/external/nspr/pr/libnspr4.so
  ../../../../config/external/nspr/libc/libplc4.so
  ../../../../config/external/nspr/ds/libplds4.so -ldl -lstdc++ -lm
  -lgcc_s -lpthread -lc -lgcc_s /usr/lib/gcc/i686-linux-
  gnu/4.8/crtendS.o /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-
  gnu/crtn.o

  The workaround results in "-lc" being passed twice.

  Passing "-Wl,--verbose" to the link command shows that ld loads
  libc.so from /usr/lib/i386-linux-gnu/libc.so. This is actually a
  linker script containing the following line:

  GROUP ( /lib/i386-linux-gnu/libc.so.6 /usr/lib/i386-linux-
  gnu/libc_nonshared.a  AS_NEEDED ( /lib/i386-linux-gnu/ld-linux.so.2 )
  )

  So the linker first loads the real libc.so.6. However, none of the
  object files that we are linking use any symbols exported from libc.
  Because our default configuration is to link with --as-needed, this
  means that libc.so is dropped now and is not used for further symbol
  resolution. Then we load libc_nonshared.a, from which we require
  stack_chk_fail_local.oS. This contains a call to stack_chk_fail, which
  is exported from libc. The link now fails because it can't resolve the
  call to stack_chk_fail.

  It seems like libc_nonshared.a should come before libc.so.6.

  I can reproduce this with the attached C++ file (build commands are
  included at the top).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1690445/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to