[BUILD] Not producing portable compiled executable bitcoin-qt #23051

Build [v22.0] on Fedora 34 with Berkley DB 4.8 produces src/qt/bitcoin-qt that is not transportable sprouting error bitcoin-qt: error while loading shared libraries: libboost_system.so.1.75.0: cannot open shared object file: No such file or directory when run from /usr/local/bin/on separate Fedora 28 Workstation. Works fine with other GUI issues open elsewhere (one possibly interfaces re-enhancement issue) on build system.

If it is helpful to see what I am building just cd bitcoin/ and run makebitcoin.sh watch for the hardcoded path. I also run strip. I also ln -s dnf get https://github.com/Willtech/bitcoin/tree/v0.22.0rc4

Just for shivers on the seperate Fedora 28 system I tried sudo get install gcc-c++ libtool make autoconf automake python3 libevent-devel boost-devel sqlite-devel miniupnpc-devel libnatpmp-devel qt5-qttools-devel qt5-qtbase-devel qt5-qtwayland qrencode-devel -y but it did not help.

Did you try to build with depends?

On Tue, 21 Sep 2021 at 12:30, Willtech @.***> wrote:

Build [v22.0] on Fedora 34 with Berkley DB 4.8 produces src/qt/bitcoin-qt that is not transportable sprouting error bitcoin-qt: error while loading shared libraries: libboost_system.so.1.75.0: cannot open shared object file: No such file or directory when run from /usr/local/bin/on separate Fedora 28 Workstation. Works fine with other GUI issues open elsewhere (one possibly interfaces re-enhancement issue) on build system.

If it is helpful to see what I am building just cd bitcoin/ and run makebitcoin.sh watch for the hardcoded path. I also run strip. https://github.com/Willtech/bitcoin/tree/v0.22.0rc4

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/issues/23051, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3PXPSIR3V63C72TKUNI5TUDBGEFANCNFSM5EN5SQUA .

--

-- Hennadii Stepanov

Okay, I will try it, I presume the setting for configure make somewhere exists.

It should always build standalone including the application icon and required system fonts.

Did you try to build with depends? On Tue, 21 Sep 2021 at 12:30, Willtech @.***> wrote: Build [v22.0] on Fedora 34 with Berkley DB 4.8 produces src/qt/bitcoin-qt that is not transportable sprouting error bitcoin-qt: error while loading shared libraries: libboost_system.so.1.75.0: cannot open shared object file: No such file or directory when run from /usr/local/bin/on separate Fedora 28 Workstation. Works fine with other GUI issues open elsewhere (one possibly interfaces re-enhancement issue) on build system. If it is helpful to see what I am building just cd bitcoin/ and run makebitcoin.sh watch for the hardcoded path. I also run strip. https://github.com/Willtech/bitcoin/tree/v0.22.0rc4 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23051>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3PXPSIR3V63C72TKUNI5TUDBGEFANCNFSM5EN5SQUA .

… -- Hennadii Stepanov

<s>There is a small possibility it may be because I did not exit before build. I will investigate.</s> I have updated the script slightly, I will push it up to my repo later, including zeromq-devel and adding some config options.

When running bitcoin-qt on separate Fedora 28 Workstation it now exits with bitcoin-qt: error while loading shared libraries: libzmq.so.5: cannot open shared object file: No such file or directory which is resolved after installing zeromq-devel on that workstation also. It is supposed to be doing a static build.

#! /bin/sh
##MAKE Bitcoin on Fedora
##Run from project root bitcoin/
clear
echo "MAKE Bitcoin"
echo "This will GIT CLEAN as part of the build process and install required libraries."
read -r -p "Are you sure? [y/N] " response
if [[ "$response" =~ ^([yY][eE][sS]|[yY])$ ]]
then
set -o xtrace
sudo get install gcc-c++ libtool make autoconf automake python3 libevent-devel boost-devel libevent-devel boost-devel sqlite-devel miniupnpc-devel libnatpmp-devel zeromq-devel qt5-qttools-devel qt5-qtbase-devel qrencode-devel
sudo get groupinstall "Development Tools" -y
git stash
git clean -fqx
./contrib/install_db4.sh `pwd`
##You may need to modify the export if you cannot match my path. Take notice of the last lines of the Berkley DB build.
export BDB_PREFIX='/home/builduser/Github/bitcoin/bitcoin/db4'
./autogen.sh
./configure --disable-tests --enable-static BDB_LIBS="-L${BDB_PREFIX}/lib -ldb_cxx-4.8" BDB_CFLAGS="-I${BDB_PREFIX}/include"
make -j "$(($(nproc)+1))"
fi

@fanquake Is the a build label? It is not building static.

If you want a portable build, use depends.

Builds are not portable by default. If you're building on 1 version of Fedora, while linking against shared libraries, and then taking the binary to an older version of Fedora to run it, where you have a different (or maybe no) version of the same lib installed, it's not going to work. The dynamic loader is telling you exactly why. As mentioned, if you want portable binaries build using the depends system (which is used for release builds).

How about, this used to work and now the workflow is a bit tained by other agendas that are separate from the entire project being the most professional collaboration on Earth? There is no depends option, there is --enable-static that I have manually enable that should be enabled by default. Otherwise, is there an actual usable document for build-unix.md?

The release build system is in de depends/ directory. It has been used for release builds since 2014.

We can't control what building in your native environment will produce, as it may change from time to time. As far as I know, defaulting to static builds is very uncommon as a default. Building from source will by default target building for your own system.

There is no depends option,

"depends" is our system for building dependencies: https://github.com/bitcoin/bitcoin/tree/master/depends. The same system used to produce release binaries.

Agreed, building from source will by default target building for your own system because Linux/Unix/Arm/Mac systems will have different build requirements and different packages. Again, this used to work I have used it several times. A static build is always preferred as they are self-contained Especially especially for a money-crypto product like Bitcoin and changes and updates to the rest of the system have no effect except once the executable is compiled, even changing between one system and another cannot stop correct functionality, except for kernel incompatibility. What does the --enable-static do you suppose, that is enabled by default and you can see that I have enabled manually on the configure command also?

--enable-static[=PKGS]  build static libraries [default=yes]

The release build system is in de depends/ directory. It has been used for release builds since 2014.

We can't control what building in your native environment will produce, as it may change from time to time. As far as I know, defaulting to static builds is very uncommon as a default. Building from source will by default target building for your own system.

As far as I understand it, --enable-static is about the libraries that are built as part of the Bitcoin Core distribution (libconsensus); the option is automatically added by the libtool mechanism used to build it. It has nothing to do with building static binaries (which is significantly more complicated).

I have no idea why what you used to do stopped working, it can be caused by tons of things. Portable builds are complicated, so if you want those, please just use depends. It's an entire system that with substantial effort was designed to solve exactly that problem.

Not sure if it was mentioned before, but using ./depends should produce a static executable by default.

I admit a non-static build can be useful in the lab or in debug so you can look at the libraries on Linux (not so easy to peek a .dll on Windows) but you should not want to mess around with things on a build you compile to use yourself. Thank-you @sipa @fanquake @MarcoFalke please consider this for future development to always use depends on the standard configure make process unless --without-depends

Thank-you. I eventually got back to try depends but the output is full of errors and eventually, it fails. Running Fedora 34 I believe I have all of the pre-requisites. I have built successfully without depends...

Output follows: make.log

Currently working on v22.0
I do not know what is different the next time, I get an output file that will runs on this system but on another it has not compatible GLIBC - how to specify GLIBC version 2.27 for compile? I can see it is a possibility because that version is mentioned a few places.

@Willtech With 22.0 we no longer use hacks to avoid glibc version dependencies: #22930

If you want a build that works down to 2.17, you need to build in an environment with glibc 2.27 or earlier; building against a glibc 2.28 or later results in an implicit dependency on that.

The guix build environment for relases uses a fixed 2.27 glibc for that reason.

It is not very compatible to take away the ability for the application to work on a relatively new operating system not even four years old really. I don't want to end up with a lab with twelve chrooted operating systems on a build computer to have all of the right versions. It is far better for the application, where the modules used are secure, to be self contained and just rely on X-windows. It is not even an idealistic situation, just normal computing models.

Probably I can upgrade the Fedora 28 computer to Fedora 31 which will get me GLIBC_2.30 or similar and it should work but I cannot get it any newer. It is not always possible, and the standard computing model does not allow for, upgrading of old systems, they just exist. Patching is for security only when necessary if it is possible otherwise other mitigating steps are employed. If what you are saying is true I should also be able to compile on the Fedora 28 computer and distribute back to the Fedora 34 computer, perhaps I will try both ways eventually.

It requires increasingly large amounts of hacks to keep the ability to build against a new glibc while retaining runtime compatibility with older ones. Glibc is simply not designed for it, and continuing this practice only increases the risk surface as the difference between supported build versions and intended runtime versions increases.

I'd love to see a mechanism to keep doing this without hacks, but it simply does not exist. Every new glibc version that build OSes ship with means more work to add workarounds and wrappers. This is not a sustainable situation, and it is highly unconventional too: apparently the expected behavior is that when building against a certain glibc, you get a build that is compatible with the version you built with, and later, but not earlier.

You have two options:

• Build using your own environment, and get a build compatible with your environment.
• Build using the release build system (now guix based), which constructs a controlled environment designed to be compatible with all major distros.

Nothing is taken away, and nothing requires a dozen chroots.

Sure, anyway, depends does not build the same portable executables as we get from bitcoin.org because the download works on both straight away.

Using the guix build will produce the exact same binaries as the ones on the site (bit by bit identical, even). Guix (and gitian before it) add a layer above depends which not only controls the dependencies, but also the compiler/library environment.

Okay, thank-you. I see there are several levels of standalone executable.,

• Standalone
• Static
• Self-contained
• Portable
• Universal

As it is, the codebase is universal as it is uncompiled (that is why PHP is better it is already universal - someone could interface it to X11 and have a universal deployment, say creat a JAVA with its own --stdin --stdout --stderr set to operate on top of the desktop GUI, PHP doesn't have to interface to an HTTP engine. Use X it is better than JAVA everyone can have Linux - Bill does a great job but the market competition can press up...), and I can think of the reasons even then why a build system for release might be private as long as it could be trusted. I will try GUIX and see if I can at least get up to portable. I have GitLab now privately so I can clone on the Fedora 28 system and try and build at lease self-contained there probably. It beats pushing everything to the public on GitHub as useful as it is.