[wip] depends: bump qt to 5.9.8

[xanimo]

-opening as draft while i work through this

(sidenote: extensively tested #3466 on x86_64-pc-linux-gnu ubuntu jammy)

[xanimo]

(i also know the goal is to support < 5.12 / 6, so disregard the change to 5.9.8, there will be more commits added in the coming days...)

[xanimo]

my mistake will adjust accordingly, i just stumbled upon #3474.

[SoraKohaku]

QT 6 not support yet? hope so....some compability on Debian higher than old.

[patricklodder]

Are you sure this is a good way to do it? Last couple of times - most recent: symbol check logic - this was proven to not be a great route for getting actual results. Perhaps better to just ignore 7 years of intermediate Bitcoin stuff and just make Qt6 work?

[xanimo]

Probably not. I'll try to put something together for Qt6.

[patricklodder]

The easiest way is to just get it to work without depends first. As in just allow it to be selected with autoconf and compile by inserting conditionals into our Qt code.

That allows everyone to get experience with it before trying to influence the build. Note that we're on a release clock constantly now, so large breaking changes like this that will impact release binaries can easily be delayed and take a million rebases. The larger the change set, the more painful it becomes. And it already was painful.

Per my note to Shafil - I've been assessing what's needed to just do a local compile without depends.

• The first step is "is anything we use now deprecated w/o replacement candidate?". I did that already and I couldn't find anything at the module level, so that's great.
• Second, you're looking at mapping Qt6 modules to the functions we require in the code (which is easier to do on top of #3466 than without, I think) and this would then be the basis for updating bitcoin_qt.m4.
• When that's done, it will definitely not compile, so that's when you're looking at code.

The Qt implementation in 1.14 - and with that 1.15 - has diverged a lot from Bitcoin. There's no point, imho, of looking at Bitcoin Core, unless we're looking to solve an issue in the final step of making the code compile with Qt6 that may already have been solved there, if any.

[xanimo]

Duly noted. Definitely don't want to introduce a large change set so will take a look more at what you've already actually done before I try messing with this.

[patricklodder]

What I can do is open a draft PR here once I have the macros done but compilation with Qt6 still fails (while CI succeeds.) And then that would be open to collaboration. Until then it's hard to collaborate, because it's all very sequential and blocking work.

[xanimo]

Absolutely. I'll wait until then before attempting to collaborate on Qt stuff but still going to explore what you've already done. I'm at a loss as to how I missed #3474 but it's neither here nor there. Excited to see someone finally do the work to ditch openssl though :+1:

Closing this per the discussion above.

[patricklodder]

Excited to see someone finally do the work to ditch openssl though 👍

Still needs more work after that one though, this only touches the Qt side. I think (but I've just glanced at the diffs) that the remainder actually can get backported from Bitcoin Core cleanly and safely...