Difference between revisions of "Troubleshooting"
(Created page with "this article is to provide solutions to common installation problems and things with wxwidgets") |
|||
Line 1: | Line 1: | ||
− | + | 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 <tt>/etc/ld.so.conf</tt> file: | ||
+ | |||
+ | <pre>/usr/local/lib</pre> | ||
+ | |||
+ | Once it's added, run <tt>ldconfig</tt> as root. | ||
+ | |||
+ | * <tt>make install</tt> installed the shared library in a directory (usually <tt>/usr/local/lib</tt>) not scanned by ldconfig on your system. | ||
+ | |||
+ | To resolve this issue, you can set the <tt>LD_LIBRARY_PATH</tt> environment variable to include the directory containing the shared library. Alternatively, add this directory to your <tt>/etc/ld.so.conf</tt> file, and re-run <tt>ldconfig</tt>. | ||
+ | |||
+ | A related question : | ||
+ | |||
+ | <pre>./wxbasic: error while loading shared libraries: | ||
+ | ../../lib/libwx_gtk-2.3.so.0.0.0: cannot open shared object file: | ||
+ | No such directory</pre> | ||
+ | |||
+ | 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 <tt>LD_LIBRARY_PATH</tt> 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 | ||
+ | <pre>../../lib/libwx_gtk-2.3.so.0.0.0</pre> | ||
+ | into your executable and not something like | ||
+ | <pre>-L../../lib -lwx_gtk-2.3</pre> | ||
+ | |||
+ | 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 <tt>../../lib</tt>, not in one of the "standard places" like <tt>/usr/lib</tt>. | ||
+ | |||
+ | 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. |
Revision as of 08:10, 24 November 2013
This article offers solutions to common problems with the framework.
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.