Boost linking on Debian 11 #21660

I have various hits of

undefined reference to `boost::system::generic_category()'

like in this example:

in function `boost::system::error_category::std_category::equivalent(std::error_code const&, int) const':
/usr/local/include/boost/system/error_code.hpp:686: undefined reference to `boost::system::generic_category()'

while building in according to documentation using boost 1.74.

Expected behavior

The project should successfully build.

Actual behavior

make can't link to boost.

To reproduce

The basic build command I used:

./autogen.sh && ./configure --with-sqlite=yes --without-bdb --without-gui --disable-tests && make -j4

But of course, I've tried various ways and compilers which turned to be irrelevant since it is a linking issue.

No idea how to reproduce because I have two systems on one I can build the project on another I can't and nothing helps.

System information

Distributor ID:	Debian
Description:	Debian GNU/Linux bullseye/sid
Release:	testing
Codename:	bullseye

Boost version 1.74.

I have tried almost everything: installing all boost, re-installing boost completely, establishing links for boost *.so libs. Nothing helped me.

Did you follow this documentation: https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#linux-distribution-specific-instructions

No idea how to reproduce because I have two systems on one I can build the project on another I can't and nothing helps.

What is the difference between these two systems? Is there a difference between how boost was installed (compiled vs binary)?

@jarolrod Yes, I followed these instructions.

Two systems have different hardware. Some differences in Debian repositories configuration are also possible. Boost libs were installed via apt on both systems. However, before the one which fails contained compiled boost.

But I did clean everything. I see from issues similar error happens sometimes. I was very unsure opening it so I really tried many things. If you know a way how to debug make your suggestions would be very welcomed.

The issue is with configure not finding the boost libs. It's most likely that your boost is not installed in a uniform path.

Can you post a link to a pastebin with the output of the ./configure stage

As Debian 11 development is still in progress, maybe wait for a release candidate?

@jarolrod nope. It finds libboost. I need more nuanced debugging ideas. It configures just fine and this is another strange observation. @hebasto thanks for your response but how to explain that I have one laptop where I can build bitcoind?

how to explain that I have one laptop where I can build bitcoind

It means that something is wrong with the boost packages (or another package) on the other laptop

Also have undefined references with Debian 11 at bitcoind linking time (also building according to documentation i.e. using boost 1.74 and code up to date):

undefined reference to `boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::detail::copy_option, boost::system::error_code*)'

undefined reference to `boost::filesystem::absolute(boost::filesystem::path const&, boost::filesystem::path const&)'

By looking more closely it appears that the prototype in Boost library libboost_filesystem.so is somewhat different of the one expected in the bitcoind code:

$ nm -D /usr/lib/x86_64-linux-gnu/libboost_filesystem.so |grep copy_file
000000000000f540 T _ZN5boost10filesystem6detail9copy_fileERKNS0_4pathES4_jPNS_6system10error_codeE
$ c++filt _ZN5boost10filesystem6detail9copy_fileERKNS0_4pathES4_jPNS_6system10error_codeE
boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, unsigned int, boost::system::error_code*)

$ nm -D /usr/lib/x86_64-linux-gnu/libboost_filesystem.so |grep absolute
000000000000fd00 T _ZN5boost10filesystem6detail8absoluteERKNS0_4pathES4_PNS_6system10error_codeE
$ c++filt _ZN5boost10filesystem6detail8absoluteERKNS0_4pathES4_PNS_6system10error_codeE
boost::filesystem::detail::absolute(boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code*)

Does make distclean help?

@MarcoFalke did distclean routinely many times.

Does make distclean help?

No, that said I fail to see how it could change the source code or the .so binary.

I also do not see how distclean relates to shared library.

@raph2705 thanks for your suggestion.

what i have so far on the laptop where linking fails

boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, unsigned int, boost::system::error_code*)
boost::filesystem::detail::absolute(boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code*)

the most interesting part though that I've checked the library also on the laptop where I've built Core successfully

boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, unsigned int, boost::system::error_code*

So I have a clue that it might be some linking or compilation flags missed in the documentation. From my experience with some other C++ libs.

Yes, I agree, for copy_file method call in bitcoind a boost::filesystem::detail::copy_option scoped enum seems to be expected whereas in current Debian Boost library it is seen as an unsigned int.

@engenegr are you using version 1.74.0-9 of libboost-filesystem1.74-dev on both of your laptops ?

@raph2705 both system have 1.74.0-9 of libboost-filesystem1.74-dev and 1.74.0.3 libboost-filesystem. I've tried to remove 1.74.0.3, it fails at linking on the same stage.

The system which builds Core master has identical packages. What's next, try to bootstrap boost from contrib scipts? Or do we have some more sophisticated tools to investigate this issue.

I shallowly looked at flags at the end of configure output, they seem identical with a single exclusion, the failing system doesn't have ccache in gcc, g++ flags. To me, it looks irrelevant.

So it's correct for libboost-filesystem1.74-dev but I've got libboost-filesystem1.74.0=1.74.0-9 on mine and it's the latter that embeds the libboost_filesystem.so.1.74.0 file.

If you take a look at /usr/include/boost/core/scoped_enum.hpp you'll see the reason why a scoped enum might be defined as a scoped enum or as its underlying type i.e. unsigned int in copy_file case (as declared in /usr/include/boost/filesystem/operations.hpp), so I thought that by adding the right preprocessor directive, in other words CPPFLAGS="-DBOOST_NO_CXX11_SCOPED_ENUMS" it could fix the issue but no result so far.

I don't know about sophisticated tools, it seems to me the issue is pretty clear now, the fix is not, maybe could we borrow a brain or two for some more ideas.

CPPFLAGS="-DBOOST_NO_CXX11_SCOPED_ENUMS" didn't work for me as well.

I guess an alternative approach could be installing suitable bootstrap via provided script in contrib.

It's ok, I found the culprit, on my side anyway, I had an old custom Boost install (not packaged) that I had forgotten about. Since all of those headers were in /usr/local/include which takes precedence over /usr/include and the libs in /usr/local/lib/ which takes precedence over /usr/lib/x86_64-linux-gnu/ I was looking at the right code but not at the one used by g++. Let me know if you've got a similar setup, in which case the issue might be closed.

By the way I'm not sure --with-sqlite=yes is needed (won't hurt though), as its value is auto by default (see ./configure --help), apart from that we do not use very different build options:

$ ./autogen.sh && ./configure CFLAGS="-O2 -march=native -mtune=native" CXXFLAGS="-O2 -march=native -mtune=native" --with-incompatible-bdb && time make -j$(nproc) && make check

Going to close this. You can continue discussion here if you want, but this is most likely not an issue with Bitcoin Core. (And without steps to reproduce there is nothing we can do anyway).

I am testing Bitcoin Core on all major operating system regularly (including Debian 11) and it works with a fresh vanilla install of the OS.

@MarcoFalke

Going to close this. You can continue discussion here if you want, but this is most likely not an issue with Bitcoin Core. (And without steps to reproduce there is nothing we can do anyway).

I agree on my part.

I am testing Bitcoin Core on all major operating system regularly (including Debian 11) and it works with a fresh vanilla install of the OS.

I didn't know that, it's good to see Debian get its credit ^^. Do you know if a packaged version is planned ?

The debian folder in https://github.com/bitcoin-core/packaging#bitcoin-core-packaging is currently unmaintained

Thank you for your answer & your help

@raph2705 thank you for your findings. That should be an issue on my machine as well since I also had not packaged boost there as well.

You helped a lot!

@engenegr thanks, happy to help