--- Log opened Fri Jun 14 00:00:41 2019
00:15 < wumpus> nothingmuch: right, we really need to build against bdb 4.8 for the releases or it would cause incompatibility issues
04:06 <@dongcarl> nothingmuch: writing a package for bdb 4.8 is really simple, just inherit, change version, and hash
04:07 <@dongcarl> The hard part is dealing with Guix’s preference for rpaths and linking everything.
04:07 <@dongcarl> It makes sense in their model, but not for our release binaries
04:08 <@dongcarl> To see what I mean, build bitcoin-core with Guix and run `ldd` on it
04:12 <@dongcarl> TheCharlatan: Guix already has llvm, not that much of a challenge but we need a cctools package for Guix, and for depends to use _that_ instead of building its own from a downloaded binary of llvm (go see the depends definition for cctools)
08:45 <@dongcarl> fanquake: Heads up... tar's `--sort=name` only sorts directory entries... and we're passing in filenames...
08:47 <@dongcarl> I'm confirming right now, but I've run into many problems like this which indicates to me that it's better to use UNIX composability with pipes rather than relying on commands to call each other correctly
09:41 < fanquake> dongcarl ok
12:11 < cfields> dongcarl: looks like upstream needs a little help with the libs.
12:12 < cfields> wait
12:13  * dongcarl waiting
12:13 <@dongcarl> cfields: btw, need your help deciphering some diffoscope output
12:14 < cfields> dongcarl: I don't understand why libtool would affect that.
12:14 < cfields> libtool isn't used for linking there.
12:15 < cfields> ld doesn't read .la files by default. I'm 99% sure of that. Should be only linking with libtool...
12:15 < cfields> So I understand how deleting the .la's could mess up _our_ link, but I don't see why it would mess with qt.
12:15 < cfields> Oooooh
12:16 < cfields> unless it embedded rpath
12:16  * dongcarl gets excited
12:16 < cfields> I bet it did
12:16 <@dongcarl> another hint: 14209286df4a91a0e6738268339ba667d868a11f is fine
12:16 < cfields> If you diff before/after the libtool removement, does a 'readelf -d' show a difference in rpath for the .so's?
12:16 < cfields> *removal. Heh.
12:17 <@dongcarl> cfields: That's a good point. Let me try that.
12:17 <@dongcarl> cfields: .so's for x11?
12:17 < cfields> When linking with libtool, it'll try to add an rpath for needed deps outside of expected paths. I think.
12:18 < cfields> I would expect differences in libX11.so and/or libxcb.so, yes.
12:18 <@dongcarl> cfields: Hmmm... So if that's the case, what's a good fix?
12:19 < cfields> dongcarl: I'd have to trace out the dep chain again. It's confusing. In this case, looks like we want libxcb to be static.
12:19 < cfields> I have no idea of its status atm :p
12:20 <@dongcarl> We have 'libxcb.so.1' as allowed in symbol-check.py
12:20 <@dongcarl> But perhaps it's not absolutely needed?
12:22 <@dongcarl> cfields: BTW, here's a diffoscope for you: https://www.dropbox.com/s/gq3eh3sr3s56pgh/diffocli?dl=0
12:22 <@dongcarl> non-reproducibility that I need to solve right now...
12:22 <@dongcarl> this is a diffoscope of `bitcoin-cli`
12:23 < cfields> No, it's needed to be exported. But it looks like we either need to build a separate static version, or help it find the shared one.
12:24 < cfields> Hmm
12:24 < cfields> Or
12:24 < cfields> we could back out the libtool removals for the shared libs.
12:24 < cfields> Blah. Will think on that. rpath is a hack that's better avoided, imo.
12:24 < cfields> dongcarl: context on the determinism problem?
12:26 <@dongcarl> cfields: doing Guix builds, building on same machine is deterministic, building on different ones are not
12:26 <@dongcarl> In this case, one machine is Arch, one machine is Ubuntu
12:28 <@dongcarl> determinism problem seems to arise from addresses being at an offset
12:40 <@dongcarl> cfields: for the `qt` problem, here's its configure help: https://gist.github.com/dongcarl/b6ca598d7061e411fa8b6b559e81f25b
12:40 <@dongcarl> Wondering if we can use `_LIBDIR` and `_LIBS` to achieve the same thing as libtool
12:45 < cfields> dongcarl: we can. But it's annoying that their list is hard-coded rather than discovered somehow.
12:46 < cfields> It'll have to carry through to our build as well.
12:47 <@dongcarl> cfields: Hmmm... Could we somehow patch their configure to use pkg-config? Does that make sense?
12:48 < cfields> dongcarl: their X stuff is so tangled I can't really make sense of it. I don't think I could reasonably justify any upstream change.
12:48 < cfields> (We could ofc hack something in for ourselves)
12:50 <@dongcarl> cfields: BTW would you happen to know why the builds still work? Even without XLib?
12:50 <@dongcarl> Seems strange to me...
12:51 < cfields> dongcarl: I'm going to have to sit down with master and get a fresh look at everything at once. Unfortunately I still don't have my home-office up and running, so I've been kinda watching from the sidelines.
12:52 <@dongcarl> cfields: Yeah that sounds like a plan. In the meantime lmk if you have any insights into my diffoscope output
12:52 < cfields> dongcarl: installing diffoscope on my dinky macbook atm :)
12:53 <@dongcarl> cfields: Oh you don't need to, just `less -R` that file I linked
12:55 < cfields> │ -  3  0       0       0       <elf>.cpp
12:55 < cfields> │ +  3  0       0       0       bitcoin-cli.cpp
12:56 < cfields> Looks like it's either hitting a temp file or the real one...
12:56 < cfields> maybe something like -pipe ?
12:57 < cfields> I'd start by finding out what "<elf>.cpp" is a placeholder for. Since that's pretty clearly what it is, imo.
12:58 <@dongcarl> Okay cool, lemme upload a diffoscope of the output tarballs, for more context
13:01 <@dongcarl> cfields: It seems like the binaries record their $PWD in their directory table?
13:01 < cfields> dongcarl: aha, that'd be it.
13:01 < cfields> Well, close.
13:01 <@dongcarl> not exactly $PWD but...
13:01 < cfields> <elf>.cpp probably means "couldn't find this file in my search dir"
13:02 <@dongcarl> Right right
13:02 < fanquake> 🚀
13:02 < cfields> So, no clue what that means, but that seems like a reasonable starting point.
13:02 <@dongcarl> Ah so I just gotta normalize the $PWD
13:02 <@dongcarl> Lemme give it a go!
13:03 < cfields> Do the stripped files compare equal?
13:03 < cfields> I would think that might "fix" the problem by hiding it.
13:03 <@dongcarl> cfields: Oh as in the final output tarballs?
13:04 < cfields> │ -    <8d2>   DW_AT_name        : (indirect string, offset: 0xf22b): <elf>.cpp
13:04 < cfields> │ -    <8d6>   DW_AT_comp_dir    : (indirect string, offset: 0x3d4fb): /home/carl/bitcoin/distsrc-x86_64-linux-gnu/src
13:04 < cfields> │ +    <8d2>   DW_AT_name        : (indirect string, offset: 0xf270): bitcoin-cli.cpp
13:04 < cfields> │ +    <8d6>   DW_AT_comp_dir    : (indirect string, offset: 0x1191): /home/dongcarl/src/bitcoin/2019-01-guix/distsrc-x86_64-linux-gnu/src
13:05 <@dongcarl> 2:24:18 PM <@dongcarl> wumpus fanquake: Here's the link for Arch: https://www.dropbox.com/sh/f2gn7xde3016dhs/AABZfhUnoOdMPRvcxqLfuRAia?dl=0
13:05 <@dongcarl> 2:24:34 PM <@dongcarl> Here's the link for ubuntu: https://www.dropbox.com/sh/5qhp9uf8zdpqfln/AABhUSjrFII11NbnhBMQ_xw-a?dl=0
13:05 <@dongcarl> Final output tarballs ^
13:05 < cfields> dongcarl: hmm, I guess it could go either way. If the offset is large enough, I suppose that'd make it into the final tarball, and change the checksums at the same time.
13:05 <@dongcarl> Yeah lemme give it a go, we can at least narrow down
13:06 < cfields> dongcarl: I'd start by researching whether or not you can use relative source locations instead of absolute.
13:06 < cfields> Or... you probably already have a solution for that :)
13:07 <@dongcarl> cfields: relative source locations?
13:07 <@dongcarl> I was going to have guix just map the bitcoin dir to `/bitcoin` inside its build container
13:07 < cfields> binutils allows for paths like "$$PWD/foo.so". Something like that, I forget the exact syntax.
13:08 < cfields> dongcarl: that won't be debuggable, then :\
13:09 <@dongcarl> cfields: Oh I think I see what you mean...
13:09 <@dongcarl> cfields: Somehow have binutils refer to depends `.so`s in a relative fashion?
13:10 < cfields> That was just an example. I was implying that you could do the same with debug path locations.
13:10 < cfields> ideally those sources would be represented as "./bitcoin-cli.cpp", rather than "/foo/bar/bitcoin/src/bitcoin-cli.cpp"
13:11 <@dongcarl> cfields: Right, sorry I'm a little slow... How would I make them relative? Where best to start my search?
13:11 < cfields> dongcarl: no worries :)
13:12 < cfields> dongcarl: Start by reading up on how ld embeds debug source file location information.
13:12 < cfields> it may be as easy as adding a flag. Could be that there's no support at all and you have to use a hammer as suggested above.
13:12 < cfields> (as you suggested, that is)
13:13 < cfields> But my point was, since they allow relative locations for runtime lookup for things like rpath, it seems reasonable that debug sources could work the same way.
13:13 < cfields> It may also be possible to do some sort of splitdebug build, and allow the debug part to be non-deterministic.
13:13 < cfields> But that's ugly.
13:14 <@dongcarl> cfields: Oh I see, what you're saying is, the differences look like they're inserted for debug purposes, and are pointing to files with their full names to aid in debugging, if we somehow get the filenames to be inserted with relative names, we'd be deterministic.
13:14 < cfields> dongcarl: sorry, it may be gcc inserting the info into the objects at compile-time. I'd have to see where the problem was introduced.
13:15 < cfields> dongcarl: you're learning to translate my rambling braindump language!
13:15 < cfields> Yes, exactly that.
13:15 <@dongcarl> Haha yay!
13:15 < cfields> So, first step:
13:15  * dongcarl listening
13:15 < cfields> Narrow down where the problem is comfing from
13:16 < cfields> If the .o files differ, it's gcc. If it's only the final binaries, it'd ld.
13:16 < cfields> *it's
13:17 < cfields> Make sense?
13:17 <@dongcarl> cfields: Yes!
13:17 <@dongcarl> (just checked, it's gcc)
13:17 <@dongcarl> I compared `bitcoin_cli-bitcoin-cli.o`
13:18 < cfields> Ok, cool. Yep.
13:19 < cfields> So, right, dig deep and see if that's solvable. If not, see what it would take to add the feature. And at the same time, test out your hammer-fix.
13:19 < cfields> You might check and see what clang does on macos. Seems like something they'd have solved.
13:20 <@dongcarl> roger that
13:20 < cfields> (They've done lots of work on splitting debugging size/speed overhead out of release binaries)
13:21 <@dongcarl> cfields: Is clang generally nicer than gcc?
13:22 < cfields> dongcarl: the apple people tend to add real-world-useful stuff pretty quickly. I suppose they have less compatibility to worry about.
13:23 < cfields> the .tbd stuff is a pretty good example of that.
13:24 < cfields> But that's probably because they maintain their own linker.
13:24 <@dongcarl> cfields: Any ideas why the GNU people don't just copy these innovations?
13:24 < cfields> dongcarl: that's a bit too general to answer :)
13:25 < cfields> clang/llvm has definitely given gcc/gnu a kick in the pants in the last few years.
13:25 <@dongcarl> True
13:27 < cfields> If gcc can't embed relative paths, there's probably a perfectly good reason for it. But it may be like "this would be incompat with a 10yr old gdbserver" or something.
13:27 <@dongcarl> cfields: Looks like someone's already solved this problem: https://reproducible-builds.org/docs/build-path/
13:28 < cfields> dongcarl: yup, looks like that's exactly it :)
13:28 <@dongcarl> woohoo
13:29 < cfields> Might be a headache to use, but you're in the right place for sure.
13:31 <@dongcarl> cfields: Good luck with home office setup, and thanks for all the help (once again)
13:32 < fanquake> Indeed. I’m looking forward to re-reading all this.
13:32 < cfields> dongcarl: thanks :)
13:33 < cfields> fanquake: get some sleep some time!
13:34 < fanquake> cfields: hah. Still getting back into sync.
17:40 <@dongcarl> cfields: does .map files correspond to the tdb file you said clang had?
20:47 <@dongcarl> fanquake: Lol I feel like every time you post those hashes it taunts me to make reproducibility work ASAP
20:51 < fanquake> dongcarl hah. Sounds like there is plenty of progress being made anyways
23:27 -!- Netsplit *.net <-> *.split quits: wumpus
23:38 -!- Netsplit over, joins: wumpus
--- Log closed Sat Jun 15 00:00:47 2019