Can't quit app on macos #7738
-
|
I just used pyinstaller for the very first time (installed via homebrew on MacOS) to package a windowed app, which uses wxPython. Everything seems to build OK. When I launch the bundled app, it runs as expected, however the only way I can fully terminate the process by force-quitting the app. Closing the app's single window, pressing command-q, or gong to the app's file menu to quit doesn't seem to do anything; the app still appears open and I am unable to open it until I force-quit it. If I manually run my app (eg unpackaged and from the command line), I am able to quit it with no problem. Any idea what might be going on and how I can resolve this? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 7 replies
-
|
Can you provide a minimal example that exhibits the problem? |
Beta Was this translation helpful? Give feedback.
-
|
Ah - yes, apologies - attached is the actual code, app is invoked by executing fix_namely_report.py You'll note that in gui.py, I've tried to explicitly destroy the app on close using wxPython's related event bindings, but to no obvious effect - which has left me believing the problem is not related to wxPython but rather pyinstaller. And here is the pyinstaller command I've been using to build the app: |
Beta Was this translation helpful? Give feedback.
-
|
PS I've also tried isolating the event loop by running the GUI in a separate process - the same problem persists. Updated code at the end of fix_namely_report.py looks like: def run_gui():
ndc = NamelyDataCleaner()
app = gui.NDCApp(False)
frame = gui.NDCFrame(parent=None, title="PXT Namely Data Cleaner", ndc=ndc)
frame.Show()
app.MainLoop()
if __name__ == "__main__":
multiprocessing.freeze_support()
p = multiprocessing.Process(target=run_gui)
p.start()
p.join() |
Beta Was this translation helpful? Give feedback.
-
|
Hmmm, yeah, it looks like I can reproduce this with homebrew python 3.11 and homebrew wxpython, but not with python.org python 3.11 and pip-installed wxpython... |
Beta Was this translation helpful? Give feedback.
-
|
Ah, yes... And because the links have a level of indirection in between ( So you'll have to fix this manually: Or switch to PyPI version of |
Beta Was this translation helpful? Give feedback.
-
|
Yep, that fixed it. Thanks so much for your help! |
Beta Was this translation helpful? Give feedback.
Ah, yes...
libwx_osx_cocoau_core-3.2.0.2.1.dyliband its symlinklibwx_osx_cocoau_core-3.2.dylibare collected as hard copies, leading to problems. Same withlibwx_baseu-3.2.0.2.1.dylibandlibwx_baseu-3.2.dylib.And because the links have a level of indirection in between (
/usr/local/opt/wxwidgets/lib/libwx_baseu_net-3.2.dylibpoints tolibwx_baseu_net-3.2.0.dylib, which points tolibwx_baseu_net-3.2.0.2.1.dylib) and the middle link is not referenced anywhere (and thus not collected), even #7619 couldn't help here (yet...).So you'll have to fix this manually: