--- Log opened Wed Nov 20 00:00:14 2019
00:40 -!- davterra [~dulyNoded@195.242.213.120] has quit [Ping timeout: 265 seconds]
00:41 -!- davterra [~dulyNoded@195.242.213.120] has joined #bitcoin-builds
05:00 < MarcoFalke> So how would I build Bitcoin Core against musl?
05:00 < fanquake> Spin up an Alpine container?
05:01 -!- dawggo12 [~Android@185.92.26.211] has quit [Ping timeout: 240 seconds]
05:02 < fanquake> https://github.com/fanquake/core-review/blob/master/docker/alpine.dockerfile
05:02 < MarcoFalke> Ok, I guess I should make the ci system work with alpine
05:02 < MarcoFalke> Can I do it in Ubuntu as well?
05:02 < MarcoFalke> [08:02] <wumpus> I suppose it's pretty much impossible to do that on ubuntu ,though
05:03 < fanquake> Heh, maybe using that wrapper
05:04 < MarcoFalke> Yeah
05:04 < wumpus> TIL there's a wrapper, this is very cool
05:06 -!- dawggo12_ [~Android@185.92.26.211] has joined #bitcoin-builds
05:14 < wumpus> it looks like the wrapper only works for C, not C++
05:16 < wumpus> it's super easy to get to work, installing from source takes 45 seconds or so on my old desktop; but it's no help for bitcoin if it's C only, there's no musl-g++ wrapper
05:23 < wumpus> "Be aware that, "out of the box", the wrapper only supports C applications, not C++. This is because the C++ libraries and headers are missing from the musl include/library path. The existing libstdc++ is actually compatible with musl in most cases and could be used by copying it into the musl library path, but the C++ header files are usually not compatible. One option may be rebuilding just
05:23 < wumpus> libstdc++ against musl; however, if C++ support is needed, it's recommended just to build a native toolchain targetting musl. "
05:25 -!- _jerry [~jerry@47.55.112.140] has joined #bitcoin-builds
05:29 -!- jonatack [~jon@213.152.161.25] has joined #bitcoin-builds
05:35 < wumpus> I guess there's no way around using something like alpine linux
05:40 -!- dawggo12_ [~Android@185.92.26.211] has quit [Ping timeout: 240 seconds]
05:42 -!- dawggo12 [~Android@185.92.26.211] has joined #bitcoin-builds
05:45 -!- _jerry [~jerry@47.55.112.140] has quit [Ping timeout: 240 seconds]
06:22 < wumpus> effetctively, building C++ for musl requires a full cross toolchain; using a cross-compilation toolchain for the native platform, might be advantageous from a determinism perspective though
06:26 < wumpus> insulated the build from what happens to be installed on the system
07:04 < wumpus> dongcarl cfields what do you think about switching linux builds to musl libc static builds?
07:10 < wumpus> it has the advantage that the binaries work pretty much everywhere instead of only on a limited range of libc versions, and it's starting to be untenable to maintain libc compatibility this far back
07:17 < dongcarl> not opposed... with Guix we won't have to maintain libc compatibility, since we won't be forced to upgrade libc version by ubuntu... but I do see the binary works everywhere advantage
07:18 < wumpus> sure, you can build against a old libc version instead of the libc-compat workaround, but you'd have just as much trouble supporting getauxval
07:19 < wumpus> it doesn't exist in 2.11 no matter how you build against it
07:20 < dongcarl> when did getauxval get introduced?
07:20 < fanquake> In the latest randomness changes.
07:20 < wumpus> sipa's static randomness patch uses it, and leveldb 1.22+ does too
07:20 < wumpus> there's really no way around supporting it
07:21 < wumpus> it's pretty much the only way to query CPU caps on non-x86
07:22 < wumpus> and it has existed since 2012 or so
07:22 < dongcarl> I see... And even if I build against glibc 2.27, it's gunna break our check-symbols.py?
07:22 < wumpus> yes
07:22 < dongcarl> since we don't have compat hooks for it?
07:22 < fanquake> Yea it would definitely be nice if we could use things that have existed for 7 years..
07:34 -!- jonatack [~jon@213.152.161.25] has quit [Ping timeout: 240 seconds]
07:54 < wumpus> I guess the problem is that in case of the Qt build, we can't link everything statically, there's some system libs such as fontconfig and X11 libraries that need to be linked dynamically
07:55 < fanquake> Me and Cory discussed briefly is the possibility of passing -nodlopen for bitcoind, now that OpenSSL is gone
07:55 < wumpus> ofc, distributing portable GUI applications is even worse than command line applications for Linux
07:55 < fanquake> As I assumed that would have been the last thing using that if anything.
07:56 < wumpus> for *bitcoind* that's definitely posisble now
08:06 -!- jonatack [~jon@89-93-131-92.hfc.dyn.abo.bbox.fr] has joined #bitcoin-builds
09:14 -!- dawggo12 [~Android@185.92.26.211] has quit [Ping timeout: 250 seconds]
09:15 -!- dawggo12_ [~Android@035-133-237-096.res.spectrum.com] has joined #bitcoin-builds
10:22 -!- davterra [~dulyNoded@195.242.213.120] has quit [Ping timeout: 276 seconds]
10:22 -!- davterra [~dulyNoded@195.242.213.120] has joined #bitcoin-builds
10:39 < fanquake> I don't see libanl.so.1 or libatomic.so.1 in the symbol checker output for the 0.19.0.1 linux release binaries.
10:51 < fanquake> actually libatomic.so.1 is in the risvc binaries
10:53 < dongcarl> ATTN: Informal meeting in 7 mins if people wanna join
10:56 < cfields> wumpus: I've been curious about that for a long time.
10:57 < cfields> especially with static pie.
11:00 < fanquake> cfields: is it possible we no longer use/require libanl.so.1 ?
11:00 < dongcarl> AC_START(MEETING)
11:00 < fanquake> guess I'll save that discussion heh
11:01 < dongcarl> hi guys
11:01 < dongcarl> good to have everyone here
11:01 < fanquake> hi Carl
11:01 < cfields> fanquake: possible, it could've been required by getaddrinfo_a, which we dropped.
11:01 < dongcarl> So fanquake how much has the OSX bump PR changed?
11:02 < fanquake> cfields: ok. I can't see it in any of the gitian linux binaries for 0.19.0.1
11:02 < fanquake> dongcarl: not much at the moment. Basically waiting on this discussing before touching anything cctools related again
11:02 < fanquake> I'll split out the 10.12 minimum bump, as that can happen separately.
11:03 < cfields> fanquake: -Wl,--as-needed should drop it if it's not used. Pretty sure we use that for gitian builds.
11:03 < cfields> (wrt libanl)
11:03 < fanquake> cfields: ok. I'm just thinking if it's unused I'll remove it from the allowed libraries in the symbol checker
11:03 < fanquake> I'll just make sure first.
11:03 < cfields> Ah, gotcha
11:03 < dongcarl> Cool, cfields We don't use as-needed for gitian
11:04 < dongcarl> We should tho
11:04 < MarcoFalke> #proposedmeetingtopic: Use native clang for macos depends build
11:04 < cfields> hmm, I swear we used to?
11:04 < cfields> anyway, not relevant now :)
11:04 < dongcarl> Let's talk about using native clang
11:04 < fanquake> Only place I see as-needed is in the guix script heh
11:04 < MarcoFalke> \o/
11:04 < dongcarl> last time I remembered that we were somewhat okay with it?
11:05 < dongcarl> I believe cfields said he wanted to chew on it a little
11:05 < dongcarl> this is also orthogonal to us switching to llvm tools
11:05 < fanquake> I think there's been some chewing going on
11:05 < cfields> As long as cctools is required, it needs to be pinned to a clang.
11:06 < cfields> I'm just not comfortable removing that requirement. This is not a supported toolchain by a long shot. We shouldn't treat it as though it's any ordinary released tools.
11:06 < cfields> Now
11:07 < cfields> We can come up with a hack to allow guix to specify its own. I have no problem with that at all, if that's the _real_ goal here.
11:07 < cfields> Let's just be specific about actual goals.
11:07 < MarcoFalke> I can't build macos on let's say aarch
11:08 < MarcoFalke> because the hardcoded clang is x86_64
11:08 < dongcarl> For me, that's the actual goal, but I also think the user should be able to specify that they want to use their system clang
11:08 < cfields> dongcarl: we have no reason to believe/suspect that's a reliable combo.
11:09 < MarcoFalke> Can we pin it to the clang version in Bionic? Is that too fragile?
11:09 < cfields> Now, if/when we can use a shipped clang+llvm-ar+lld, that's a different story.
11:09 < cfields> Bionic?
11:10 < cfields> Oh, heh, sorry...
11:10 < cfields> every time you say that I think you mean the libc :)
11:11 < dongcarl> How about FORCE_USE_SYSTEM_CLANG_DANGEROUS_I_KNOW_WHAT_IM_DOING=1 or something like that
11:11 < cfields> dongcarl: but system clang isn't what you want.
11:11 < cfields> You want to specify your clang. You just want to be lazy about it :)
11:12 < cfields> (by using your inherited env, which makes "clang" do the right thing)
11:12 < dongcarl> Right, I want to just specify my clang, and if I specify my clang, I don't wanna download the llvm binary
11:13 < dongcarl> Is that possible to do?
11:13 < cfields> dongcarl: right.
11:13 < cfields> dongcarl: how about like a x86_64-apple-guix-darwin16 target?
11:14 < dongcarl> cfields: Eh, I'd like to not introduce a non-standard triple into the mix
11:14 < cfields> and MarcoFalke, we can get smarter about fetching for the correct build platform.
11:15 < cfields> MarcoFalke: ofc ideally we'd be building clang from source to avoid the issue entirely :)
11:15 < MarcoFalke> Yeah, I guess I can adjust the URL
11:15 < dongcarl> cfields: okay but this is all pointless if we can get the llvm tools working correct?
11:15 < cfields> dongcarl: yup. So I'd like to think these are temporary workarounds.
11:16 < fanquake> cfields figure anything more in regards to the tbd stubs
11:16 < cfields> dongcarl: let me clarify why I think it would be moot at that point...
11:16 < cfields> fanquake: so tactful :)
11:16 < fanquake> I'll not interrupt since you're on a role heh
11:18 < dongcarl> my guess is that llvm tools are tested against their clang counterparts so there's somewhat of a guarantee for compatibility, whereas cctools is mostly only tested with one version of clang, and there might be subtle bugs with version-crossing that no one in the world is aware of/has encountered
11:19 < cfields> dongcarl: the problem right now is that we're using a toolchain comprised of multiple completely disconnected parts. Namely clang and ld64. The problem with that is that fixes for one may be deployed in the other. For example, it's easy to imagine inserting a bugfix in lld to workaround a broken compiler release. With those two out of sync, we have zero idea how trustworthy the result is. The system is a black-box that we throw code into, if
11:19 < cfields>  the release runs, we ship it.
11:19 < cfields> yup!
11:20 < dongcarl> cfields: Based on your current exploring, do you think switching to llvm tools is an achievable goal?
11:20 < cfields> My argument is that we can only aim to support a single black box.
11:20 < fanquake> There's also the problem of cctools being maintained by basically one person, in a fairly ad-hoc way
11:20 < fanquake> *cctools-port
11:20 < cfields> right, what fanquake said too.
11:21 < cfields> dongcarl: right, ok, there's at least one big, huge, giant caveat for llvm tools: lld doesn't yet support .tbd files, which are how shared libs are represented in MacOS SDKs since 10.11.
11:21 < cfields> :(
11:22 < cfields> So, my (still very limited) testing has been against the 10.10 sdk so far.
11:22 < cfields> https://lists.llvm.org/pipermail/llvm-dev/2017-September/117264.html
11:23 < cfields> Looks like that never materialized. Or at least, hasn't made it into a relase.
11:23 < cfields> *release.
11:24 < fanquake> cfields: You mentioned patching as a potential path. Is that actually realistic?
11:24 < cfields> Also, my tests show that I can link a binary containing a .o and a .a (created with llvm-ar), which works. But linking bitcoind, built with a hacked up depends, segfaults. I still need to explore what's up with that.
11:25 < fanquake> I guess it's "black-boxy" but we're more in control of the box?
11:25 < dongcarl> so we won't have it because it doesn't have support for tbd files?
11:25 < cfields> fanquake: If that's the _only_ hold-out, I would say it would be worth seeing if we could find someone to do that, yes.
11:25 < dongcarl> patching?
11:25 < cfields> dongcarl: adding the tbd support to lld and upstreaming.
11:26 < cfields> but lld still can't link bitcoind, which leads me to believe that macos support may not be all that robust yet.
11:26 < cfields> Need to explore a bit more.
11:26 -!- jonatack [~jon@89-93-131-92.hfc.dyn.abo.bbox.fr] has quit [Ping timeout: 276 seconds]
11:27 < cfields> For now, sounds like we could make everyone happy-ish if we added a hack for guix, and fixed up non-x86 builds for MarcoFalke ?
11:27 < fanquake> Have to keep the Guix train on the rails
11:27 < MarcoFalke> Should these fixes go into the clang-9 bump by fanquake?
11:28 < dongcarl> Yeah I'd be alright with that
11:29 < dongcarl> Curious why gentoo has tapi packaged: https://packages.gentoo.org/packages/sys-libs/tapi
11:29 < cfields> There's a bunch flying around that I haven't really looked at in a while. You guys drive, and just point me at stuff to review :)
11:29 < fanquake> There's this one of mine https://github.com/bitcoin/bitcoin/pull/16392
11:29 < fanquake> Which I'm going to split the 10.12 bump out of, and bump the 10.14 SDK to the 10.15 SDK.
11:30 < dongcarl> Did we figure out which clang version matched our cctools version/
11:30 < dongcarl> ?
11:30 < fanquake> Sounds The question is settling on a clang/cctools-port/ld64/tapi version for that
11:30 < fanquake> There's now a slightly newer cctools-port+ld63 combo available.
11:30 < fanquake> (than what's in that PR)
11:31 < cfields> I have no preference as long as they line up in some way.
11:31 < cfields> fanquake: iirc the newer cctools would be better aligned with our clang, no?
11:31 < fanquake> The newer one is 927.0.2-ld64-450.3
11:31 < cfields> Er, with whatever clang you had chosen.
11:32 < fanquake> I've currently picked 6.0.1. I'll confirm how well that lines up.
11:32 < fanquake> *Clang 6.0.1
11:33 < dongcarl> how are you confirming how well that lines up?
11:33  * dongcarl curious
11:33 < cfields> dongcarl: ok, and I'll come up with a hack for you asap.
11:33 < fanquake> dongcarl I'm pretty sure I could look it up, now I'm trying to remember where that was
11:34 < dongcarl> cfields: Sounds good on that front, you can reference the last few commits here https://github.com/bitcoin/bitcoin/pull/17099 to see what I was trying to achieve
11:34 < cfields> dongcarl: curious, not that this is a real fix, but would doing an "export /path/to/guix/stuff/clang/bin:$PATH" before a gitian build not be enough?
11:34 < cfields> I'm trying to figure out how to best hack it in.
11:35 < fanquake> So it looks like cctools 927.0.2 ld64-450.3 would line up ~ with Clang 7
11:35 < cfields> oh, shit, I need to sign 0.19.0.1 :\
11:36 < dongcarl> cfields: Wouldn't we still download clang in that case?
11:36 < cfields> Completely slipped my mind this time, somehow. Doing now.
11:36 < fanquake> 921.0.1 409.12 for Clang 6.0.1
11:36 < cfields> dongcarl: sure. But generally, would a path prefix do the job? Or do you need separate paths for different tools?
11:36 < fanquake> So I could actually stay on the version of cctools and ld64 currently in that PR, and not pull in the latest changes, if we're happy to stick with Clang 6.0.1
11:37 < dongcarl> cfields: sorry but I'm not 100% sure what you mean...
11:38 < dongcarl> fanquake: I'm fine with either, I don't see any particular reason to bump right now
11:39 < dongcarl> Also, did anything come of the libc++ header diffing?
11:39 < fanquake> dongcarl Righto. We're going to do Clang 6.0.1, cctools 921.0.1, ld64 409.12 and libtapi 1000.10.8
11:39 < cfields> dongcarl: when you say "system clang" you just mean that you want "clang" "ld" "ar" to *just work*, right? Meaning no specifying "my-system-triplet-clang" or "/my/depends/path/to/clang", just clang.
11:39 < cfields> dongcarl: basically, same as gcc.
11:39 < fanquake> and the 10.15 SDK. Bumping minimum required macOS to 10.12
11:39 < cfields> Is that correct?
11:40 < ryanofsky> re gentoo tapi: it might have been for https://wiki.gentoo.org/wiki/Project:Prefix
11:40 < dongcarl> cfields: I don't really mind setting darwin_CC or darwin_LD to some full path actually
11:41 < cfields> dongcarl: would those be in separate places? Ideally?
11:41 < dongcarl> But yes, it would be preferable to use just "clang" "ld" "ar" and have them just work like gcc
11:41 < cfields> Or you'd just prefer just more explicitly stated paths?
11:44 < dongcarl> Let's do "make the first clang in my path work and not download the clang from llvm just like gcc"
11:45 < dongcarl> Here's how I coded it up: https://github.com/bitcoin/bitcoin/compare/b05279271975b9123833d5eb2ea99b2a06230f47...0d3f3428c948f5f723addacfc68f3570436392b3
11:45 < cfields> dongcarl: roger, thanks.
11:46 < dongcarl> Thanks, sorry if I'm being confusing
11:46 < fanquake> I think this was a successful meeting
11:46 < dongcarl> Oh yeah, lots discussed...
11:46 < dongcarl> Wait one more thing
11:46 < dongcarl> btw ryanofsky thanks I'll look into that
11:47 < dongcarl> one more thing...
11:47 < cfields> dongcarl: No worries, I think I'm probably asking conflicting questions too.
11:47 < dongcarl> Did we get anything out of the c++ headers comparison?
11:47 < cfields> Oh, right!
11:47 < cfields> Anyone do that? :)
11:47 < fanquake> I did not
11:48 < fanquake> If you tell me what you'd like to have done I will commit to it.
11:48 < dongcarl> Well the main question I wanna answer there
11:48 < dongcarl> Is if we should put it in the SDK
11:48 < dongcarl> like in https://github.com/tpoechtrager/osxcross/blob/master/tools/gen_sdk_package.sh#L183-L188
11:48 < ryanofsky> dongcarl, it's not too interesting, basically gentoo prefix is to gentoo as nix is to nixos
11:49 < fanquake> dongcarl right. So what are we diffing?
11:49 < dongcarl> I sent the tarball over to you guys
11:50 < fanquake> Ah ok
11:50 < dongcarl> I think cfields requested it, but I'm not 100% sure what for
11:51 < cfields> dongcarl: there was a brief question of which we should be using, libc++'s version, or the apple SDK's version. I've come around to the idea of using the SDK's version, but I'm also really curious as to what actually differs.
11:52 < fanquake> Guess than can all be revealed at next weeks meeting
11:52 < dongcarl> sounds good
11:53 < dongcarl> thanks all
11:53 < cfields> :)
11:53 < fanquake> I'll also through https://github.com/bitcoin/bitcoin/pull/17538 into the mix as something to think about before then.
11:53 < fanquake> thanks!
11:54 < fanquake> gitian builds are broken after the introduction of getauxval (in random), but it'll also be required for the leveldb bump.
11:54 < dongcarl> Dope
11:54 < dongcarl> Thanks for working on that
11:55 < fanquake> I'll open up a PR to remove libanl from our allowed symbols too. 99% sure it's uneeded after https://github.com/bitcoin/bitcoin/commit/10ae7a7b2316f8052ec58ef237ce6dd987300900
11:56 < fanquake> Can't see it any of the 0.19.0.1 gitian binaries. i.e https://gist.github.com/fanquake/9ce5ab30280f60f747b3dc68c2cfd423
11:56 < dongcarl> Dope
11:56 < cfields> fanquake: aha, yup, that should've done it :)
11:57 < fanquake> Cool. Thanks everyone.
11:58 < cfields> fanquake: aha, we add: -Wl,--exclude-libs,ALL
11:58 < cfields> That's what I was trying to say when I said -Wl,--as-needed
11:59 < fanquake> cfields ah ok
11:59 < fanquake> I see it in configure.ac
12:00 < cfields> I think that should result in not linking against libs that don't pull in any symbols.
12:02 < dongcarl> cfields: what's the diff between those two flags?
12:06 < cfields> dongcarl: iirc exclude-libs controls our exported symbols, such that we don't export much more than main(). That means that the linker can make better decisions. To oversimplify: if a lib has no symbols with a logical path to main(), it can be dropped.
12:07 < cfields> I believe you could achieve something similar with "-Wl,--as-needed -lanl -Wl,--no-as-needed"
12:07 < cfields> IIRC you can't just use --as-needed without a "closing" "no-as-needed", or it ends up applying to your libc and start files as well.
12:08 < cfields> Maybe that's changed, though. That always seemed like weird behavior to me.
12:08 < dongcarl> yeah I think that's changed, since the Guix builds didn't need the closing one
12:09 < dongcarl> "our exported symbols" = bitcoind's exported symbols?
12:09 < cfields> Right
12:12 < cfields> Off to make some food, thanks all!
12:12 < dongcarl> :-)
14:02 -!- jonatack [~jon@37.166.80.227] has joined #bitcoin-builds
15:10 -!- _jerry [~jerry@47.55.112.140] has joined #bitcoin-builds
16:33 -!- dawggo12_ [~Android@035-133-237-096.res.spectrum.com] has quit [Ping timeout: 246 seconds]
16:40 -!- dawggo12 [~Android@035-133-237-096.res.spectrum.com] has joined #bitcoin-builds
18:26 -!- _jerry [~jerry@47.55.112.140] has quit [Ping timeout: 240 seconds]
18:34 -!- jonatack [~jon@37.166.80.227] has quit [Read error: Connection reset by peer]
19:06 -!- dawggo12 [~Android@035-133-237-096.res.spectrum.com] has quit [Read error: No route to host]
19:06 -!- dawggo12 [~Android@035-133-237-096.res.spectrum.com] has joined #bitcoin-builds
21:11 -!- MarcoFalke [~none@198.12.116.246] has quit [Ping timeout: 276 seconds]
21:51 -!- dawggo12 [~Android@035-133-237-096.res.spectrum.com] has quit [Remote host closed the connection]
23:35 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
--- Log closed Thu Nov 21 00:00:15 2019