Static and Dynamic Libraries

[waynew]

How does Qt differentiate between static and dynamic libraries when both are included in the application pro file? The doc is not clear and the syntax appears to be the same for both. Just by the library file extension (.a Vs .dll on Windows)? I have listed both types in the pro file and the static (<lib>.a) is working but not the dynamic (<lib.dll>) is not and won't load with QLibrary.

[franz]

The syntax is the same. The .a library basically contains object code similar or equal to the .o files created during compilation. The dll (or shared object) is actually very similar to an executable. When you run your application, the compile time linked shared object will have to be in the search path, which on windows will typically be the application directory. Whether QLibrary can load it or not depends a bit on how you use it. You'll have to elaborate there what you want and what you are doing right now.

[waynew]

Thanks franz. That helps. I tried linking the static library but it gives me a linker error( a reference error to the library function I call), not recognizing the first function call I make to the library. Yes, I have the headers included. Also, if I comment out the library function call, the build is ok, but the exe stays the same size, which indicates to me the library is not being included.

So, I tried using the dll. I put it in my application build directory and included the headers. the build is ok, but QLibrary says it can't load the library. Dependency walker only shows a few warnings regarding Microsoft dlls.

Also, if I pick a random MS dll and put it in my application build directory, QLibrary loads it ok.

At this point, I am thinking there must be something wrong with my library (I built it from source using Mingw/msys).

[SixDegrees]

Whatever you're building now and trying to link to the library will have to be built using the same tools the library was built with - mingw. It may have to be rebuilt to use similar flags - for example, you can't link a library built in 64-bit mode with an application built in 32-bit mode.

[waynew]

Thanks Six, I built the library on the same 32 bit Windows machine I made my Qt application on.
So, that should not be a problem, right?

[SixDegrees]

It may not be the problem, at least if they were built with the same compiler. Post the actual error message you're getting.

[waynew]

Well, when I try to link to the static library, the error message is:
C:\CPP\QT_Projects\HRLogger_Development/lotwupload.cpp:23: undefined reference to `_imp__tqsl_init@0'

For reference, the pro file entry is:

INCLUDEPATH += C:\mingw\msys\1.0\home\wayne\tqsllib\include
LIBS += -L"C:\mingw\msys\1.0\home\wayne\tqsllib\lib" -ltqsllib

INCLUDEPATH += C:\mingw\msys\1.0\home\wayne\tqsllib\include
LIBS += -L"C:\mingw\msys\1.0\home\wayne\tqsllib\lib" -ltqsllib

To copy to clipboard, switch view to plain text mode 

The library .h files are included in my application.

And the first library call (where it fails) is :

int ret = tqsl_init();

int ret = tqsl_init();

To copy to clipboard, switch view to plain text mode 

And this function is defined in tqsllib.h which is included in my application.

So what could I be doing wrong here?

[BalaQT]

Hi ,
Open the Makefile of ur project, see LIBS + line
if double quotes is missing in pro file,
Try LIBS += -L$$quote("C:\mingw\msys\1.0\home\wayne\tqsllib\lib ")

or

may be u can try by adding the library's path in the PATH variable. u can also try path in QtCreator's projects->Run Settings

Try run qmake , clean & compile the project entirely

hope it helps

Thnks
Bala

[franz]

Forward slashes. If possible, always use forward slashes.

[waynew]

Thanks folks, tried that stuff, no luck. Same problem.
If I comment out the call to the library function, and do a build, both with and without the LIBS lines in the pro file, the size of the application exe does not change.

Does anyone else think this is an indicator that the library is not included in the exe? And that would cause the linker error when the library function call is left in?

[SixDegrees]

For whatever reason, the linker is not able to locate the library you're trying to link to. It may be a quoting or backslash issue, as others have suggested, or simply a case of the library not where you're telling the linker to look for it. Check your path, make sure the library is really there and that the path it's on matches the one in your project file.

[waynew]

Ok, I checked all of that and it is ok.

Here is where part of my newbie confusion comes in. The doc for building the tqsllib says to use the configure command with --disable-shared, which I did. Then it says after running "make install" "This should result in the creation of the tqsllib2.dll" Which it did.

Wouldn't using --disable-shared mean that you are creating a static library? Like a lib.a file? If so, then why does it create a dll?
It also creates the files libtqsllib.a libtqsllib.la and tqsllibd.a in the lib directory where I built it. tqsllib2.dll is in the bin directory.

I have been trying to use the tqsllib.a file as a static library. Is this incorrect?

Can someone explain this to me? I am really library confused.
At least I was able to build the qserialdevice static library and include it in my application and it is working fine. But this library is just not the same.

[Timoteo]

Looks like your answer lies here:

#if defined(__WIN32__) && !defined(TQSL_NODLL)
      #ifdef TQSLLIB_DEF
            #define DLLEXPORT __stdcall __declspec(dllexport)
            #define DLLEXPORTDATA __declspec(dllexport)
      #else
            #define DLLEXPORT __stdcall __declspec(dllimport)
            #define DLLEXPORTDATA __declspec(dllimport)
      #endif
#else
      #define DLLEXPORT
      #define DLLEXPORTDATA
#endif

#if defined(__WIN32__) && !defined(TQSL_NODLL)
      #ifdef TQSLLIB_DEF
            #define DLLEXPORT __stdcall __declspec(dllexport)
            #define DLLEXPORTDATA __declspec(dllexport)
      #else
            #define DLLEXPORT __stdcall __declspec(dllimport)
            #define DLLEXPORTDATA __declspec(dllimport)
      #endif
#else
      #define DLLEXPORT
      #define DLLEXPORTDATA
#endif

To copy to clipboard, switch view to plain text mode 

You aren't defining any of these symbols yourself are you?

C:\CPP\QT_Projects\HRLogger_Development/lotwupload.cpp:23: undefined reference to `_imp__tqsl_init@0

Here, the linker expects to find a function with the stdcall convention. It seems that you build the library one way, and you are trying to link against it in other.

Examine your defines for building it, and check your defines for linkage.

[waynew]

Thanks Timoteo. I can see that you are trying to tell me something important, but being a C++ newbie, I am having a hard time understanding it.

Here are my questions/comments:

1. When I compile the tqsl library and the files tqsllib.a and tqsllib2.dll are created - isn't the tqsllib.a the static and the tqsllib2.dll the dynamic?
2. If the configure is run with --disable-shared, why does it create the dll?
3. You said "It seems that you build the library one way, and you are trying to link against it in other." I am just trying to link against the static tqsllib.a I thought that was what I had in my pro file. So what do you mean?
4. I don't think I am defining any symbols. I am just calling the first function I need in the library that is tqsl_init();
5. Why does one need the code you posted?
6. What do you mean by "Examine your defines for building it, and check your defines for linkage"?

Sorry for all of the newbie questions to your post, I know you are trying to help.
I am really trying to get this - I have 5 C++ books and 5 Qt books, but none of them really explain how to work with external libraries.
If I could find a good reference that explains all of this I wouldn't have to waste all of your time with dumb questions.

[Timoteo]

The code I posted is from the header of the library in question. It uses a set of defined symbols to determine whether you are importing or exporting symbols. It also determines the calling convention that the linker should expect (__cdecl for static lib, and __stdcall for dynamic lib). From another quick glance it appears that you need to define TQSL_NODLL in order to link statically.
your .pro

DEFINES += TQSL_NODLL

DEFINES += TQSL_NODLL

To copy to clipboard, switch view to plain text mode 

It also appears that you need to define TQSL_NODLL (not in source, but passed to the compiler) when building the library to achieve static linkage.

[waynew]

Thanks Timoteo, that helps.

The code in the library is

/** Initialize the tQSL library
  *
  * This function should be called prior to calling any other library functions.
  */
DLLEXPORT int tqsl_init();

/** Initialize the tQSL library
  *
  * This function should be called prior to calling any other library functions.
  */
DLLEXPORT int tqsl_init();

To copy to clipboard, switch view to plain text mode 

I have included the tqsllib.h in my application, and I call the init function like this

int ret = tqsl_init();

int ret = tqsl_init();

To copy to clipboard, switch view to plain text mode 

And the build error is:
C:\CPP\QT_Projects\HRLogger_Development/lotwupload.cpp:19: undefined reference to `tqsl_init'

So what am I missing now?

[Timoteo]

Did you rebuild the library as static? Could you upload your project somewhere and send it to me via PM or attach it here?

---

Added after 5 minutes:

Just some text to augment the replies to your previous questions:

It is important to understand just what a function declaration is. I am going to supply one and break it down while taking the win32 platform as an example.

int __stdcall doSomethingAwesome(int coolArg);

int __stdcall doSomethingAwesome(int coolArg);

To copy to clipboard, switch view to plain text mode 

Moving from left to right, we start with the return type. Now everyone knows what this is, but why does the compiler actually need it? The return type in this example tells the complier that the EAX register
will have a signed integer value in it when the procedure returns. In other words, the return type specifies the post-condition of the EAX register. Most know that compilers can much more easily inline
a function that returns nothing (void), and now you may know why. That's because the compiler knows that you have no dependency on the post-condition of EAX and it now has an extra register to use
when inlining.

Next is the calling convention. The calling convention tells the compiler how the parameters must be passed into the procedure and who is responsible for balancing the stack upon procedure return (caller versus callee). For instance, on win32 the parameters are pushed onto the stack, in win64 the parameters are passed in registers.

Next is the function identifier. Pretty much self-explanatory. Just note that this can be decorated or undecorated (extern "C").

Finally, we have the parameter. The most important thing that the compiler has to know about the parameter is the SIZE of the type. The compiler cannot generate correct procedure prologue without knowing this. In other words, the compiler cannot deduce the proper pre-conditions for entry into the procedure and cannot setup a correct stack frame for it. The same applies to procedure epilogue generation.

Most of this stuff is handled transparently by the compiler and you'd never have to know the compiler's reasons. When you get into mixed language projects, though, it comes in handy to know this stuff.

How this applies to your problem: The calling convention must be specified the same way when building the library and when linking to it.

[waynew]

I definitely still have a lot to learn about C++, That's what you get with an old hardware engineer!

I created a small test project but the files were too big to attach and I couldn't see a way to send an attachment on a PM so I put them on my website. Go to k4elo.net and the Download page. 3 files - the test project, the tqsl compiled library, and the config log from the library compile.

And thanks again for all of your help.

[Timoteo]

I had a look at the lib requirements and saw that you need the Windows DDK (WDK) in order to build it. I've been busy so I've not had the chance to setup my environment here at home for a build. When I establish a baseline that will build and link properly, I will post the results back to you (unless you beat me to it).

[waynew]

Many thanks Timoteo I really appreciate all of your efforts, you are a hero.
By sheer luck and a great deal of perspiration and trial and error, I have gotten the dll to load into my application in a test project test_lib2.
All I did was to put the includepath in the pro file, include the library header, then put the tqsllib2.dll into the debug directory and used QLibrary to load the library.
qDebug reports the library is loaded.
Now I am working on getting the tqsl_init() function resolved. No success yet.
I don't know if I am on the right path or not, but it looks promising.

I'll report back later tonight or tomorrow morning with my results.

I am still confused about library building. That is the library.a vs the library.dll when you build a library with --disable-shared.
I thought that would create a library.a that you could link statically. Appears not to be the case as I had no luck with linking tqsllib.a statically.
Just shows you how much I don't know about C++ yet.

Hoping that someone puts an entry into the wiki explaining external library usage.