_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #scopehal
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #scopehal
_whitelogger_ has quit [Remote host closed the connection]
<dingwat>
uh, so this is a new error. Building scopehal-apps on a new Windows machine, I'm now getting "The procedure entry point .... could not be located in the dynamic link library C:\<user>\scopehal-apps\build\src\ngscopeclient\glslang.dll", anyone familiar with this?
<dingwat>
(when I try to run it)
<azonenberg>
Interesting
<azonenberg>
is the dll actually there?
<azonenberg>
what symbol is it looking for?
<dingwat>
can't copy and paste the scary entry point, lemme screenshot. and yes, glslang is there
<azonenberg>
where did the dll come from? is it possible it got corrupted while copying from the system install folder or something?
<azonenberg>
interesting, its trying to find it in multiple places
<dingwat>
not sure where that DLL came from. I had to copy other DLLs in but didn't copy glslang.dll in..
<azonenberg>
Hmm, i don't know the windows build process at all WRT if it might copy the files itself
<azonenberg>
balrog: ^
<azonenberg>
ideas?
<azonenberg>
gut feeling is to do a clean build and maybe reinstall the vulkan SDK in case something got borked there
<dingwat>
interesting. glslang exists in msys64/ucrt64/bin, checked the MD5 on both files and they're the same
<azonenberg>
this kinda feels like linker derping or maybe header/lib/dll version mismatch or something
<dingwat>
hmm, that's scary, when I run pacman -Syu I get a big stack of "error: duplicated database entry <pkg>". I'll see if I can fix those and then do a clean build
<azonenberg>
that's actually consistent with the failure IMO
<azonenberg>
in terms of a failed upgrade or mismatched library versions or something
<dingwat>
cleaned up my packages, did a clean build, still have the same problem
<dingwat>
azonenberg: ah, ok, resolved it by copying _every_ .dll in msys64/ucrt64/bin into scopehal-apps/build/src/ngscopeclient (big hammer solution)
<dingwat>
so there's a DLL missing, but it's not showing the normal "can't find DLL error", instead it's giving this much less helpful error. Weird
<azonenberg>
lol
<azonenberg>
ok well, ultimately it's still the same root cause of "we need to properly map out the windows dependencies for build and packaging"
<azonenberg>
if you can figure out the actual required list of DLLs by checking one at a time, that would be helpful to know
<d1b2>
<fredzo_72653> @dingwat to run your build on windows you have two options: 1/ cd build/src/ngscopeclient and run ./ngscopeclient.exe from a msys64 ucrt64 shell (typically what you will do in development phase) 2/ Build the MSI installer (see getting starting guide for that) and run it: that will copy all the required DLLs to your install folder
<d1b2>
<fredzo_72653> This is all explained in the latest documentation (see TEX files), maybe it's not clear enough but it's there
<d1b2>
<azonenberg> @fredzo_72653 we still need to make the MSI build as part of the github CI pipeline
<d1b2>
<azonenberg> if you have time to work on that, that would be great
<dingwat>
fredzo, got it, I've been trying to just build from source, and I know that there are undocumented steps to copy in the right DLLs, but usually the error messages tell me exactly which DLLs I need :)
<d1b2>
<fredzo_72653> Yep, really not my domain of expertise.... I discovered how github actions worked with this project 😅
<d1b2>
<azonenberg> at least you're running on windows which is more than me
<d1b2>
<fredzo_72653> CPack with Wix to generate MSI installer works fine locally, but we need to find a way to install Wix Toolset on the Github build box
<d1b2>
<fredzo_72653> CPack knows the list of DLLs that needs to be bundled in the installer
<d1b2>
<fredzo_72653> Re hid dependency, it was misplaced (my bad) in the documentation (in the Vulkan dependecy secetion), @azonenberg you added it in the right place but did not remove it from the vulkan section I think.
<dingwat>
azonenberg: figured it out. Missing libstdc++-6.dll will cause that those ugly errors
<d1b2>
<azonenberg> can you take that as an action item before you spend too much more time on the stream browser stuff?
<d1b2>
<azonenberg> gui improvements are nice, but less critical to new users than "can install it"
<d1b2>
<azonenberg> our single biggest priority for the new user experience is not making people compile from source
<d1b2>
<fredzo_72653> lol cealrly 🙂
<dingwat>
:)
<d1b2>
<fredzo_72653> at least if you don't want to lose 99% of potential users !...
<dingwat>
it's definitely not ideal, telling people "yeah there's this cool new open source t&m software, oh but you need to compile it from source and also on Windows there is a pile of DLLs that you need to manually patch up" haha
<dingwat>
if I can help with testing Windows install/build processes, please let me know
<azonenberg>
dingwat: so not having installers earlier was a somewhat intentional de-prioritization
<azonenberg>
i.e. we didn't want to lower the entry barrier to installing it too much until the documentation had caught up
<d1b2>
<fredzo_72653> @azonenberg I'll have another look, but I'm not very confident I can do that without spending hours on it..
<azonenberg>
the rationale was, people willing to compile from source are probably able to spend some time poking at the code when things go wrong
<azonenberg>
and not need a lot of handholding getting started
<azonenberg>
people downloading a prebuilt binary installer have higher expectations of fit-and-finish
<azonenberg>
and we didn't want to let them down until we could actually deliver on that
<dingwat>
azonenberg: oh totally, that makes sense
<azonenberg>
But now that we have a harder deadline for shipping a release, obviously we need both packaging and docs dealt with asap
<azonenberg>
i plan to spend most of december on testing, bug fixing, and documentation