--- Log opened Wed Apr 13 00:00:53 2022
00:15 -!- Jackielove4u [uid43977@user/jackielove4u] has joined #bitcoin-core-builds
01:10 < laanwj> not sure how to fix this: somehow we end up without symbols for qt in the windows release https://github.com/bitcoin-core/gui/issues/582#issuecomment-1097686240   i don't know of how the flow of CXXFLAGS goes in depends
01:11 < laanwj> they used to be there back in the days of gitian IIRC
01:13 < laanwj> hrm could be a problem with addr2line as well, when i look using objdump is see function names …
01:13 < laanwj> that's a lot more manual work tho :)
01:18 < laanwj> it has function names but not *line numbers*
01:23 < hebasto> laanwj: what exact `objdump` invocation  are you using?
01:31 < laanwj> hebasto: i've filled in the function names, looks like were crashing in freetype? (grey_record_cell)  ... i have no clue why it's not like it's rendering text
01:32 < laanwj> hebasto: but fwiw: objdump -Crd bitcoin-qt.exe > bitcoin-qt.asm   make sure the .dbg exists
01:33 < laanwj> the crash is some 14161fbe8:   ff 15 ea 8d ba 00       call   *0xba8dea(%rip)        # 1421c89d8 <__imp_longjmp>      stack unwinding fun
01:34 < laanwj> this is why it ends up deeply in the kernel, on windows it's some kernel mechanism called SEH that gets used for stack unwinding
01:40 < laanwj> an issue from... 2010 :-) https://lists.nongnu.org/archive/html/freetype-devel/2010-12/msg00023.html
01:40 < laanwj> (no, no idea if that's even close, just happened when searching for longjmp related crashes in freetype)
01:40 < hebasto> Oo
01:42 < laanwj> it makes no sense for it to be rendering fonts there
01:48 < laanwj> hebasto: might want to try disabling anti-aliasing inside that paint event handler
01:48 < laanwj> i have a gut feeling it's used for that
01:52 < laanwj> hebasto: did you know Qt doesn't use our provided freetype 2.11.0 on windows, but its internal one--i just caught it in the act because ft 2.11 doesn't have the function gray_record_cell anymore
02:10 < laanwj> so i guess we only hit this issue here because it's the most complex object rendered, it needs the cell buffer reallocation
02:10 < laanwj> which causes a longjmp
02:15 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has quit [Ping timeout: 240 seconds]
02:17 < hebasto> yes, had the same idea about AA, checking...
02:18 < hebasto> no, was not aware of freetype
02:19 < hebasto> we have `-no-freetype` for mingw32 explicitly
02:19 < laanwj> pretty sure qt cannot live without freetype
02:20 < hebasto> why use it silently?
02:20 < laanwj> no idea !
02:20 < hebasto> heh
02:20 < laanwj> no-freetype apparently really means "use internal freetype"
02:21 < hebasto> `-qt-freetype` is for that
02:46 < laanwj> maybe switching to the d2d backend worked around the issue because it really avoids this use of freetype in this case
02:47 < laanwj> it needs it for software rasterization of some things
02:53 < hebasto> disabling AA helps
02:57 < fanquake> hebasto: what patch are you talking about from https://bugreports.qt.io/browse/QTBUG-94692
02:58 < fanquake> also clearly this isn't a Guix issue, so I'm not sure why it wouldn't happen with Ubuntu/Debian cross-compiled binaries
02:59 < hebasto> fanquake: https://bugreports.qt.io/browse/QTBUG-93476?focusedCommentId=573642&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-573642
02:59 < fanquake> oh right, from the thread I linked, not https://bugreports.qt.io/browse/QTBUG-94692
03:00 < hebasto> but it points to QTBUG-94692 :)
03:01 < hebasto> https://github.com/Martchus/qtbase/commit/4f351792812f2ad38743702ccffa6ccc7e5114da
03:01 < fanquake> that looks horrible
03:01 < hebasto> lets just disable AA
03:02 < hebasto> with a nice and descriptive comment
03:02 < hebasto> ^^ for migw32 only, of course
03:09 < fanquake> That also kinda seems like overkill, but at this point I'm starting to not care. The 23.x release shouldn't be getting blocked on this random broken GUI crap
03:37 -!- jonatack [jonatack@user/jonatack] has quit [Ping timeout: 248 seconds]
04:19 -!- jonatack [jonatack@user/jonatack] has joined #bitcoin-core-builds
06:11 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined #bitcoin-core-builds
07:46 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-builds
07:53 < dongcarl> Wondering what the difference is (in mingw-w64) between .dll.a libraries and plain .a libraries. For example, I see that there's libpthread.a and libpthread.dll.a, the latter of which provides __impl_pthread_mutex_* symbols in addition to pthread_mutex_* ones
08:06 -!- jonatack [jonatack@user/jonatack] has quit [Ping timeout: 240 seconds]
08:15 -!- jonatack [jonatack@user/jonatack] has joined #bitcoin-core-builds
10:15 < laanwj> isn't one the link library for linking against the dll?
10:15 < laanwj> remember that windows doesn't allow linking against dlls directly, they don't have the required information for linking
10:16 < laanwj> so there's (usually) a .lib or in this case .a that provides the link information but not actually code
10:16 < laanwj> why do i know things about windows
10:16 < sipa> yeah, i think the .dll.a is has stub functions which call the DLL's implementation
10:17 < sipa> so the .a is the static library, the .dll is the dynamic library, and the .dll.a is the static library which invokes the dynamic library
10:17 < sipa> and you link with either the .a or the .dll.a
10:18 < laanwj> it's pretty elegant in a sense that the link library only contains the interface, so it's independent of the actual implementation, you don't need the implementation to link against it (only at runtime)
11:14 < dongcarl> So if I link against .dll.a, does that mean I'll need to have the actual .dll at runtime?
11:15 < sipa> Exactly.
11:16 < sipa> (my information about Windows building is ~20 years old... things may have changed, but apparently not much)
11:16 < dongcarl> Okay so if I want to embed libstdc++ into a library, I should make sure that I'm linking against libstdc++.a instead of .dll.a?
11:17 < dongcarl> Urgh this is the exact opposite of what someone on #mingw-w64 told me... Oy vey
11:17 < sipa> Maybe it's the other way around!
11:19 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 250 seconds]
11:20 < dongcarl> 😖
11:21 < sipa> https://stackoverflow.com/a/17066866/8342274 says the same as I thought.
11:23 < dongcarl> right... I guess that does make sense
11:29 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-builds
12:07 < laanwj> yes, if you don't want to depend on the dll at runtime, you'd want to link the .a
12:16 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 260 seconds]
12:17 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-builds
12:47 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
12:47 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-builds
15:19 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 248 seconds]
15:29 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-builds
16:03 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 248 seconds]
17:05 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
17:05 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-builds
23:51 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-builds
--- Log closed Thu Apr 14 00:00:55 2022