<j​effro256:monero.social> @sech1: Trying to integrate RandomX V2 in PR #10038, but the RISC-V CI build is failing when I update the RandomX submodule: github.com/monero-project/monero/ac…2273222729/job/64431117401?pr=10038. The header `riscv_vector.h` cannot be found

jeffro256 you need GCC 14 for RISC-V

<r​brunner7:monero.social> Does anybody run a Monero LWS server that I could connect to for an hour or so? I would like to quickly test Skylight Wallet to check its conventional and Polyseed support, and I am lazy to compile and configure an LWS server myself just for that if I can just "borrow" somebody else's server for a while. I am also on IRC to pass me some IP in private.

rbrunner skywallet has built in tor so azefh2cpk3j2cata5gv7rlk6pflxn72lbfz6pmookgvb55pyokgphjid.onion:8443 should work unless

<r​brunner7:monero.social> Thanks a lot, plowsof, seems to work. Is this the NSA's server, or who is running that?

<o​frnxmr:xmr.mx> No, this one is the nsa migfi5a4d4x5fupdvtxbl4azrfxtuhjogjuo63tbjekcjqfkqmgbhlid.onion:18086

<r​brunner7:monero.social> Hmm, the first address gives me a connection error while in the newly created wallet, but never mind, I can make my tests

<o​frnxmr:xmr.mx> What sort of error? On what screen? Lws likes to connect & disconnect repeatedly

<r​brunner7:monero.social> In the wallet display, topleft corner, onion icon with red cross, and giving me a tooltip of "Failed to connect to ..."

<r​brunner7:monero.social> Tor connectivity is built-in, right, I don't have to connect myself "manually" to Tor first?

<o​frnxmr:xmr.mx> correct, if using built-in tor, it starts rhe daemon at wallet open

<r​brunner7:monero.social> Oh, for a wallet restore, it won't let me past the Tor config screen, with connection error. Sigh.

<r​brunner7:monero.social> Never mind, the second address works right now

rbrunner not an nsa server, ghcq

<r​brunner7:monero.social> Sure :) Still pretty basic, that Skylight wallet app.

.merges

oh still borked

anyway, done

it recognises new PRs being opened so my IP is not banned.. will have to check if logs exist later today

rbrunner : you crashed it :( cc ofrnxmr paste.debian.net/hidden/d41290d8

<r​brunner7:monero.social> Cool

<o​frnxmr:monero.social> Plowsof, are you running latest version?

<o​frnxmr:monero.social> I havent seen that bug myself, but i run bleeding edge (develop branch) that has a lot of bugs fixed

ghcr.io/vtnerd/monero-lws:latest (docker :( )

<o​frnxmr:xmr.mx> So either master or release?

<o​frnxmr:xmr.mx> the branches dont seem that far off. Cc vtnerd

<o​frnxmr:xmr.mx> ^

<r​brunner7:monero.social> Just for the record: I just created a few new wallets in the latest version of Skylight wallet app, and restored a few from seed. No transactions whatsoever. Deleted wallets, to be able to create new ones, because of the missing handling of wallets by filename.

<v​tnerd:monero.social> I think this is an outdated version as the line number doesn't map to anything on 0.3 master or develop

<j​effro256:monero.social> sech1: Would it be possible to implement a fallback? Right now the minimum GCC version for Monero is 7, released in 2017. Bumping to GCC 14, released in 2024, would require a 7-year leap forward in our primary dependency.

<o​frnxmr:xmr.mx> On master?

<v​tnerd:monero.social> Master requires c++17 which was enabled by default in gcc 11

<v​tnerd:monero.social> So even then it's a bump forward from min requirements

<o​frnxmr:xmr.mx> I think 7 is release because we build with (EOL'd) 18.04. But yeah, 14 isnt available on ubuntu til 24.04

<o​frnxmr:xmr.mx> documentation.ubuntu.com/ubuntu-for…velopers/reference/availability/gcc

jeffro256 this is only for riscv builds

riscv is a relatively new platform, especially the vector extensions, so no way around that

<j​effro256:monero.social> GCC 7.x contains full support for C++17 as long as you pass `-std=c++17` to the compiler, which we do, so we don't effectively need GCC 11 as the minimum requirement AFAIK

gcc 7 knows nothing about riscv though

as I said, it's a new platform

basically all recent risc-v boards have gcc 15

<j​effro256:monero.social> sech1: yes I understand, but can't you use conditional compilation to fallback to an interpreted VM when vector intrinsics aren't supported by the current compiler?

<j​effro256:monero.social> Or are you saying that standard C++ won't compile for RISC-V on GCC 7?

<o​frnxmr:xmr.mx> monero-project/monero #9448#issuecomment-2306893632

<o​frnxmr:xmr.mx> >  building master with 7 is broken.

<o​frnxmr:xmr.mx> (possibly outdated comment)

gcc 7 is ancient

Why we don't build official release builds using the latest and greatest versions of GCC, is beyond me

And why should I add more #ifdefs and cmake file edits just to support ancient compilers for platform that doesn't even have these ancient compilers

find me any riscv board that has anything older than gcc 14

<o​frnxmr:xmr.mx> sech1 because they are built with gitian, which is using ancient EOL'd 18.04

there is a PR for guix builds

it updated riscv build to use gcc 14, that's it

no more things needed to do here

<o​frnxmr:xmr.mx> guix builds are for master

<o​frnxmr:xmr.mx> so if we branch from master (which we all want to) then were good

yes, and randomx v2 (that has this code) is also for master

<o​frnxmr:xmr.mx> Also, fcmp runs like trash on old rust versions, so i dont think we should cripple the software bt supporting inefficient or ancient libs at this hard fork

<j​effro256:monero.social> sech1: just because we use GCC14 for GUIX doesn't automatically mean that we shouldn't support lower versions of GCC for other compilation pathways IMO

<0​xfffc:monero.social> Any plan for C++20?

Then there will be no vector code for RandomX (even the original one) on RISC-V platform

And hash verification will be 30% slower

jeffro256 lower versions of GCC are supported, just not for RISC-V

RISC-V RVA23 makes them mandatory, so all future boards must support vector extensions, which means they _must_ ship gcc 14 or newer

Again, I don't see a point to support anything older on RISC-V

<s​yntheticbird:monero.social> I love it when a C++ codebase upgrade to a new C++ feature set version but there is no one motivated into improving the existing parts of the codebase with the new feature set

Maybe because "if it works - don't touch it" rule...

<s​yntheticbird:monero.social> right

<s​yntheticbird:monero.social> so there is really no reason to upgrade the C++ version in an already mature project

<s​yntheticbird:monero.social> beside me ragebaiting, 0xfffc what exactly does C++20 would bring ?

It makes sense to upgrade to use new features in the new code