--- Log opened Thu Jul 16 00:00:22 2020
00:04 -!- jonatack [~jon@37.167.48.219] has joined #bitcoin-builds
01:30 -!- jonatack [~jon@37.167.48.219] has quit [Ping timeout: 265 seconds]
03:03 -!- Julian12Jaskolsk [~Julian12J@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-builds
03:31 -!- jonatack [~jon@37.167.121.211] has joined #bitcoin-builds
04:09 -!- jonatack [~jon@37.167.121.211] has quit [Read error: Connection reset by peer]
04:13 -!- Julian12Jaskolsk [~Julian12J@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds]
04:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
04:30 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Write error: Connection reset by peer]
04:31 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-builds
04:32 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
04:46 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-builds
05:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
05:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
06:00 < hebasto> meeting?
06:01 < willcl_ark> I'm trying to work out as part of https://github.com/bitcoin/bitcoin/issues/19388 what exactly breaks compiling the fuzz tests alongside the wallet, but struggling to determine what it is...
06:01 < willcl_ark> ah sorry, I won't interrupt a meeting!
06:01 < fanquake> hebasto: yea. Cory running ~5 mins late
06:02 < fanquake> dongcarl also missing heh
06:03 < hebasto> heh
06:03 < fanquake> Did you have any particular topics in mind? I have a couple, but they are rambly.
06:04 < hebasto> fanquake: while waiting for colleges could look the question in https://github.com/bitcoin/bitcoin/issues/18092 ?
06:04 < fanquake> Also becoming too used to Jitsi discussions, and less inclined to type out lots over IRC hah.
06:05 < fanquake> Sure. I think I've talked to Cory about that before. The short answer is yes it's currently done intentionally.
06:05 < hebasto> but why?
06:06 < hebasto> cannot grasp the reason of doing that
06:07 < fanquake> My understanding is that it was done so that user supplied C*-FLAGS can override the flags we choose
06:08 < hebasto> thanks
06:08 < hebasto> fanquake: another issue reported by you is https://github.com/bitcoin/bitcoin/issues/16391
06:09  * hebasto it is fixed by https://github.com/bitcoin/bitcoin/pull/18298
06:09 < hebasto> https://github.com/bitcoin/bitcoin/pull/18298
06:09 < cfields> Sorry I'm late! Here now.
06:09 < hebasto> mind looking into it?
06:10 < fanquake> Thanks. I've honestly been quite lax at looking at those PRs lately. Have been less-interested in GUI related changes.
06:10 < fanquake> However I'll make sure I look at it for you.
06:10 < fanquake> hi cfields
06:11 < hebasto> hi cfields
06:11 < cfields> hi :)
06:11 < fanquake> I see your cctools LTO changes just got merged: https://github.com/tpoechtrager/cctools-port/pull/85
06:11 < cfields> Heh, apparently 9am is too early for Carl
06:12 < hebasto> :)
06:12 < fanquake> Yea. Carls done a good job of setting this up. Not quite as good a job at turning up heh
06:12 < fanquake> Also just dropped you a Concept ACK in https://github.com/bitcoin/bitcoin/pull/19530. I'll atleast run through a build before actually ACKing.
06:13 < cfields> fanquake: oh, nice. That turned out to be a requirement for _all_ Ubuntu clang versions, not just for clang 10.0. Glad I jumped in there.
06:13 < cfields> Sure. Want to do a quick round of "chasing concept ACKs" ?
06:13 < cfields> Pretty sure I owe hebasto several as well.
06:13 < fanquake> I also managed to get my recent libevent changes in: https://github.com/libevent/libevent/pull/1048
06:14 < fanquake> Still a few followups left there though I think.
06:14 < cfields> nice :)
06:14 < fanquake> "Want to do a quick round of "chasing concept ACKs" ?" Sure. You starting?
06:16 < cfields> I'm the one who's way behind, how about hebasto starts :)
06:17 < fanquake> 👍
06:17 < hebasto> cfields: what is your opinion on https://github.com/bitcoin/bitcoin/issues/18092 ?
06:17 < cfields> hebasto: ok, so that's a bug, but a kinda complicated one.
06:18 < cfields> hebasto: you're right that it should be fixed. It's really annoying...
06:18 < hebasto> complication with propagation of flags?
06:19 < fanquake> Fixed in a way that will appease users want to override flags at compile time though I assume?
06:19 < cfields> Ok if I respond on the issue today? I'd rather gather my thoughts on that than get the details wrong in real-time.
06:19 < hebasto> thanks
06:19 < fanquake> My undertanding was that them being "overriden" from depends is very similar, if not the same as a user providing their own flags.
06:20 < fanquake> Although, will defer to reading your reply later, so we don't have to dive into it here.
06:20 < cfields> fanquake: yeah, it is. But you can _also_ supply your own flags on top, I believe. You can override the compilers at least.
06:21 < hebasto> And the latest thing from Qt building stuff is https://github.com/bitcoin/bitcoin/pull/18298
06:21 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-builds
06:21 < fanquake> Cool. I'm probably looking at doing some flag splitting to address a pthread related issue. So will good to have some clarification of how we want/think this should be working.
06:22 < hebasto> what "pthread related issue"?
06:23 < cfields> hebasto: Will review #18298.
06:23 < gribble> https://github.com/bitcoin/bitcoin/issues/18298 | build: Fix Qt processing of configure script for depends with DEBUG=1 by hebasto · Pull Request #18298 · bitcoin/bitcoin · GitHub
06:23 < dongcarl> hi all, sorry for the lateneess
06:23 < hebasto> hi dongcarl
06:23 < cfields> hi dongcarl
06:24 < hebasto> i'm done. next please
06:24 < fanquake> I'm planning on writing up a longer explanation. However the short of it is that due to how libtool builds shared libraries, and appends -nostdlib, when you try and link against pthread (atleast in our case), it doesn't actually work, and if we were to actually use pthread in a lib (like libconsensus) you end up with undefined symbols.
06:25 < dongcarl> fanquake: wouldn't this affect projects other than bitcoin too?
06:25 < cfields> fanquake: uhh, is pthread used in libconsensus??
06:25 < fanquake> dongcarl: yes it has done. There are threads from 2005 discussing something similar
06:26 < fanquake> cfields: it's not, but was build it using the pthread_clfags
06:26 < fanquake> and Clang complains. I figured out the above when digging into that.
06:26 < cfields> fanquake: ah ok, let's fix that while we're at it too.
06:26 < fanquake> I have an example where if you "were" to introduce a symbol, like pthread_create, into libconsensus, things start breaking.
06:27 < fanquake> Obviously not something we'd want to do, but I want to clean up an ambiguity, and remove the warnings.
06:27 < fanquake> *any
06:27  * fanquake should have finished his gist
06:27 < cfields> fanquake: same issue as this? https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L603
06:28 < fanquake> cfields: yea similarish
06:28 < dongcarl> yall continue with the convo, at some point we should recall the action items decided upon while I was away
06:28 < fanquake> I'm not sure if we used the same hack for the windows dll for linux share lib, wether it would fix it or not.
06:29 < cfields> I really wish libtool would just use a standard link. I believe the -nostdlib stuff is a relic of old old hacks.
06:29 < fanquake> However I think the better approach is  to just skip compiling with pthreads there, given we don't use them.
06:29 < cfields> fanquake: for sure.
06:29 < fanquake> Yea, the explanations I found for why nostddlib is used were basically, stuff decades ago was kinda broken/done a bit weird, hence there's a hack.
06:30 < fanquake> end pthreads and libconsensus
06:30 < cfields> Right. I think compiler front-ends have taken on a good bit of libtool's original functionality.
06:31 < dongcarl> fanquake: Perhaps worth posting on libtool mailing list too
06:32 < cfields> fanquake: it'd be nice to break the pthread flags out just for the purpose of documentation. That way we can add threading selectively only where it's needed.
06:32 < fanquake> dongcarl: I'll collect my thoughts and figure out where to send the relevant info hah
06:32 < fanquake> cfields: Yea. That is also another good reason break it up.
06:33  * fanquake runs to get his tea
06:33 < cfields> dongcarl: got some action items for us?
06:34 < cfields> dongcarl: I don't see much in the scrollback, not sure if I missed something.
06:34 < dongcarl> Okay no worries, I just want to make sure that if someone says "we should open an issue about this" we don't miss it
06:35 < dongcarl> cfields: did you have anything you wanted to talk about?
06:35 < fanquake> I have one topic. There are two approaches I can take to solve #19522 (which is actually something I broke ~4 years ago).
06:35 < gribble> https://github.com/bitcoin/bitcoin/issues/19522 | build: fix building libconsensus with reduced exports for Darwin targets by fanquake · Pull Request #19522 · bitcoin/bitcoin · GitHub
06:36 < fanquake> oops. cfields you first.
06:37 < cfields> Maybe we can discuss some of the performance/stack flags fanquake has been working on for a while. I was ignoring those until catching up on the status of LTO. I think maybe we should discuss in that context.
06:37 < cfields> fanquake: you first, my topic is a little vague.
06:37 < cfields> Looking at 19522.
06:38 < fanquake> Basically I'd like to know if everyone prefers keeping the macro, and modifying it (as it used to be), or bringing the visibility checks into configure. We have a check in there currently, but it's never actually been used.
06:39 < fanquake> The PR currently brings the checks into configure, removes the macro, and make some other small changes. However the alternative approach is to continue using the macro, remove the visibility check of ours that we don't actually use, and also make the other small changes.
06:39 < cfields> fanquake: I'm not opposed to bringing them in. I know visibility was broken in the past because the macro tried some weird value as part of the check...
06:39 < hebasto> fanquake: i think dropping macro is ok
06:40 < fanquake> Yes. The macro in its  unmodifed form doesn't work with Clang, because it checks for protected, and another visibility that Clang doesn't support.
06:40 < cfields> Ugh! That's still the issue??
06:40 < fanquake> As of the latest version of the macro upstream, that is still an issue yes
06:40 < cfields> fanquake: we can share the blame, then :(. I knew that years ago but assumed it wouldn't be a problem in future clangs.
06:41 < fanquake> heh. You patched around it by dropping the checks, and I re-broke it by updating the macro.
06:41 < cfields> Ah, ok.
06:41 < fanquake> Note that in it's current form, I'm also dropping any checking for dllimport.
06:42 < fanquake> As in libconsensus we only check wether MSC_VER is defined before using it. Not sure if that is something we want to change?
06:42 < fanquake> I'd like to think we can pretty safely assume that if the compiler is MSVC we can use dllimport.
06:43 < cfields> Sorry, back in 1min.
06:45 < dongcarl> fanquake: sorry I'm ill informed on this topic but is there a functional difference between using the macros and bringing them into configure.ac?
06:46 < cfields> sorry, back.
06:46 < fanquake> dongcarl: for our purposes, essentially no. The checks we'd be performing in configure would basically be the same, except that we'd make sure they work for Clang.
06:46 < fanquake> I feel like I've said Yes and No in the one sentence there.
06:47 < cfields> dongcarl: the macro is intended to be generic enough to work for any attribute, but attribute are _just_ messy enough that it ends up not working often enough.
06:47 < dongcarl> fanquake: If upstream doesn't seem to want to improve upon the macro to work for our cases, we should just do our own
06:47 < fanquake> Yes. Most of these macros are also marginally geared towards working with GCC, rather than Clang.
06:47 < dongcarl> cfields: that would make sense
06:47 < dongcarl> fanquake: is there an upstream macro repo for clang too?
06:48 < fanquake> I'm not sure, but I wouldn't think there'd be a Clang-only version anywhere.
06:48 < fanquake> Our upstream is currently: https://github.com/autoconf-archive/
06:49 < dongcarl> I feel like one of the main reasons we use upstream repo macros is so that we can get the benefits of other people's build system debugging, if that stops being true and starts being a burden, then we should just do our own thing.
06:49 < cfields> Another option would be handling this stuff outside of autoconf in attributes.h
06:50 < fanquake> cfields: this specific case, or are you talking more generally?
06:50 < dongcarl> cfields: but our goal is to do feature detection instead of special-case-for-compilers-then-compiler-versions, no?
06:51 < cfields> fanquake: The c++ language itself has been improving detection of attributes.
06:51 < cfields> dongcarl: sure, but iirc there are new tests like __has_attribute that do feature-testing in the pre-processor.
06:52 < dongcarl> oh cool!
06:52 < fanquake> I think I'll close out the #19522 discussion here, so we can get to other topics. If everyone is ok with the macro dropping approach, I'll take any Concept ACKs.
06:52 < gribble> https://github.com/bitcoin/bitcoin/issues/19522 | build: fix building libconsensus with reduced exports for Darwin targets by fanquake · Pull Request #19522 · bitcoin/bitcoin · GitHub
06:52 < cfields> dongcarl: https://en.cppreference.com/w/cpp/feature_test
06:53 < cfields> Ugh, c++20 :\
06:53 < dongcarl> cfields: Haha let's table it for C++20 then
06:53 < cfields> fanquake: will concept ack dropping the macro. Completely agree.
06:54 < fanquake> cool. Only other recent PR I have is #19522. I think that can go in as-is, and I'll circle back to writing a test later on.
06:54 < gribble> https://github.com/bitcoin/bitcoin/issues/19522 | build: fix building libconsensus with reduced exports for Darwin targets by fanquake · Pull Request #19522 · bitcoin/bitcoin · GitHub
06:54 < fanquake> ugh. #19525
06:54 < gribble> https://github.com/bitcoin/bitcoin/issues/19525 | build: add -Wl,-z,separate-code to hardening flags by fanquake · Pull Request #19525 · bitcoin/bitcoin · GitHub
06:55 < fanquake> Must be time for a cfields topic
06:56 < cfields> lto?
06:56 < fanquake> 🚀
06:56 < dongcarl> lto!
06:57 < fanquake> #19530
06:57 < gribble> https://github.com/bitcoin/bitcoin/issues/19530 | depends: build LTO support into Apples ld64 by theuni · Pull Request #19530 · bitcoin/bitcoin · GitHub
06:57 < cfields> shit, sorry guys, i've g2g.
06:58 < hebasto> how to test it?
06:58 < dongcarl> hebasto: I guess just "-flto"
06:59 < dongcarl> fanquake: Your hardening flags thing reminds me that we should build benchmarking into DrahtBot
06:59 < dongcarl> Or maybe it can be a "benchbot"
06:59 < hebasto> I mean how to catch that binaries differ in right way
07:00 < cfields> I'm afraid I need to take my cat to the emergency clinic. I'll follow up with an LTO issue later today.
07:00 < fanquake> dongcarl: yea, can we hook up perfmonitor into it somehow?
07:00 < fanquake> cfields: hope it's ok!
07:00 < dongcarl> cfields: best of luck!
07:01 < dongcarl> Okay
07:01 < dongcarl> It's been an hour
07:02 < fanquake> hebasto: I think the easiest answer to that is running a full sync of bitcoind and ensuring all of the unit tests pass
07:02 < dongcarl> So we can disband for now, hebasto did you have anything else you wanted to bring up?
07:02 < hebasto> dongcarl: there were only two items from me, already discussed
07:03 < hebasto> #18092 and #18298
07:03 < gribble> https://github.com/bitcoin/bitcoin/issues/18092 | build: CXXFLAGS with depends · Issue #18092 · bitcoin/bitcoin · GitHub
07:03 < gribble> https://github.com/bitcoin/bitcoin/issues/18298 | build: Fix Qt processing of configure script for depends with DEBUG=1 by hebasto · Pull Request #18298 · bitcoin/bitcoin · GitHub
07:03 < dongcarl> hebasto: got it
07:03 < dongcarl> For me, I just need https://github.com/bitcoin/bitcoin/pull/17919 in soon, I think it's fairly uncontroversial
07:03 < fanquake> dongcarl: I was going to ask you about dropping the [wip] commit, however I see that's been done
07:04 < fanquake> I think I can merge that now
07:04 < dongcarl> fanquake: dope!
07:04 < fanquake> Don't want to block the macOS / Guix progress for 0.21.0
07:04 < dongcarl> woohoo
07:05 < dongcarl> lots to do
07:05 < hebasto> if anyone have time for riddles mind looking into https://github.com/bitcoin-core/gui/issues/33 ?
07:05 < hebasto> smth strange with Qt static linking...
07:06 < dongcarl> Huh weird, thanks for bringing it up
07:06 < dongcarl> If nothing else I'll endmeeting
07:06 < hebasto> thanks
07:06 < fanquake> hebasto: interesting. Do you think it's more likely a Qt problem, or an issue with out configuration or similar?
07:07 < hebasto> digging into it the second day... have no clue
07:07 < fanquake> I will subscribe to that thread for updates
07:07 < dongcarl> Sounds like we got a plan
07:08 < dongcarl> #endmeeting
07:08 < dongcarl> hebasto fanquake thanks for joining again, and I apologize for my lateness
07:08 < fanquake> dongcarl: no worries
07:08 < dongcarl> thanks especially to those of us in a timezone where it's late right now
07:09 < dongcarl> cya on the interwebs
07:11 < willcl_ark> So I have been trying to get the fuzz tests to compile alongside the wallet and rest of the standard targets as part of #19388 and was wondering if anyone knew the fundamental reason linking gets broken when I enable both targets as the same time?
07:11 < gribble> https://github.com/bitcoin/bitcoin/issues/19388 | Build fuzz tests by default · Issue #19388 · bitcoin/bitcoin · GitHub
07:12 < willcl_ark> I have tried dumping the symbols generated by the makefile in both cases and diff-ing them, but my build skills are not quite good enough to dechipher what is actually wrong during linking
07:14 < fanquake> willcl_ark: I don't have an answer for you now, but can take a look at your branch once I'm up tomorrow.
07:15 < fanquake> I assume this is the current changeset: https://github.com/willcl-ark/bitcoin/tree/default_fuzz_tests
07:15 < willcl_ark> Thanks fanquake that would be great! Ill push a rebased version in a sec. Going to leave the changes in a few commits that I would hope to squash, so you can see more easily what I've done
07:15 < willcl_ark> yeah that's the branch
07:18 < fanquake> willcl_ark: cool 👍
07:19 < willcl_ark> ah I'm not gunna rebase, it's not going to make any difference :) let me know if you spot something; i'm hoping it's somethign easy/obvious!
07:24 < fanquake> cfields: just tested building your cctools LTO branch. It bombs out when linking genisoimage.
07:24 < fanquake> ld: CMakeFiles/genisoimage.dir/apple.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here. <-- Multiple errors similar to this.
07:24 < fanquake> I'll take another looks tomorrow.
07:26 -!- Davterra [~tralfaz@89.45.90.114] has quit [Quit: Leaving]
07:35 < cfields> Sorry for not being very present today's meeting. Looks like we're making an emergency trip, so I'm afraid I'll have to push back the stuff I said I'd get to today.
07:37 -!- Davterra [~tralfaz@104.200.129.62] has joined #bitcoin-builds
07:39 < dongcarl> cfields: no worries hope your cat is alright!
07:56 -!- Netsplit *.net <-> *.split quits: MarcoFalke, meshcollider
07:57 -!- Netsplit over, joins: meshcollider, MarcoFalke
09:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
09:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-builds
10:04 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
10:11 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-builds
10:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
10:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-builds
11:42 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
11:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
11:46 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-builds
11:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-builds
12:37 < cfields> Looks like our cat's going to be ok.
12:37 < cfields> That was really shitty timing during today's meeting, I'm happy to do another whenever...
12:37 < cfields> let's organize some topics ahead of time, though :)
12:37 < cfields> fanquake: fwiw, I haven't tested adding "-flto" to depends, which I suspect is what you tried there.
12:37 < cfields> My only testing so far was compiling core itself with -flto .
13:23 < midnight> My current attempt to gitian build v0.20.0 is missing an osslsigncode-2.0; is it pulled in by some step I'm clearly missing? "tar: osslsigncode-2.0.tar.gz: Cannot stat: No such file or directory"
13:24 < midnight> nvm, found my answer.
13:24 < midnight> \o
13:26 < midnight> (benefits of using my own gitian builder)
13:52 < midnight> Oh, i see.. it *appears* as though osslsigncode's existence in inputs/ is only handled by the python gitian builder; and it is not satisfied by a make -C bitcoin/depends download run..
13:52 < midnight> fanquake: Out of curiosity, why does the gitian-builder.py retrieve osslsigncode directly with wget and osslsigncode is not part of the make download portion of the inputs/* satisfaction?
15:13 < fanquake> cfields: that was just after checking out your branch and running make -C depends for a Darwin target. Wasn’t passing any additional flags. I’ll retry today.
15:15 < fanquake> midnight: the python script is much newer than depends, I assume it got thrown in there as a convenience. I assume we could include it as part of a depends download.
15:16 < midnight> fanquake: No big deal. It's very very easy to find, so I could match up my build script within (looks up) about 1m47s. I just figured, well, usually there's a reason for these kinds of things.
15:43 < cfields> It's somewhat arbitrary. It's only needed for an optional packaging step. So it doesn't make a ton of sense in depends...
15:43 < cfields> But then again, some macos packaging stuff _is_ in depends.
15:45 < fanquake> Could be a lot less if #19068 gets in heh.
15:45 < gribble> https://github.com/bitcoin/bitcoin/issues/19068 | build: Use a zip instead of dmg for macOS releases by fanquake · Pull Request #19068 · bitcoin/bitcoin · GitHub
16:16 -!- Netsplit *.net <-> *.split quits: MarcoFalke, meshcollider
16:22 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-builds
16:22 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-otyqznegmsqkmiol] has joined #bitcoin-builds
--- Log closed Fri Jul 17 00:00:22 2020