loool

does anyone have gcc 14.1.1 and can confirm this build issue? monero-project/monero #9359

e.g. arch should have 14.1.1

<s​yntheticbird:monero.social> selsta

<s​yntheticbird:monero.social> yes I had the same issue trying to build spackle private testnet build

<s​yntheticbird:monero.social> thought I had done something wrong but yes I've the exact same error

s​yntheticbird: do you know how checkout miniupnpc_2_2_8 tag?

<s​yntheticbird:monero.social> no

have you compiled monero before?

p2pool uses miniupnp but it doesn't have this problem with gcc 14. The version in Monero is 4 years old, it's time to update it

<s​yntheticbird:monero.social> yes, 8 months ago

<s​yntheticbird:monero.social> 4 years old is pretty unfortunate

can you try the following changes first and then compile using these steps? first paste.debian.net/hidden/9892c4ee then paste.debian.net/hidden/f74b4854

if it works I'll PR it

<s​yntheticbird:monero.social> i'll try

alternatively I can also prepare a branch so that you just have to enter make

<s​yntheticbird:monero.social> more I'm trying*

<s​yntheticbird:monero.social> selsta posted log in issue

hmmm

actually, what I did for p2pool was turning off a bunch of stuff in miniupnp's CMakeLists: github.com/miniupnp/miniupnp/compar…/master...SChernykh:miniupnp:master

try to leave only UPNPC_BUILD_STATIC = TRUE and UPNPC_NO_INSTALL = TRUE, everything else = FALSE

minihttptestserver seems to be one of those binaries which aren't needed for building Monero

will add UPNPC_BUILD_TESTS FALSE

syntheticbird: can you try again with the changes to `external/CMakelists.txt` selsta/monero c4d5047

<s​yntheticbird:monero.social> selsta trying right now

ty

<s​yntheticbird:monero.social> I forgot to run with -j 8. Wondered why it was so slow

<s​yntheticbird:monero.social> selsta Compiled successfully

will PR

seems it fails on older compilers now

<s​yntheticbird:monero.social> oh

<w​oodser:monero.social> somehow with binaries running on different OS, we're creating a multisig wallet where the participants apparently have different public spend and view keys after completion. was wondering if we can add a check in the multisig creation process to validate that the keys are the same, to prevent creating a broken wallet

<r​brunner7:monero.social> Doesn't the additional last multisig data exchange round that was added a year ago or so by UkoeHB already test that? Anway, if what you describe is a genuine problem, this seems to be pretty much the worst-case scenario to me.

woodser: do the OS have different endianness, or perhaps different sizes for certain ints?

woodser: have you reproduced the problem yourself? It's odd for the view keys to be different, since the view key derivation is quite simple. It could be a serialization bug, but user error is also possible.

<w​oodser:monero.social> probably a mix of linux arm64 and linux, mac, or windows x86, which as far as I know, usually use the same little endian and int sizes

<w​oodser:monero.social> I can reproduce being a participant which fails to import multisig hex due to different public keys, by creating a multisig wallet with this participant

woodser: Are binaries are built from the same commit?

<w​oodser:monero.social> yes they should be

woodser: Multisig account creation is deterministic from original wallet seeds. If you perform setup ceremonies with multiple combinations of OS using the same set of wallet seeds and compare the multisig kex strings passed between them, can you identify which string diverges?

<w​oodser:monero.social> I can look into that but that will take some time

Ok. I looked through the multisig account setup code and didn't see any obvious issues that could be relevant.

size_t and uint64_t are different on mac, not sure if relevant to this issue monero-project/monero #7321/files

size_t can be 4 or 8 bytes depending on if it's 32- or 64-bit compiler

not sure if it's 32-bit or 64-bit related, mac is on 64bit for ages now

it's 64-bit there, but it's defined differently, so the uint64_t serialization functions are not called

in any case, size_t shouldn't be ever used in serialization code