it's 15:41 i'll look for checks for the define BOOST_FILESYSTEM_DISABLE_STATX in the boost source code 15:41 grep -r is doing its thing more slowly than i expect. my sense of how big boost is adjusting. 15:43 it's finding hits inside binary files. hasn't gotten to the source folders yet. most linuxy terminaly softwarey people have a huge set of scripts they use to make their terminals exactly how they want. i'm not that great at keeping track of things, so i only have a couple. the one i want to talk about i have already talked about. a better use of time might be speeding up this grep. since the define is in the filesystem lib -- oops it found it! 15:44 libs/filesystem/src/operations.cpp i'm having trouble finding symbols to isolate the presence of this define by looking at object file contents. it's 15:48 BOOST_FILESYSTEM_USE_STATX is defined only if BOOST_FILESYSTEM_DISABLE_STATX is _not_ it also checks BOOST_FILESYSTEM_HAS_STATX and BOOST_FILESYSTEM_HAS_STATX_SYSCALL . maybe i'll see if other files in this folder reference the define. seems to be the only C source that references it here. 15:51 . basically functions like equivalent_stat take a struct statx if statx is enabled, a struct stat if it isn't. i guess i can check the sigs of those funcs. 15:52 objdump -t | c++filt ooooh equivalent_stat is inlined. so are the other guys. hrm. well, it looks like calls to invoke_statx only happen if it's enabled. ... but it's also inline. but it calls the real statx function! so i can check for that maybe. i could also consider wondering why this compiles at all on my system, or just mutate my stdlib headers. so it uses statx, statx_ptr, statx_fstat, some combination of those. 15:56 | grep statx yields no symbols. maybe i'll check bitcoind's symbols. ooooh i should check the filesystm library's symbols. let's check this gdb output again 1601 . the debugging flow is jumping between line numbers unexpectedly. maybe i'll delete just this object file and rebuild without optimization. oh ... except this is inside boost and that means a different library dir and name by defualt ... ummmmmmmmmmmm well i'll try linking to the debug libs. 1602 looking up on the dangerwebs how to link to boost when it's built debug. 1605 i might be able to just install the debug libs with variant=debug install but when i do this it appears to try to rebuild everything, unsure. nope! ... but it doesn't install anything either. okay. i think i figured it out. 1610 re-con-fig-ur-ing bitcoind. then i can relink it. relinking! make does more reconfiguring. doopty-doo. 16:11. it didn't relink it. _deletes binary_ relinking ...... i see it passing the flags i requested. i guess i'll just try debugging it and see if it looks better. it's 16:22 and i'm stpoped at a breakpoint in boost in bitcoin. i didn't set the LD_LIBRARY_PATH and it loaded the system libraries, not the dbeug ones =/ relaunch yay using the local libs now. 1614 uhhh there's no debugging info. at least, line numbers aren't showing. ok, it got me somewhere there are line numbers. 1614 it's jumping lines just like before =S i'll check the call it's jumping oh ok. it's doing a null pointer dereference?. no. it's not. it's skipping a call to mkdir, going straight into the calls producing the arguments. time to disassemble! here's where i have it paused right now. it's 1617: 0x00007ffff7f85333 <+99>: jne 0x7ffff7f853e0 <_ZN5boost10filesystem6detail16create_directoryERKNS0_4pathEPS3_PNS_6system10error_codeE+272> => 0x00007ffff7f85339 <+105>: mov 0x0(%rbp),%rdi 0x00007ffff7f8533d <+109>: call 0x7ffff7f7b220 <mkdir@plt> i'll step over that mkdir call and see what happens. this is boost::filesystem::detail::create_directory(boost::filesystem::path const&, boost::filesystem::path const*, boost::system::error_code*) in boost 77 . aw man my git-built gdb automatically displays the assembler when you step by instruction, really nice oh whoops my eyes are crossed. no, this is the random sourceline that has the unrelated information. it's a call to c_str within a path structure. i'll just keep typing disas. mkdir returned -1 into $eax here's what gdb shows me, classic gdb: (gdb) ni 0x00007ffff7f85342 475 const value_type* c_str() const BOOST_NOEXCEPT { return m_pathname.c_str(); } no mkdir call on that line due to optimization i guess i'll look up mkdir just to know stronger that -1 means 'error in errno'. man 2 mkdir -> yup. 1620 ok. so the internet said the problem was statx, and i'm getting a failure in mkdir, maybe this means the call to mkdir was done in result of a call to statx or something dunno. i'll look in the source to see where mkdir is called. the line with mkdir appears to be 2182. i'll output errno 1622 and errno has unknown type, plz cast it (int)errno is 17, i'll look that up in /usr/include oh hey i had a brainflash and typed 'perror 17' on the command line: file exists. ok so mkdir doesn't expect to be passed an existing path. let's check the caller's behavior. it's 1624 and create_directory is called at the end of create_directories plural on line 2136. okay, it calls detail::status which is returning wrongly that the directory does not exist. 1626 made a progress ! woopty-woo!