User forums > Using Code::Blocks

How to link with Dynamic Libraries

(1/2) > >>

cacb:
Hi,

I am trying to use Code::Blocks to define a workspace containing 2 projects (each with separate build targets for Windows and Linux)
DynLibTest : A DLL project on Windows, a shared object project on Linux       
DynLibConsole: A console application on Windows and Linux using DynLibTest 

The example runs fine on Windows, DynLibConsole links against the DynLibTest.lib (export library). On Linux I am able to link the shared object and I get a "libDynLibTest.so" as expected.

The problem occurs when trying to link DynLibConsole against libDynLibTest.so, I get the error message: "ld   cannot find -lDynLibTest.so"

Under "Linker settings" I have mentioned "libDynLibTest.so" and under "Search Directories" (Linker) I have given the relative path to where the .so is found. This is equivalent to what I did on Windows (where I referenced the export library DynLibTest.lib istead of libDynLibTest.so.

So what am I missing to get this to work in Code::Blocks?

Jenna:
It should work if you just add DynLibTest (without prefix or extension).
Normally it works on both linux and win,  gcc should be able to pick up the correct library (if the linker path is set correctly of course).

cacb:

--- Quote from: jens on November 05, 2009, 03:09:34 pm ---It should work if you just add DynLibTest (without prefix or extension).
Normally it works on both linux and win,  gcc should be able to pick up the correct library (if the linker path is set correctly of course).

--- End quote ---

I cannot figure it out. The linker path is to the directory of the DynLibTest project where the libDynLibTest.so file is found.

I have tried these variants of the name
libDynLibTest.so : "ld   cannot find -lDynlibTest.so"
libDynLibTest : results in undefined references to the class member functions I am calling, followed by "collect2: ld returned 1 exit status"
DynLibTest.so : "ld   cannot find -lDynlibTest.so"
DynLibTest : results in undefined references to the class member functions I am calling, followed by "collect2: ld returned 1 exit status"

So from what you say, it seems that using "DynLibTest" is correct, but now my problem is maybe that the exported classes are not really exported? In any case, none of the above work. Is there some way I can check whether the .so I have generated actually exports the functions? On windows I use Dependency Walker (depends.exe) for that purpose.

I am also assuming I don't have to explicitely export classes on Linux. I use the following (simplified)

#ifdef WINDOWS
   #define  DLL_EXPORT  __declspec(dllexport)
#else
   #define  DLL_EXPORT
#endif

class DLL_EXPORT foo {
public:
   foo();
   ~foo()
};

Jenna:
I use it his way (with wxWidgets):


--- Code: ---#ifdef __cplusplus
extern "C"
{
#endif // #ifdef __cplusplus
#ifdef __WXMSW__
    #ifdef BUILD_DLL
        #define DLL_EXPORT __declspec(dllexport)
    #else // #ifdef BUILD_DLL
        #define DLL_EXPORT __declspec(dllimport)
    #endif // #ifdef BUILD_DLL
#else // #ifdef __WXMSW__
    #define DLL_EXPORT
#endif // #ifdef __WXMSW__

class DLL_EXPORT foo {
public:
   foo();
   ~foo()
};

#ifdef __cplusplus
}
#endif // #ifdef __cplusplus


--- End code ---

As far as I know, you can use your dll without explicitely exporting or importing (even on windows), if you only use it with MinGW/gcc, but I'm not absolutely sure about this.

cacb:

--- Quote from: jens on November 05, 2009, 07:13:16 pm ---As far as I know, you can use your dll without explicitely exporting or importing (even on windows), if you only use it with MinGW/gcc, but I'm not absolutely sure about this.

--- End quote ---
I use VC2008 on Windows, and have it working there (my #defines are as you show them, my previous post was a bit over-simplified). I have done this for 10+ years on Windows, no problem.

The problem is doing the same on Linux. I am still in the dark.

Navigation

[0] Message Index

[#] Next page