New to Linux - Question about shared libraries and makefiles
 

Hello all!

I've recently started doing some developing under Linux after several years of using MSW and have some questions about how to get gcc to link against some third party libraries. First off, I need some help understanding shared libraries. 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?

I see two kinds (or three?) of libraries in Linux: .so (which I think is analogous to .dll) and .a (is .la the same thing?). Are .a libraries analogous to .libs?

And now the makefile question:
I can't get gcc to find a library in /usr/local/lib (I get the following error: /usr/bin/ld cannot find -llibwx_based-2.8)

My makefile contains the line:
$(CC) -o $@ $(CCOBJS) $(LIBDIRS) $(LDFLAGS) $(LIBS)
where $LIBDIRS contains -L/usr/local/lib and LIBS contains -llibwx_based-2.8

Do I need to include a file extension for the library? It looks like all I have on my machine are the .so files - I can't find anything else for that lib...

I thought it might be a permissions problem (all wx libs are owned by root) but a tried sudo make and it was no better.

One last question: I've been reading a lot about an environment variable called LD_LIBRARY_PATH or something similar to that. That isn't defined on my machine (or I don't see it when I do 'env' in a terminal). Will I need to define this to use shared libraries? Where is the best place to define it?

It's a lot of questions, I know... thanks for the help!

-Kerry

I'm guessing you're writing in C, then. You may be falling into a common hole (I can't be certain without seeing your code) of trying to use Linux as Windows, so lets take a step back.

What exactly are you trying to do? I'm guessing something GUI based, as per libwx, but how are you calling it? How are you importing it?

Yes, I'm writting a GUI-based app in C++. I suspect you're right about trying to use Linux as Windows... hopefully we can correct that :-)

Typically, to use an external library (dynamic or static) I just #include the header in my source code, add the location of the .lib file (in Windows, even a .dll will have a .lib that you link against) to my linker's search path, and tell the linker to link against the .lib file (I would use the complete filename, i.e. 'libThisLibrary.lib'). Then I'm free to make any calls to that library from within my code. If it's statically linked, I'm done, but if it's dynamic then I need to put my .dll either in the same directory as the executable or somewhere on the system's PATH.

Does this make sense? I'm doing pretty much the same thing in Linux (fresh install of Fedora 11 if it matters). I can post code or my makefile or whatever else will make it easier to see what I'm trying to do, just let me know what you'd like to see. It's a pretty sizable program, as I've been developing it under Windows for a couple of years, but I've been *trying* to keep the code cross-platform from the beginning. Everything compiles just fine, it's only the linking I'm having issues with.

When I first tried to compile under Linux, it became clear that MSVC does NOT adhere to the C++ standards, as it let me get away with a few "mistakes" without even warning me. gcc of course caught these for me and they were easy to fix. Maybe something similar is happening with the linking? I should have done something differently but MSVC let me get away with it and gcc is calling me on it?

Thanks again!

-Kerry

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.

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.

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.

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.

Ahha! The problem was using the 'lib' prefix when using the -l option! Thanks for the tip (yes... I should have read the man pages - I'll be sure to start there next time :redface:).

So now I've got another question (maybe it's best to start a new thread?): In Windows, I include .ico files in the project via a resource (.rc) file. They get compiled into the executable. Is there a preferred way for handling this in Linux? Is it better to have a folder of icons that gets distributed with the app, or can you still compile them with the executable?

Thanks!

-Kerry

Hi,

You can take a look at 'Advanced Linux Programming Guide' to get some helpful information. Also take a look at the other links in the 'Programming General & WEB' section of 'Slackware-Links'. More than just Slackware® links!