Hangs before window appears on Linux #6
Comments
|
Hi, thanks for the bug report. The only thing that comes to mind is a missing -pthread flag, see here: floooh/sokol#404 I've been testing on my Ubuntu 20.04 machine where the demo works, so I didn't pay attention to this flag. I just committed a potential fix which adds the -pthread flag when compiling on Linux. Can you check if this works for you? |
|
Hi @floooh - thanks a lot for the fast reply. Unfortunately though, the Here's the full callstack of when I break into it whilst it's seemingly hung: |
|
Hmm strange that -pthread doesn't help. Your callstack is exactly the same as in this issue (the symptom there is also a hang, unlike that other issue I linked which crashed, but both were fixed with -pthread): |
|
...can you do these steps, and post the terminal output? I just want to make sure that the -pthread is actually showing. First, delete the build subdirectory if it exists, and then: Thanks! |
|
...maybe the issue is caused because some parts (namely imgui) are still compiled without -pthread... let me try something else (I really don't understand why GCC isn't setting this flag by default, it's causing so much hassle...). |
|
Ok new attempt in those two commits: This sets up the pthread stuff using CMake's builtin module via find_package(), hopefully this should fix those issues. I don't understand why I'm not seeing those problems here, I just checked again and I have a vanilla Ubuntu 20.04 with X11 desktop (e.g. no X11 on Wayland or similar). |
|
...however, the "recommeneded" cmake way doesn't add the -pthread flag to all compiler invocations either, so if the above fix doesn't work, the next step would be to simply add -pthread to the global C, CXX and LINKER options like I do in fips (which seems to work, but is rather brute-force): |
|
Thanks @floooh - those latest changes seem to have done the trick! The only additional thing to note now is I noticed I get an assertion fail when closing the window: Or, in the debugger: (Am happy to open this in a new issue though if you prefer?) Thanks again! |
|
I think the assertion you're getting now on shutdown is the same problem, so no need to create a new ticket. I'll try the "brute force" variant next, globally setting the -pthread flag for all compiler and linker invocations (so the same thing that fips does). |
|
Ok new attempt: If this still shows any sort of problems then it must be something else. |
|
Hi @floooh - unfortunately with that latest change it's now back to hanging before a window appears... Here's the verbose make output in case it holds any clues: |
...wow ok, that's unexpected (because according to the log the -pthread flag is now passed to all gcc/g++ invocations. Could you do a verbose log of the previous commit that worked but crashed on shutdown? I wonder how the compile flags look there (this contains more "cmake magic" for setting the pthreads flags): ...afterwards leave detached head state with 'git checkout main'. Thanks |
|
Hey @floooh - I'm starting to worry that I might just be wasting your time... I'm beginning to suspect there's just something wrong with my system config somehow. Because now, with So there must be something else going on here, right? And I feel bad about taking up any more of your time with it, especially if it's increasingly looking like some iffy config at my end. I'm going to continue my investigations though, and will report back. Next step: I'm going to create a fresh new user on the system, to see whether they have more success. However, one thing I can still say with pretty much 100% confidence, is that it's still true that I do not recall ever experiencing these types of issues with "main branch" Sokol - but maybe that just proves how neat |
|
So, my experiment with the new user worked: the The key difference between the resulting binaries from the two users is that for some reason my main user's binary does not get Whereas my test user gets all of the above linked, and also this: This is clearly the missing link, so now I'm just trying to work out why my main user does not get this linked into its binary. I've been diffing the verbose output for each and they're both actually very similar, but the most suspicious difference at the moment is that my main user does pass a few additional default library and header include paths to each compiler and linker invocation... So next I will try to remove those and see if that makes a difference. |
|
Ok - very embarrassingly, this was due to me having a custom I'm really very sorry for taking up your time with this. Thanks for your help, and thanks for the awesome library. |
|
Ah alright, no worries! Interesting that this is the second time recently where I've seen global environment variables messing up builds :) (last time the culprit was the CPATH environment variable which messed up cross-compilation builds: https://groups.google.com/g/emscripten-discuss/c/2Ot0ZQoK9is |
|
Oh that is interesting! Because after reading around a bit I thought Thanks for your patience and understanding! One final thought: is it worth reverting this repo to the earlier, less "brute force" method of handling |
Good point, I think I'll revert it to the find_package() version, as that should be the most "cmake-ish" way. |
|
I just gave it a quick check on my setup and it all seems to be working - thanks! 👍 |
Hi,
I've used master branch Sokol (via fips) for a while with very few issues.
I only recently discovered this starterkit repo, and I decided to give it a go as it sounds like it could be useful for a new project I've been considering.
However, strangely, when I've tried to build and run a clean checkout of the repo, it seems to hang before a window even appears.
Breaking into it in the debugger seems to suggest it's hung on the call to
_sapp.glx.QueryExtensionsString(_sapp.x11.display, _sapp.x11.screen)in_sapp_glx_init().Do you have any thoughts on what might be happening here?
Is there any additional diagnostics debugging I could turn on that might help?
Not sure if useful, but here's some gfx hardware info about my system:
And about my system:
Thanks!
The text was updated successfully, but these errors were encountered: