libera #monero-dev

9 May 2022

Official repo: github.com/monero-project/monero || Don’t ask to ask, just ask:) || Monero GUI dev is at #monero-gui || Monero website dev is at #monero-site || Non-dev questions -> #monero, please || No fork help, you’re on your own

• 16:44
  selsta
  hyc: randomx seems to fail to compile now on a lot of OS
• 16:45
  selsta
  paste.debian.net/hidden/aee04b1d
• 17:04
  hyc
  hmmm
• 17:06
  hyc
  that's odd, since the #includes for that haven't changed
• 17:06
  hyc
  which platform is that?
• 17:07
  selsta
  hyc: github.com/monero-project/monero/actions/runs/2295596808
• 17:10
  selsta
  also you have to include `<stdio.h>` in `src/virtual_memory.c` due to `sscanf`
• 17:13
  hyc
  ugh thanks
• 17:14
  hyc
  too much lost between shuffling branches
• 17:14
  selsta
  but not sure yet what causes the complains about MAP_ANON and MAP_HUGETLB
• 17:15
  hyc
  yeah that makes no sense
• 17:15
  moneromooo
  I think ANON isn't on all Unices and HUGETLB is fairly recent to boot. Might need ifdefs ?
• 17:16
  hyc
  got builds running now across the rest of the platforms, will see
• 17:16
  hyc
  MAP_ANON is only used if MAP_ANONYMOUS isn't defined
• 17:16
  hyc
  but MAP_ANONYMOUS is the POSIX def, it should always be there
• 17:18
  selsta
  the same code worked previously as far as i can tell
• 17:18
  hyc
  right
• 17:18
  selsta
  hyc: maybe you have to declare the C version in randomx cmake
• 17:18
  hyc
  there's nothing in the diffs that changed around there
• 17:19
  hyc
  ?
• 17:19
  hyc
  which cmake?
• 17:19
  selsta
  currently only CXX_STANDARD 11 is set, but not C_STANDARD 11 in randomx cmakelists
• 17:20
  selsta
  stackoverflow.com/a/5446710
• 17:21
  hyc
  hmmm
• 17:25
  hyc
  seems like it may need _GNU_SOURCE, regardless of C version
• 17:29
  hyc
  odd that it compiles fine on my linux and macos boxes
• 17:43
  hyc
  hm, maybe the difference is that gitian is using gcc 7.5 and my linux box is gcc 10.3
• 17:48
  hyc
  setting C_STANDARD 11 property didn't help
• 17:52
  hyc
  fixed...
• 17:52
  hyc
  running all builds again
• 17:55
  selsta
  looking good now
• 18:00
  selsta
  all green
• 18:07
  hyc
  great
• 18:10
  tusko
  is there some particular version of boost that should (or should not be) be dynamically linked when building? have so many boost errors
• 18:10
  hyc
  we statically link
• 18:11
  hyc
  dynamic linking only works if library and main program are all built by same version of compiler. too unreliable
• 18:11
  hyc
  the official binaries use boost 1.64
• 18:12
  moneromooo
  At least 1.53 IIRC. 1.72 worked. I think 1.74 also did. If you use open openSSL >= 1.1, older boost doesn't work.
• 18:12
  hyc
  that or newer should work. my macos build uses 1.75.
• 18:13
  hyc
  1.64 also doesn't work on arm mac without small fixes
• 18:13
  moneromooo
  If you're using earlier than 1.53, upgrade. If you're using a very recent boost, we might need to patch, so post the errors on paste.debian.net. Otherwise, it's likely your problem.
• 18:19
  selsta
  hyc: I tried updating boost to 1.79 so that we can drop all the patches
• 18:21
  selsta
  but it's a huge mess, boost changed the library naming to attach -x64 and CMake stops finding the boost libs
• 18:21
  selsta
  found a couple different solutions but none worked on all operating systems
• 18:21
  selsta
  and then I gave up lol
• 18:23
  selsta
  moneromooo: we support 1.58 or newer
• 19:04
  hyc
  yuck. yeah any time you run into cmake problems might as well stop...
• 19:14
  tusko
  I definitely got a lot of warnings about what looked like some linked list writing bytes to something size 0.
• 19:14
  tusko
  that seemed sketchy
• 19:17
  moneromooo
  It'd be a useful report with the actual message(s),
• 19:23
  jeffro256[m]
  tusko I was getting that too, lemme see if I can reproduce it
• 19:25
  moneromooo
  Compile time or runtime ?
• 19:29
  jeffro256[m]
  Compile time
• 19:29
  jeffro256[m]
  Here I made an issue: monero-project/monero #8320
• 19:30
  jeffro256[m]
  I haven't had any runtime issues AFAIK, but it really spams the crap out of the compiler output cause it's in the boost archive code
• 19:30
  moneromooo
  Ah, I think I remember seeing that one, IIRC I thought the compiler was full of it.
• 19:30
  tusko
  For me, I run `git clone --recursive github.com/monero-project/monero.git && cd monero && git checkout release-v0.17 && USE_SINGLE_BUILDDIR=1 make` and get this error bpa.st/TXWA
• 19:30
  tusko
  So that one is at compile time
• 19:30
  moneromooo
  I'll look again.
• 19:30
  moneromooo
  Shame it can't give traces to its chain of deduction, it'd make things easier.
• 19:31
  jeffro256[m]
  @tusko update your submodules
• 19:31
  tusko
  and then, after I force init and update the modules, yeah I get that same error jeffro256[m] just produced after
• 19:31
  jeffro256[m]
  `git submodule update --init --force`
• 19:32
  tusko
  Yup that worked, and now I get the error you demonstrated.
• 19:33
  jeffro256[m]
  moneromooo Thanks! I can take a look it a couple of days, it seems like it shouldn't be *too* difficult
• 19:34
  moneromooo
  I *think* after looking, I make a brute force program to call this with 0-N length to make sure it didn't overflow, but I'm not 100% sure. I'll do it soon.
• 20:16
  jeffro256[m]
  moneromooo I added another trace to that issue, idk if that will help
• 20:20
  moneromooo
  AFAICT it's fine and ASAN doesn't complain on ttps://paste.debian.net/1240372/
• 20:21
  moneromooo
  I'll post that.
• 20:27
  selsta
  luigi1111: merges?
• 20:27
  selsta
  .merges
• 20:27
  xmr-pr
  8046 8220 8226 8235 8262 8277 8278 8279 8280 8281 8293 8300 8301
• 20:27
  selsta
  .merge+ 8302 8304
• 20:27
  xmr-pr
  Added
• 20:32
  luigi1111
  Wow