[spam][personal][crazy] Trying to Build Bitcoin from Source

[Karl]

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 at 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!