"exo-open: symbol lookup error" when trying to open log folder #29

Activity

1. ErikBjare

   added

   bug

   on Oct 24, 2017
2. johan-bjareholt commented on Oct 24, 2017

   

   johan-bjareholt

   on Oct 24, 2017

   Member

   More actions

   Seems like libexo can't find a shared gobject library?
3. ErikBjare commented on Oct 24, 2017

   

   ErikBjare

   on Oct 24, 2017

   Last edited by ErikBjare

   MemberAuthor

   More actions

   Found these two similar issues:

   • Libexo - undefined reference when starting SteamVR ValveSoftware/steam-for-linux#4707
   • 2.1.0 AppImage fails to run with "undefined symbol: g_type_check_instance_is_fundamentally_a" OpenShot/openshot-qt#298

   According to the second issue g_type_check_instance_is_fundamentally_a was introduced in glib2-2.40. I'm a bit confused how something added in glib 2.40 ended up in the builds that run on Ubuntu 14.04.5 which has glib 2.19? Perhaps an issue in exo-open?

   Anyway, I think this issue in exclusive to Xfce (which uses exo-open) so not a big deal.

   Edit: nvm, seems like Ubuntu 14.04 has the package libglib2.0 which is at version 2.40.
4. johan-bjareholt commented on Oct 25, 2017

   

   johan-bjareholt

   on Oct 25, 2017

   Member

   More actions

   A wild guess could be that PyInstaller overrides the shared library directory so exo-open uses the PyInstaller libglib2.0 rather than the system provided one. I used readelf -a on the .so file and found no symbol named g_type_check_instance_is_fundamentally_a, so it seems rather likely.

   👍React with 👍1Reacted by Erik Bjäreholt
5. ErikBjare commented on Sep 25, 2020

   

   ErikBjare

   on Sep 25, 2020

   Last edited by ErikBjare

   MemberAuthor

   More actions

   Probably related to ActivityWatch/activitywatch#208
6. TimeToBuildBob commented on Oct 2, 2026

   

   TimeToBuildBob

   on Oct 2, 2026

   Contributor

   More actions

   This looks already fixed. Current master's aw_qt/trayicon.py has a get_env() helper that restores LD_LIBRARY_PATH from LD_LIBRARY_PATH_ORIG (or drops it) before spawning external tools, and both open_url() (Linux branch, via xdg-open) and open_dir() (non-Windows/non-macOS branch) use it:

   • bcd27a0 "fix: replace webbrowser.open with xdg-open with original LD_LIBRARY_PATH" (2020-06-25) — switched "Open dashboard" from webbrowser.open() to xdg-open with the restored env on Linux
   • 04069cb "fix: Make open dir work correctly with PyInstaller on Linux" (2021-02-21) — applied the same clean-env treatment to "Open log folder" / "Open config folder"

   The related ActivityWatch/activitywatch#208 is also already closed. I don't see a remaining external-open call path that still leaks the bundle's LD_LIBRARY_PATH. Closing this out as already resolved unless someone can still reproduce it on a recent build — happy to take another look with a concrete repro (bundle build, OS/desktop, exact error).