Author

Topic: Building Bitcoin-core on CentOS 7 (Read 3198 times)

full member
Activity: 162
Merit: 109
June 07, 2017, 08:05:23 AM
#8
Hello!

I wrote and tested Makefile for local-user environment for compiling and installing Bitcoin Core UASF patch (https://github.com/UASF/bitcoin)
It's for CentOS 6.* but i hope it will work in any Linux and *BSD systems

https://github.com/Perlover/bitcoin-uasf-makefile

Please README.txt there (why i did it)

Best regards, Perlover Smiley
newbie
Activity: 22
Merit: 0
July 22, 2015, 07:54:27 AM
#7
yes, running it on the same box ... so far it runs smooth.
I just want to avoid to run into trouble because of broken linking ... or diggin myself a security hole  Grin
legendary
Activity: 1456
Merit: 1081
I may write code in exchange for bitcoins.
July 21, 2015, 10:28:46 AM
#6
Well yes, but I've abandoned the dynamical-linking as I wasn't able to convince the linker to link against the right libs.
Plus I got a lot of the: "no version information available" warnings/errors which forced me to roll back the new libs to the system default ones.

On top, I checked the rpath everytime and the entries within the Makefiles. They were always pointing to the right libs, but for whatever reason the linker either choose the system libs or I got a ton of "version information" errors and stuff ... (probably because of the missing -ldl switch)

On the other hand, when dealing with bitcoin direve space should not be an issue Wink
I don't really care if the application is gonna bit a few meg's bigger because of the statical linking.

So I was expecting that the linker will indeed include everything and don't try something dodgy:
Code:
... Linking the shared library libbitcoinconsensus.la against the static library /opt/ssl/lib/libcrypto.a ...

Could there be a "-static" missing ?

Could be, I'm not an expert at this stuff although I do have a little bit of experience.  Anyway, it looks like it's just a warning, did you try to run it on the computer you compiled on?  If that's the target machine, it might not matter at all that what you've compiled isn't portable.
newbie
Activity: 22
Merit: 0
July 21, 2015, 05:02:24 AM
#5
Well yes, but I've abandoned the dynamical-linking as I wasn't able to convince the linker to link against the right libs.
Plus I got a lot of the: "no version information available" warnings/errors which forced me to roll back the new libs to the system default ones.

On top, I checked the rpath everytime and the entries within the Makefiles. They were always pointing to the right libs, but for whatever reason the linker either choose the system libs or I got a ton of "version information" errors and stuff ... (probably because of the missing -ldl switch)

On the other hand, when dealing with bitcoin direve space should not be an issue Wink
I don't really care if the application is gonna bit a few meg's bigger because of the statical linking.

So I was expecting that the linker will indeed include everything and don't try something dodgy:
Code:
... Linking the shared library libbitcoinconsensus.la against the static library /opt/ssl/lib/libcrypto.a ...

Could there be a "-static" missing ?
legendary
Activity: 1456
Merit: 1081
I may write code in exchange for bitcoins.
July 20, 2015, 12:08:02 PM
#4
Hi all,

I've tried a couple of things and played around with the parameters but all failed ... until somebody suggested me to "forcefully" link the binaries against the static ssl libs.
So I modified the Makefile's in the "root" and "src" directory:
Code:
CRYPTO_CFLAGS = -I/opt/ssl/include
CRYPTO_LIBS = -ldl /opt/ssl/lib/libcrypto.a

LIBS =-lanl -ldl

PKG_CONFIG_PATH = /opt/ssl/lib/pkgconfig

SSL_CFLAGS = -I/opt/ssl/include
SSL_LIBS = -ldl /opt/ssl/lib/libssl.a

So far the compiling and linking seem to work, except for this message I don't understand:
Code:
*** Warning: Linking the shared library libbitcoinconsensus.la against the
*** static library /opt/ssl/lib/libcrypto.a is not portable!

Does anyone know what this means ?


I would think it just means that libcrypto.a is compiled for this machine and that you can copy it into your binary (static linking) but that binary might not execute on another machine.  Ie, not portable. Smiley

dynamic linking should be more portable  because each machine that implements libcrypto can have it's own code for that interface and your program only needs to know that the functions are there and callable, not how to implement them on a particular machine.
newbie
Activity: 22
Merit: 0
July 20, 2015, 02:19:13 AM
#3
Hi all,

I've tried a couple of things and played around with the parameters but all failed ... until somebody suggested me to "forcefully" link the binaries against the static ssl libs.
So I modified the Makefile's in the "root" and "src" directory:
Code:
CRYPTO_CFLAGS = -I/opt/ssl/include
CRYPTO_LIBS = -ldl /opt/ssl/lib/libcrypto.a

LIBS =-lanl -ldl

PKG_CONFIG_PATH = /opt/ssl/lib/pkgconfig

SSL_CFLAGS = -I/opt/ssl/include
SSL_LIBS = -ldl /opt/ssl/lib/libssl.a

So far the compiling and linking seem to work, except for this message I don't understand:
Code:
*** Warning: Linking the shared library libbitcoinconsensus.la against the
*** static library /opt/ssl/lib/libcrypto.a is not portable!

Does anyone know what this means ?


legendary
Activity: 1456
Merit: 1081
I may write code in exchange for bitcoins.
June 26, 2015, 11:01:29 AM
#2
I'm not very good with linker errors but perhaps if the "wrong" libraries are missing routines that are in the ones you just built and put into /usr/local/share/ then you could move the "wrong" libraries out of the way and put a symlink there which points to the "right" ones.

Maybe another option would be to look in the Makefile generated by configure to see if the -l statements look right and if they don't edit them by hand.
newbie
Activity: 22
Merit: 0
June 26, 2015, 05:15:38 AM
#1
Hi All,

I'm trying to build the latest bitcoin-core (ver. 0.10.2) on my CentOS 7 box.

Unfortunately the openssl version of CentOS 7 doesn't ship with with eliptic curves encryption support.
So I had to download and build it my own.
Building went fine and files are placed in /usr/local/ssl/...

Next I configured the bitcoin source-code:
Code:
./configure PKG_CONFIG_PATH=/usr/local/ssl/lib/pkgconfig LIBS=-Wl,-rpath,/usr/local/ssl/lib
So this should tell the linker not to link agains the old ssl library, but the one in /usr/local/ssl/lib

Compiling went fine without errors.
But again, when you try to launch the bitcoind, I get:
Quote
Error: OpenSSL appears to lack support for elliptic curve cryptography. For more information, visit https://en.bitcoin.it/wiki/OpenSSL_and_EC_Libraries
Error: Initialization sanity check failed. Bitcoin Core is shutting down.

A quick check reveals:
Code:
[root@server ~]# ldd /usr/local/bin/bitcoind
        linux-vdso.so.1 =>  (0x00007fff0f7fe000)
        libboost_system.so.1.53.0 => /lib64/libboost_system.so.1.53.0 (0x00007f8ee8210000)
        libboost_filesystem.so.1.53.0 => /lib64/libboost_filesystem.so.1.53.0 (0x00007f8ee7ff8000)
        libboost_program_options-mt.so.1.53.0 => /lib64/libboost_program_options-mt.so.1.53.0 (0x00007f8ee7d86000)
        libboost_thread-mt.so.1.53.0 => /lib64/libboost_thread-mt.so.1.53.0 (0x00007f8ee7b6f000)
        libboost_system-mt.so.1.53.0 => /lib64/libboost_system-mt.so.1.53.0 (0x00007f8ee796a000)
        libboost_chrono-mt.so.1.53.0 => /lib64/libboost_chrono-mt.so.1.53.0 (0x00007f8ee7762000)
        libdb_cxx-4.8.so => /lib64/libdb_cxx-4.8.so (0x00007f8ee73c0000)

        libssl.so.10 => /lib64/libssl.so.10 (0x00007f8ee7152000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f8ee6d6b000)

        libanl.so.1 => /lib64/libanl.so.1 (0x00007f8ee6b67000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8ee685f000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f8ee655d000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8ee6347000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8ee612a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f8ee5d69000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f8ee5b61000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f8ee5914000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f8ee5631000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f8ee542c000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f8ee51fa000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f8ee4ff6000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f8ee4ddf000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8ee8ad6000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f8ee4bd0000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f8ee49cb000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f8ee47b1000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f8ee458b000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f8ee432a000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f8ee4105000)

Why does it still link against the wrong library ?  Shocked Cry
Any ideas ?
 
Jump to: