Shared Libraries / DLL's... wuuuuuuuuuuuuuuuuuut?

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

0rm
Posts: 81
Joined: Wed Feb 17, 2010 2:30 pm UTC

Shared Libraries / DLL's... wuuuuuuuuuuuuuuuuuut?

Postby 0rm » Fri Feb 26, 2010 12:17 am UTC

Allow me to explain; every time I try to use a library that's distributed either in *.so or *.dll format, the damn things just don't link! Is there a special way to link dynamic/shared libraries as opposed to static libraries? Do I have to call some function to load a DLL, or is it all done with the compiler? I have been unable to find any resources on the subject.
They say it's unhackable; I think it can be hacked.
They say it's fast; I think it could be faster.
They say it's the best; I think it can be done better.

0xBADFEED
Posts: 687
Joined: Mon May 05, 2008 2:14 am UTC

Re: Shared Libraries / DLL's... wuuuuuuuuuuuuuuuuuut?

Postby 0xBADFEED » Fri Feb 26, 2010 12:31 am UTC

It's hard to diagnose without more information. "They just don't link" isn't very informative.

A few things you could check:
Make sure you're linking to the import library (the .lib/.a files) for the shared libraries and not the shared library itself.
Make sure the path containing the import libraries are on your linker's library path.
Make sure the import libraries are actually being fed to the linker.
Make sure the shared libraries are on your path, so that when they're requested at run-time the application doesn't barf.

That's really all there is to it. Lacking any actual linker complaints it's hard to say what your problem is.

User avatar
headprogrammingczar
Posts: 3072
Joined: Mon Oct 22, 2007 5:28 pm UTC
Location: Beaming you up

Re: Shared Libraries / DLL's... wuuuuuuuuuuuuuuuuuut?

Postby headprogrammingczar » Fri Feb 26, 2010 2:18 am UTC

0rm wrote:Do I have to call some function to load a DLL, or is it all done with the compiler?

DLL stands for dynamic linked library, which means the compiler does nothing. You have to use a function call, but it varies from OS to OS.
<quintopia> You're not crazy. you're the goddamn headprogrammingspock!
<Weeks> You're the goddamn headprogrammingspock!
<Cheese> I love you

0xBADFEED
Posts: 687
Joined: Mon May 05, 2008 2:14 am UTC

Re: Shared Libraries / DLL's... wuuuuuuuuuuuuuuuuuut?

Postby 0xBADFEED » Fri Feb 26, 2010 2:57 am UTC

headprogrammingczar wrote:DLL stands for dynamic linked library, which means the compiler does nothing. You have to use a function call, but it varies from OS to OS.

You're right, but this is somewhat misleading.

If you want to dynamically load a dll without linking to it at link-time this is true (e.g. using LoadLibrary on Windows). This is mostly useful in something like a plugin or extension system where there's no way to know what the required set of dll's are at link-time. The more common usage of dll's though is to link to the import library and let the OS's dll loader take care of resolving the dependencies at runtime. In this case there are no explicit calls that need to be made, you just feed the import library to the linker and the dll is loaded automatically at runtime. I think is the case that the OP was talking about.

0rm
Posts: 81
Joined: Wed Feb 17, 2010 2:30 pm UTC

Re: Shared Libraries / DLL's... wuuuuuuuuuuuuuuuuuut?

Postby 0rm » Fri Feb 26, 2010 9:43 pm UTC

You all have helped actually! I'll need to look up the library loading functionality in Linux and Windows. Import library, that's a static library that is produced with a DLL right?
They say it's unhackable; I think it can be hacked.
They say it's fast; I think it could be faster.
They say it's the best; I think it can be done better.

0xBADFEED
Posts: 687
Joined: Mon May 05, 2008 2:14 am UTC

Re: Shared Libraries / DLL's... wuuuuuuuuuuuuuuuuuut?

Postby 0xBADFEED » Sat Feb 27, 2010 2:04 am UTC

0rm wrote:Import library, that's a static library that is produced with a DLL right?

When you compile some code as a shared library two files are produced, the shared library (.dll/.so) and the import library (.lib/.a). The shared library contains the actual functional code. The import library just contains the information necessary for linking to the shared library at runtime. So at link-time your code links to the import library and this tells your application how to link to the shared library at runtime.

In MSVC there's an additional step you have to take so that your symbols in your shared library are accessible if you're actually writing the DLL and not just linking to a 3rd party library. Functions and classes that you want to expose need to be annotated with __declspec(dllexport) when compiling the shared library and when including exposed classes/functions in your other libraries they need to be annotated with __declspec(dllimport). This is usually accomplished using something similar to:

Code: Select all

//I'll assume your library is called MyCoolLib

#ifdef COMPILING_MY_COOL_LIB
#define MY_COOL_LIB_API __declspec(dllexport)
#else
#define MY_COOL_LIB_API __declspec(dllimport)
#endif

//annotating a class as exposed for the dll
class MY_COOL_LIB_API MyExposedClass { ... };

//annotating a function as exposed for the dll
MY_COOL_LIB_API void MyExposedFunction();

So then you'd define COMPILING_MY_COOL_LIB when compiling the shared library and leave it undefined for any other library using the MyCoolLib code. This ensures that the correct directive is inserted for each case (creating or using the library). This can also be accomplished without these annotations by using a definitions file (.def I think) that explicitly states what the exposed symbols are. But I alwasy just do it inline in the C++.

0rm
Posts: 81
Joined: Wed Feb 17, 2010 2:30 pm UTC

Re: Shared Libraries / DLL's... wuuuuuuuuuuuuuuuuuut?

Postby 0rm » Sat Feb 27, 2010 4:23 am UTC

Thanks for that. Now what about functions that load a shared library at runtime?
They say it's unhackable; I think it can be hacked.
They say it's fast; I think it could be faster.
They say it's the best; I think it can be done better.

User avatar
TNorthover
Posts: 191
Joined: Wed May 06, 2009 7:11 am UTC
Location: Cambridge, UK

Re: Shared Libraries / DLL's... wuuuuuuuuuuuuuuuuuut?

Postby TNorthover » Sat Feb 27, 2010 10:21 am UTC

0rm wrote:Thanks for that. Now what about functions that load a shared library at runtime?

Earlier posts here suggested LoadLibrary for windows (I can't really tell you much more about that). The equivalent on unix is dlopen and friends; there seems to be an example in the manpage.

0xBADFEED
Posts: 687
Joined: Mon May 05, 2008 2:14 am UTC

Re: Shared Libraries / DLL's... wuuuuuuuuuuuuuuuuuut?

Postby 0xBADFEED » Sat Feb 27, 2010 3:38 pm UTC

0rm wrote:Thanks for that. Now what about functions that load a shared library at runtime?

Basically in Windows there are two main API calls for working with implicit linking at runtime, LoadLibrary and GetProcAddress. LoadLibrary loads the DLL into the current process and GetProcAddress allows you to get the address of a specific function in the library. So you would use LoadLibrary to load the dll, GetProcAddress to get the address of some function, and then cast that address into the appropriate type of function-pointer so that you can actually call the function. That's pretty much it.

You might try here. Seems like it might be a decent tutorial for working with DLL's on Windows.

Karrion
Posts: 92
Joined: Fri Jun 22, 2007 12:14 am UTC
Location: Melbourne, AU

Re: Shared Libraries / DLL's... wuuuuuuuuuuuuuuuuuut?

Postby Karrion » Mon Mar 01, 2010 2:10 am UTC

0xBADFEED wrote:
0rm wrote:Import library, that's a static library that is produced with a DLL right?

When you compile some code as a shared library two files are produced, the shared library (.dll/.so) and the import library (.lib/.a). The shared library contains the actual functional code. The import library just contains the information necessary for linking to the shared library at runtime. So at link-time your code links to the import library and this tells your application how to link to the shared library at runtime.


While the above is true for windows DLLs, there's no such thing as an import library for .so files.

To link against a library /usr/local/lib/foo/libfoo.so on unix, using gcc:

Code: Select all

gcc -Wall -o bar -L /usr/local/lib/foo bar.o -l foo


On windows, you link against the import library C:\Program Files\Foo\foo.lib, eg using MSVC's linker:

Code: Select all

link /OUT:bar.exe /LIBPATH:"C:\Program Files\Foo" foo.lib bar.o

(If you're using the Visual Studio IDE, the directory is added in the project properties -> Configuration Properties -> Linker -> General -> Additional Library Directories, and the .lib added in the project properties -> Configuration Properties -> Linker -> Input -> Additional Dependencies)

These will do a link-time dynamic link against the library. The actual link with the .so or .dll doesn't actually happen until program load time, and will be done automatically by the dynamic link loader, no calls to LoadLibrary() or dlopen() needed. You do need to make sure that the library is available in the places the dynamic link loader will look for them:

On Linux, this is usually the places listed in /etc/ld.so.conf, plus directories listed in the environment variable $LD_LIBRARY_PATH, plus the location it was at when you did the dynamic link against it. See man ld.so for details.

On windows, this is usually the same directory as the executable is in, plus the directories listed in the system environment variable %Path%.


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 11 guests