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