[bug] compiling in FreeBSD 14 fails on error

[FierceSkit]

Current behavior:

When compiling dogecoin on FreeBSD 14 with boost 1.83 and clang 16, the following error occurs:

error: static_cast from 'obj_ptr_t' (aka 'void *') to 'void (*)(bool, const CBlockIndex *)' is not allowed
      return static_cast<const Functor*>(type_result.members.obj_ptr);
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/include/boost/function/function_base.hpp:657:40: note: in instantiation of function template specialization 'boost::function_base::target<void (bool, const CBlockIndex *)>' requested here
      if (const F* fp = this->template target<F>())
                                       ^
/usr/local/include/boost/signals2/detail/signal_template.hpp:530:46: note: in instantiation of function template specialization 'boost::function_base::contains<void (bool, const CBlockIndex *)>' requested here
            if((*it)->slot().slot_function().contains(slot))
                                             ^
/usr/local/include/boost/signals2/detail/signal_template.hpp:222:11: note: in instantiation of function template specialization 'boost::signals2::detail::signal_impl<void (bool, const CBlockIndex *), boost::signals2::optional_last_value<void>, int, std::less<int>, boost::function<void (bool, const CBlockIndex *)>, boost::function<void (const boost::signals2::connection &, bool, const CBlockIndex *)>, boost::signals2::mutex>::do_disconnect<void (bool, const CBlockIndex *)>' requested here
          do_disconnect(slot, is_group());
          ^
/usr/local/include/boost/signals2/detail/signal_template.hpp:718:19: note: in instantiation of function template specialization 'boost::signals2::detail::signal_impl<void (bool, const CBlockIndex *), boost::signals2::optional_last_value<void>, int, std::less<int>, boost::function<void (bool, const CBlockIndex *)>, boost::function<void (const boost::signals2::connection &, bool, const CBlockIndex *)>, boost::signals2::mutex>::disconnect<void (bool, const CBlockIndex *)>' requested here
        (*_pimpl).disconnect(slot);
                  ^
init.cpp:1669:36: note: in instantiation of function template specialization 'boost::signals2::signal<void (bool, const CBlockIndex *), boost::signals2::optional_last_value<void>, int, std::less<int>, boost::function<void (bool, const CBlockIndex *)>, boost::function<void (const boost::signals2::connection &, bool, const CBlockIndex *)>>::disconnect<void (bool, const CBlockIndex *)>' requested here
        uiInterface.NotifyBlockTip.disconnect(BlockNotifyGenesisWait);
                                   ^
1 error generated.

Steps to reproduce:
set up FreeBSD 14.0, pkg install git and all dependencies according to guide, git clone dogecoin.
/ switch to 1.14.7-dev branch clone again

run:

./autogen.sh
./configure --disable-hardening MAKE="gmake"
CFLAGS="-I/usr/local/include" CXXFLAGS="-I/usr/local/include -I/usr/local/include/db5"
LDFLAGS="-L/usr/local/lib -L/usr/local/lib/db5"
gmake

Dogecoin Core version
1.14.7-dev

Machine specs

• OS: FreeBSD 14.0 (clang-16 and boost 1.83
• CPU: 8
• RAM: 8192MB
• Disk size: 32GB
• Disk Type (HD/SDD): SSD (NVME)

[patricklodder]

The good news is: I am unable to reproduce this with clang-16 and boost 1.83 on arch linux, so those aren't the cause. I'll look into FreeBSD 14 in the morning.

[chromatic]

That seems familiar to this issue: boostorg/function#47

Maybe reinterpret_cast will do the trick for us too? Do we need a conditional patch against Boost?

[patricklodder]

Per @chromatic's comment, this is indeed a boost issue. Debian and Arch patched it but freebsd pkg didn't.

Should work again with boost-libs-1.84.0.pkg on x86_64.

[patricklodder]

I'll add a note to the release notes that compiling with unpatched boost-1.83.0 will result in an error.

[georgeartem]

Following. Is core maintaining a list somewhere that mentions minimum OS that will provide a clean build in addition to the docs that state the minimum requirements for binaries?

[patricklodder]

a list somewhere that mentions minimum OS that will provide a clean build

No. The process really only actively supports the release binaries. For example, there are no automated tests for FreeBSD, nor should such a test block a pull request, imho.

All self-compilation documentation / support is best-effort, because there are too many variants. Dozens of OS's multiplied by a handful of different compilers multiplied by a handful of package managers make for too many dozens of hands full. So, if it fails, just post an issue. Maybe someone will solve it for you, maybe you have to solve yourself. In this case, a bug in boost-1.83.0 cannot be solved by us unless we pin the dependency, and then we only solve it for the OS we maintain depends in.

[georgeartem]

Yes, understood. What I am getting at is, for someone new starting with a "fresh box" let's say, it would be helpful to know the core "recommended" development toolset for the above, and it might also be helpful for senior members to tell newbies to "get the recommended toolset" and not have to nit with all of the iterations when the box they are using is "unsupported". The downside would be that those with "exotic" builds really would more or less be on their own, but it might also save a lot of trouble and headache with core members attempting to help troubleshoot edge cases.

…

On Sat, Feb 24, 2024 at 12:27 PM Old Dip Tracker ***@***.***> wrote: a list somewhere that mentions minimum OS that will provide a clean build No. The process really only actively supports the release binaries. For example, there are no automated tests for FreeBSD, nor should such a test block a pull request, imho. All self-compilation documentation / support is best-effort, because there are too many variants. Dozens of OS's multiplied by a handful of different compilers multiplied by a handful of package managers make for too many dozens of hands full. So, if it fails, just post an issue. Maybe someone will solve it for you, maybe you have to solve yourself. In this case, a bug in boost-1.83.0 cannot be solved by us unless we pin the dependency, and then we only solve it for the OS we maintain depends in. — Reply to this email directly, view it on GitHub <#3437 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZSY42DRKGA6OMNWMRRJEDYVJEJZAVCNFSM6AAAAABDR6CYOSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRSG4ZDENRYHA> . You are receiving this because you commented.Message ID: ***@***.***>

[patricklodder]

it might also be helpful for senior members to tell newbies to "get the recommended toolset" and not have to nit with all of the iterations when the box they are using is "unsupported".

Luckily, we do that!

From INSTALL.md at the very top:

The easiest way to install the latest version of the Dogecoin Core software is by to download the latest precompiled binaries for your platform from the release page. Currently, binaries are released for the following platforms:

• Windows, 64-bit and 32-bit
• Linux, 64-bit and 32-bit
• MacOS, Intel 64-bit
• ARM, 64-bit and 32-bit Linux

[georgeartem]

😂 noted.Sent from my iPhoneOn Feb 24, 2024, at 1:26 PM, Old Dip Tracker ***@***.***> wrote: it might also be helpful for senior members to tell newbies to "get the recommended toolset" and not have to nit with all of the iterations when the box they are using is "unsupported". Luckily, we do that! From INSTALL.md at the very top: The easiest way to install the latest version of the Dogecoin Core software is by to download the latest precompiled binaries for your platform from the release page. Currently, binaries are released for the following platforms: Windows, 64-bit and 32-bit Linux, 64-bit and 32-bit MacOS, Intel 64-bit ARM, 64-bit and 32-bit Linux —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[patricklodder]

I've added the note. Let's hope that all the package repos that haven't included the patch yet, like FreeBSD ports, will either do that or just package 1.84 soon.

[georgeartem]

I’m trying to think of the second or third year CS student whose interest in CS may stem from crypto currency. They pull down the binaries and lookup the minimum OS list. Their build fails or throws a bunch of warnings then theyre likely to rage quit as a result. They would benefit from having more guardrails in their exploration process.A list of OS and other specs that this team knows will give a clean build would IMO be helpful for that demographic and just seems like the logical next step to maintaining a minimum spec for binaries.Would require some dedicated time for testing and share of existing knowledge to dig a level deeper than what was provided earlier in this thread.🙏Sent from my iPhoneOn Feb 24, 2024, at 6:47 PM, Old Dip Tracker ***@***.***> wrote: I've added the note. Let's hope that all the package repos that haven't included the patch yet, like FreeBSD ports, will either do that or just package 1.84 soon. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[patricklodder]

Alright. My position is that if someone wanna rage quit they gonna rage quit. But, to not create a cheems culture, here's how you can realize your idea, starting small:

1. We have build guides for a couple of linux distros. Those are easy to test because you can just run these in docker containers on any host OS thanks to docker-machine. So it's super-easy to automate. We don't put these in CI because we don't want to block good code with bad breaking packages, but that doesn't mean it cannot get tested.
2. For each actively maintained version, you create a Dockerfile, which you test every time a package manager updates one of the dependencies.
3. If the guide in this repo falls short, you open an issue including the Dockerfile so that people here can reproduce what goes wrong.
4. Someone picks it up and a fix gets proposed. I just did one for a bleeding edge setup on someone's custom rpmset, and they didn't cheems out on us either. So this works.
5. Advanced mode: You create the issue AND the pull request yourself 😁

However, we cannot fix bugs introduced in dependencies that 3rd party package maintainers don't patch, like the one here. In that case, file an issue on their repo, and don't rage quit.

[georgeartem]

I’ve come to the understanding (only very very recently) that I’m pretty good at putting my foot in my mouth.Sent from my iPhoneOn Feb 28, 2024, at 5:02 PM, Old Dip Tracker ***@***.***> wrote: Alright. My position is that if someone wanna rage quit they gonna rage quit. But, to not create a cheems culture, here's how you can realize your idea, starting small: We have build guides for a couple of linux distros. Those are easy to test because you can just run these in docker containers on any host OS thanks to docker-machine. So it's super-easy to automate. We don't put these in CI because we don't want to block good code with bad breaking packages, but that doesn't mean it cannot get tested. For each actively maintained version, you create a Dockerfile, which you test every time a package manager updates one of the dependencies. If the guide in this repo falls short, you open an issue including the Dockerfile so that people here can reproduce what goes wrong. Someone picks it up and a fix gets proposed. I just did one for a bleeding edge setup on someone's custom rpmset, and they didn't cheems out on us either. So this works. Advanced mode: You create the issue AND the pull request yourself 😁 However, we cannot fix bugs introduced in dependencies that 3rd party package maintainers don't patch, like the one here. In that case, file an issue on their repo, and don't rage quit. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[patricklodder]

No need to feel like that. I was just answering under the assumption that you wanted to get things done, as opposed to adding it to my personal todo list because then it'll get done in 2084. So if you want this facility then the best way is to champion it yourself. It's a lot of work though, so consider yourself forewarned. The reason for that is that you cannot give advice on things you haven't tested, and we're talking rapidly changing environments.

For example, a Debian package developer reported this issue with boost 1.83 in December already - and I'm not sure if they have fixed it yet. The bug is still open, whereas when I tested on Archlinux, they did include the patch already. So there are lots of issues that you'll be facing, especially on bleeding edge package sets. Also realize that fixing an issue like #2690, which is exactly the situation you describe, minus the rage quitting, took 9 hours out of my calendar.

Bottom line, your goal of maintaining custom builds for students that ought to learn instead of giving up, is going to be extremely expensive to realize. But it's not impossible. It can be done. If you champion it, I'll help, and I am sure others will too, because issues do get picked up all the time.

Right now, the model is reactive: contributors react whenever someone comes here, reports something broken. But there is no structural support or proactive testing on the custom compiles and their guides. On the code-proactive side we have been discussing ways to keep the ship cleaner than it is (it's kind of a mess, see for example #3379 for an idea how to improve) but these are huge operations and take time to realize. Potentially years.

So here's the deal: you file an issue, people pick it up. The smaller the scope of the issue, the more likely a fix will be done quickly. Additionally, if you need help figuring out how to create a good framework for testing this, I'm willing to reserve a day or 2 to sit down with you and work it out, because even if we only get issues filed against the latest bleeding edge packaging of a single distro, it will help improving overall quality and experience.