0

I have a nice GUI program which runs fine if I start it from terminal but does not start at all if I run it from a non-terminal program launcher like dmenu or gmrun. Everytime I do so, nothing observable happens (neither on screen or in some log) but a defunct zombie process is the only trace I see so far. I tried also several possible commands to start it from 9menu where I use /bin/bash as the shell to run the command. Currently, I am stuck and wondering where to look next for a possible solution.

Since the program runs fine from terminal, I assume it has nothing to do with my—admittedly—unconventional and outdated setup? Where should I look first, wxWidgets, locale, …?

This is my environment:

  • Debian 3.2.102-1 i686 GNU/Linux
  • The GUI program: treesheets (compiled by myself, using wxWidgets 3.1.4)
  • Window manager: I tried with dwm and 2bwm

Any hint would be helpful!

smartmic
  • 269

1 Answers1

0

I could find the decisive hint by inspecting the command run of treesheets which results in a zombie process using strace. In fact, I stumbled over the same problem with another C++ program.

The root cause is quite common and was revealed by the strace log: the library path for libstdc++.so.6 was wrong (outdated). Running the program from shell was no problem because there I had an environment variable LD_LIBRARY_PATH which includes the path /usr/local/lib to my updated, manual installation of glibc. But this environment was not present when running a command .xsession.

So, to fix my problem

  • either prepend LD_LIBRARY_PATH=/usr/local/lib to the command in .xsession
  • add the proper linking flag during the build process in the Makefile (eg. add -Wl,-rpath=/usr/local/lib,--enable-new-dtags to LDFLAGS (in case of a CMake project: add set(CMAKE_INSTALL_RPATH "/usr/local/lib") to CMakeLists.txt)
smartmic
  • 269