Troubleshooting

This article offers solutions to common problems with the framework.

Under Linux, upon running my application, why do I get the error message "error while loading shared libraries: libwx_gtk-x.x.so"?

This message means that the library is not in the system search path for shared libraries. Usually this means either:

• You forgot to run ldconfig after running make install to install wxWidgets (using Linux).

On some linux running ldconfig isn't enought because you have to add this line to your /etc/ld.so.conf file:

/usr/local/lib

Once it's added, run ldconfig as root.

• make install installed the shared library in a directory (usually /usr/local/lib) not scanned by ldconfig on your system.

To resolve this issue, you can set the LD_LIBRARY_PATH environment variable to include the directory containing the shared library. Alternatively, add this directory to your /etc/ld.so.conf file, and re-run ldconfig.

A related question :

./wxbasic: error while loading shared libraries:
../../lib/libwx_gtk-2.3.so.0.0.0: cannot open shared object file:
No such directory

This is a classic problem and I have to say that for once, it's simpler on Windows.

Whereas Windows has a single PATH with both .exe and .dll, Unix is different. Usually the executable is on PATH and shared libraries are on LD_LIBRARY_PATH or something like that. I think that answers part of your question about how things are organized, but alas it's not relevant to this problem.

This particular user is having problems, I think, because of the way you linked wxBasic. I bet you linked

../../lib/libwx_gtk-2.3.so.0.0.0

into your executable and not something like

-L../../lib -lwx_gtk-2.3

When you used that relative path (or even a full path), the path to the shared library is copied into the executable. When the executable is run, it expects to find the shared library in ../../lib, not in one of the "standard places" like /usr/lib.

So what we usually do is use the -L and -l options to the C++ compiler/linker. The -L says WHERE to look for libraries and the -l suggests what the library is called. I say "suggests" because the libabc.so (or libabc.a) is refered to with -labc. Also, the version number stuff at the end is somehow ignored with the -l in a way I don't understand.

Why does my application crash on exit?

Chances are you are freeing something that was already freed (see Avoiding Memory Leaks).

If you are using SuSE 8.2, you are using a buggy non-release version of gcc, which causes the crashing. SuSE 10.2 also had some wrongly-configured WxWidgets rpm packages available from Packman-Bremen that crashed on exit.

My application does not exit

A wx app doesn't close until the last top-level window (frame, dialog, wizard or taskbaricon) is destroyed.

When you close a wxFrame, it destroys itself. When you close a wxDialog, it just hides, so you need explicitly to destroy dialogs yourself later (or, for modal dialogs, create them on the stack; then they die when they lose scope). Terminate modal dialogs with EndModal(), not close, if you close them yourself.

If can't keep track of what toplevel windows are open, just calling wxGetApp().ExitMainLoop() should terminate the application gracefully in any case

Also check that all threads have been terminated, if you created threads besides the main one

(credits for explanation : http://forums.wxwidgets.org/viewtopic.php?p=115871#115871 David Hart and Doublemax])

Why does my app crash in the callback of an event bound with Connect() ?

Most likely you passed the wrong event sink parameter (or omitted it) while calling ->Connect(...); By default wx expects the event callback to be in the object you connect. If your callback is not in the very object you connected, you need to pass an event sink parameter.

See docs for wxEvtHandler.

Note that as of wxWidgets 2.9/3.0, use Bind instead of Connect, since Bind will give you a compile-time error if you do this mistake.