Quote:
Originally Posted by ETCKerry
Under windows, there are .dll's. When you build your project, you link against a corresponding .lib that knows to load the appropriate .dll at runtime. I suspect Linux has something similar?
|
Yes, but with an important simplification. The .dll like file in Linux is called a .so and you link against the .so itself, not against some .lib file that represents the exports of the .so.
When you link against a .so it is doing the same thing you described for Windows, linking to the exports of the shared library so at run time it can use the shared library. It is
not linking the internal content of the .so into the image.
Quote:
Are .a libraries analogous to .libs?
|
Usually yes. The .a files are a more general construct than Windows .lib files, so they might be used for other purposes. But most .a files are used the same as Windows .lib files.
Quote:
cannot find -llibwx_based-2.8
|
Without some experimentation, I'm usually unsure of these details myself. In general, I think you need a blank after the -l and before the name, and I think you never include the "lib" prefix nor the ".a" or ".so" suffix when specifying a name to "-l". Sometimes it is correct to leave out the version number part as well.
Quote:
I've been reading a lot about an environment variable called LD_LIBRARY_PATH
|
I forget the details I once understood about the conditions under which the full path of the .so that was found at link time is stored in the image vs. just the name, such that the search for the .so is done again at load time. Sometimes it is convenient to keep the results of the link time discovery of .so files rather than search again at load time. You can use the ldd command to find out what .so files your image needs to find and where it can (or can't) find them.
The system default search path for .so files tends to be correct in most Linux distributions, so you often don't need LD_LIBRARY_PATH. But Linux is unlike Windows in its search for .so files. For example Linux does not automatically look first in the directory where it found the main executable. So if you are working with multiple versions and/or instally your application or things it depends on in nonstandard places, you likely need to set LD_LIBRARY_PATH to tell it whee to look for .so files.