Research meeting in -lab starts at 18:00 UTC (15 minutes from now)

hi

my mingw64 is closing after trying to build using source ./build.sh release-static

where can I see a log error?

rating89us: Is the monero-gui folder in C:/ ?

Is it top level directory?

Also can you try `./build.sh release`

without source and static and without make deploy

test

test failed

thanks!

Now I get '/mingw64/bin/libicudt64.dll': No such file or directory

there is a libicutud65.dll in my dir

do I need to downgrade?

What is the exact you used?

exact command?

all files in my dir are version 65

make deploy

git clone github.com/monero-project/monero-gui.git

cd monero-guisource ./build.sh release-staticcd buildmake deploy

monero-gui does not expect you to have an up-to-date MSYS2. I feel like it's always been that way.

Modify windeploy_helper.sh accordingly.

I think you just do `./build.sh release`

no make deploy step is necessary

make deploy is necessary.

Now when I open monero-wallet-gui.exe I get can't find libzstd.dll

Have a look at my paste.

I’m trying to compile in a Windows VM currently. Will update the repo if some steps are necessary.

iDunk: see the windows build script: github.com/monero-project/monero-gu…ter/.github/workflows/build.yml#L36

that’s why I thought make deploy is not necessary.

iDunk: thanks, it worked with your windeploy_helper.sh

I mean, it's necessary if you want to run monero-gui outside of MSYS2.

rating89us: Btw you should join #monero-gui

iDunk: oh btw you seem familiar with Windows

do you want to help me debug why cmake can’t find openssl

64 bit build ?

I added Windows support here monero-project/monero #6270

together with this PR: monero-project/monero #6267

but it kept failing with cmake not finding openssl, the gui builds fine with exactly the same setup

logs are here: selsta/monero 3a52f0f/checks?check_suite_id=378861637

Is "update pacman" step handled accordingly ?

here you can see the branch: github.com/monero-project/monero/co…aster...selsta:windows-workflow-tmp

`msys2do pacman -Syu --noconfirm` looks correct

L46-L48

You have to terminate MSYS2 (not exit), and run pacman -Syu again.

the GUI script writes the same so I’m not sure if that’s the problem

L15 in build "-D MSYS2_FOLDER= ". Is the gui script using 6267 ?

it uses the equivalent monero-project/monero-gui #2690

Maybe add "echo $MINGW_PREFIX" somewhere at the beginning of the script to see whare it thinks it is.

ok will try thanks

Anyway, I don't think $MSYS2_FOLDER is being set correctly.

iDunk: $MINGW_PREFIX is empty

weird thing is it also adds `"-D MSYS2_FOLDER=` for the GUI and it works fine, this whole thing is just confusing

The problem may be the non-interactive shell, as you can see in lines 12 and 13 in build step.

it says that for every step, I don’t think it is the problem, anyway thanks for looking into it

Every time cmake config cannot find openssl here is when I build the 32 bit release. I immediatelly know I forgot to fix the "-D MSYS2_FOLDER=" in Makefile. 6267 is supposed to fix that, but could be it doesn't work so well in non-interactive shells.

right that sounds plausible but the GUI uses the same non-interactive shell and builds the same monero (just with GUI-DEPS) and it finds openssl there

but I have a few more ideas I’ll try now

hi, Im wondering about this function get_last_n_blocks_weights() which leads to BlockchainLMDB::get_block_info_64bit_fields(). It is used for calculating max block size. Does it return the 100 blocks PREVIOUS to the current block, or INCLUDING the current block?

also used for penalty and fees

depends what you mean by 'current block'

If you mean the block in the process of being mined then no that wouldn't be included

if you mean the most recent block added to the chain then yes it would

is update_next_cumulative_weight_limit() used when someone wants to sync a new node (i.e. to verify block weights and so on)? If so, it seems pretty inefficient since every block seems to calculate the long term median twice (to get block B's long term weight it calculates the previous block's long term median, and then to get the cumulative median

for block B it calculates the long term median for B... move on to block C which will recalculate block B's long term median. Am I missing something here?

Is the median of 100000 blocks meaninglessly fast?

Fairly slow, but there's an incremental mode for the common case of pushing one block.

yeah that much makes sense, is there some other function used for syncing? Or are my premises flawed..