Page 1 of 1

[SOLVED]: .so file on Linux

Posted: Mon Aug 22, 2005 6:36 pm
by ONEEYEMAN
Hi, ALL,
Do I have to link my application with my shared .so file?

I am using "LoadLibrary()" to load the file, but no luck yet... :(

Library and application compiles fine, but LoadLibrary fails!

Using KDevelop 3.2.1/KDE 3.4.1 as development environment.

It's wxGTK 2-6-1

Thank you in advance.

Posted: Tue Aug 23, 2005 3:22 am
by heda
Hi,
LoadLibrary() is part of Windows API and doesn't work under Linux. If you want to load a shared library by your program (without linking it with the shared library on linking process), you can use wxDynamicLibrary which works on different platforms. ( Linux's native function is dlopen() )

Good Luck,
Hedayat

Posted: Tue Aug 23, 2005 4:10 am
by ONEEYEMAN
Thank you for the reply, heda.
I am actually using the wxDynamicLibrary.LoadLibrary(), but wondering if I have to link the app against the .so file?
I am using the KDevelop 3.2.1 with the wxWidgets support.

Thank you

Posted: Tue Aug 23, 2005 7:25 am
by upCASE
You don't need to link with the .so (you never would have to, it's a shared object...) or the corresponding .a file.

Use wxDynamicLibrary::Load() and check if it returned true. You can then use GetSymbol() to get the actual functions. Be sure to either create wxDynamicLibrary on the heap, or use wxDynamicLibrary::Detach() and call wxDynamicLibrary::Unload() later, as the library will be unloaded by the destructor of wxDynamicLibrary.

Posted: Wed Aug 24, 2005 1:56 am
by ONEEYEMAN
As far as I remember, if the file name is "libdialogs.so", all I should pass is "dialogs", right?

Thank you.

Posted: Wed Aug 24, 2005 7:11 am
by upCASE
ONEEYEMAN wrote:As far as I remember, if the file name is "libdialogs.so", all I should pass is "dialogs", right?
???
If it was libdialogs.a and you want to link it in using gcc the parameter would be -ldialogs, correct. But it's a shared object, like DLL in windows. You don't link with it. Use the full name / path when loading it.
Not sure about Linux, but on Windows a DLL would be searched for in several places in this order:
1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4 .The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable.

I suppose there's something similar in Unix, so maybe only wxDynamicLibrary::Load("libdialogs.so") would do the trick.