1. 
   laanwj commented at 1:36 pm on March 5, 2014: member

   According to https://bitcointalk.org/index.php?topic=495683.msg5471918#msg5471918, the resulting executables from gitian no longer work on debian 7.4 (stable).

   0bitcoind: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by bitcoind)
   1bitcoind: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by bitcoind)
   

   This is caused by switching the gitian build to VMs using Ubuntu 12.04 (which uses GLIBC_2.15).

   I investigated and the only symbol that we actually use from GLIBC_2.14/15 is:

   0$ objdump -T bitcoin-0.9.0rc2-linux/bin/32/bitcoin-qt |grep GLIBC_2.15
   100000000      DF *UND*  00000000  GLIBC_2.15  __fdelt_chk
   

   __fdelt_chk is part of the FORTIFY_SOURCE functionality and was indeed introduced in glibc 2.15.

   We may be able to remove dependency on this symbol by undefining FORTIFY_SOURCE, but as it is part of a hardening feature I’m not really happy about that.

2. laanwj added the label Build system on Mar 5, 2014
3. 
   luke-jr commented at 6:56 pm on March 7, 2014: member

   Can’t we just static-link this symbol as well?
4. 
   laanwj commented at 8:35 am on March 8, 2014: member

   It’s not possible(read:safe) to static-link libc++/glibc unless statically linking everything.

   Fully static linking has some drawbacks too, at least:

   • Not possible to link against any shared libraries
   • No dynamic loading of modules possible (IIRC with glibc this can give problems with ‘NSS’ and name resolving which relies on dynamic modules)
   • IIRC entirely static linking will conflict with some of the hardening features such as ASLR which rely on the dynamic linker
   • Dependency on a certain minimum kernel version (i.s.o minimum glibc version)

   In the case of bitcoind this would be possible, we don’t need any of the system deps nor dynamic loading.

   In the case of bitcoin-qt it’s not as we need to link against the system’s Qt. This means that we need to share the libc++/glibc implementation.

5. 
   jcea commented at 7:04 pm on March 19, 2014: none

   Ubuntu 10.04 has glibc 2.11, and Red Hat Linux has glibc 2.12. See Issue #3904
6. 
   wtogami commented at 9:45 pm on March 19, 2014: contributor

   I’m sorry I missed this. I originally advocated for gitian to precise 12.04 for the Windows builds only because I was aware that doing so for the Linux builds would break glibc compatibility. 12.04 mingw was necessary to fix some long standing issues in the Windows builds and to enable win64 builds.

   AFAIK there is no reason why gitian needs precise for the linux builds? It should be downgraded back to lucid for 0.9 to maintain compatibility.

7. 
   laanwj commented at 10:15 pm on March 19, 2014: member

   We’re striving towards being able build everything on one VM.

   Downgrading to 10.04 goes the wrong way. It’s not an option.

   Adding fully-statically built bitcoind (but not -qt) to the release would be more likely.

   But there are likely also other ways to get rid of those symbols. Patches welcome as always.

8. 
   jcea commented at 11:03 pm on March 19, 2014: none

   Downgrading VM would be the right way UNTIL a more satisfactory change can be deployed. The fact is that current release is broken in quite a few linux distributions, many of them not legacy at all.

   Better something working today that something perfect in a month.

   I would push for a “9.0.0a” linux release now with the old build VM, compatible, while somebody else is working on a better approach. But dropping in the cold perfect currently supported linux distributions is a mistake, in my opinion.

   I am back in 8.6.0 land for now :(. The released 0.9.0 is not working on Debian Stable, Ubuntu 10.04, RedHat enterprise linux… This is not going to improve.

   I respectfully request to go back to old VM until something" better" is done, like static compilation. First, fulfill users needs. Current and prioritary need is to have a working bitcoin application.

9. 
   anton000 commented at 1:16 am on March 20, 2014: none

   +1 @jcea idea of 0.9.0a from old build VM same on CentOS 6.5 , back to 0.8.6 for now :(
10. 
    laanwj commented at 7:02 am on March 20, 2014: member

    Well, do it yourself in that case. You don’t need me for anything.
11. 
    laanwj commented at 9:01 am on March 20, 2014: member

    I managed to make gitian produce a static executable as well for bitcoind (just a matter of adding -static to OPTFLAGS):

     0  2943584 Mar 18 18:18 32/bitcoin-cli
     1  7748512 Mar 18 18:18 32/bitcoind
     2  8407524 Mar 18 18:18 32/bitcoind.static
     3 12164000 Mar 18 18:18 32/bitcoin-qt
     4  9740608 Mar 18 18:18 32/test_bitcoin
     5  8420256 Mar 18 18:18 32/test_bitcoin-qt
     6  3103728 Mar 18 18:32 64/bitcoin-cli
     7  7773680 Mar 18 18:32 64/bitcoind
     8  8632240 Mar 18 18:32 64/bitcoind.static
     9 12226032 Mar 18 18:32 64/bitcoin-qt
    10  9860528 Mar 18 18:32 64/test_bitcoin
    11  8457776 Mar 18 18:32 64/test_bitcoin-qt
    

    As you can see the fully static executable is only ~10% larger than the semi-static one that we currently ship.

    Drawback of the static executable is that it can’t have -pie (address space randomization) as that creates a dependency on the dynamic linker.

    Still need to test it on the affected architectures, but I think this is a good intermediate solution.

    Edit: also needs a bitcoin-cli.static

12. 
    laanwj commented at 11:53 am on March 20, 2014: member

    Testing needed in #3914
13. 
    theuni commented at 5:30 pm on April 7, 2014: member

    I had some other things pushed on top of this, but it’s coming up on my stack. Not forgotten.
14. 
    jcea commented at 11:42 am on April 8, 2014: none

    I am glad somebody is paying attention to this. I am stuck in 0.8.6 world. Surely I am not the only one.
15. 
    theuni commented at 6:19 pm on April 8, 2014: member

    Ok, a clean solution pushed to a testing branch: https://github.com/theuni/bitcoin/commits/libc-compat If anyone could try, it would be much appreciated.

    Assuming it actually works as intended, I’m comfortable with that as a candidate for merge.

    Note that only glibc issues are addressed there. It removes the 2.15 and 2.14 dependencies. libstd++ issues still remain.

16. 
    wtogami commented at 5:37 am on April 9, 2014: contributor

    I tried @theuni’s https://github.com/theuni/bitcoin/commits/libc-compat with a change to gitian-linux.yml adding --enable-glibc-back-compat to the end of the ./configure line.

    Problem: GLIBC_2.15 not filtered.

    [root@rhel6 tmp]# file bitcoind bitcoind: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, stripped [root@rhel6 tmp]# ldd bitcoind ./bitcoind: /lib/libc.so.6: version GLIBC_2.15’ not found (required by ./bitcoind) linux-gate.so.1 => (0x00418000) librt.so.1 => /lib/librt.so.1 (0x0048c000) libm.so.6 => /lib/libm.so.6 (0x00130000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x004bb000) libpthread.so.0 => /lib/libpthread.so.0 (0x0015a000) libc.so.6 => /lib/libc.so.6 (0x00175000) /lib/ld-linux.so.2 (0x00398000)`

    Problem: libstdc++ static link issue

    http://193.28.235.60/~warren/temp/build.log The static gitian binaries meant to work with older distros introduced in #3914 came at the cost of disabling all hardening flags on x86_64. Unless a way to static link Precise’s x86_64 libstdc++ is found without disabling hardening, we will need a shim library to filter out the libstdc++ symbols too. has notes on this issue.

17. 
    wtogami commented at 6:14 am on April 9, 2014: contributor

    @theuni suspects the libstdc++ x86_64 problem may actually be the library is broken in Precise.
18. 
    quel commented at 1:30 am on April 15, 2014: none

    3kingsAnon,

    While that solution may function to run the bitcoin binaries, the number of problems it may cause are beyond enumeration. sid is a permanent name for Debian unstable and as such is prone to breakage, lack of security attention, etc. It’s one thing to pull some packages from testing [currently named jessie which will be the release that replaces stable/wheezy one day], but it is another to pull such packages from sid especially when they involve critical core components such a libc. Additionally, it is unlikely for a long time that the version of libc in stable or testing replaces the unstable version and so your only potential of getting any critical fixes, such as security related fixes, vanishes as soon as you remove the sid repo line.

    Please do not use this recommendation or pass this along. The sheer issues with apt related to libc versions, breaking existing packages, security, etc. make this solution a poor idea.

    Instead for now you have two options that are much better:

    1. Use the static binaries from 0.9.1 (bitcoin-cli.static and bitcoind.static)
    2. build your own, which amusingly enough requires an old version of db4.8 from squeeze (currently oldstable)
19. 
    luke-jr commented at 1:38 am on April 15, 2014: member

    @quel +1
20. 
    wtogami commented at 1:47 am on April 15, 2014: contributor

    Please test the binaries in #4042. It should be at least as functional as the gitian binaries of Bitcoin 0.8.x.
21. laanwj closed this on May 2, 2014

    ---

22. DrahtBot locked this on Sep 8, 2021

Contributors
laanwj luke-jr jcea wtogami anton000 theuni quel

Labels
Build system