Static and Dynamic Libraries

[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.

[Timoteo]

This library definitely is different (in the bad way). For example, I cannot get it to build cleanly on Linux due to it being bound to an older OpenSSL (if I hack around on it, I can get it to build, but it is nasty). Btw, what I said about it requiring the Windows DDK - total brain spasm. Dunno where that came from really. Also the configuration for the library appears to be totally borked on Windows (VS compiler).

The Trusted QSL software does come with a prebuilt library with it, but

dumpbin /exports tqsllib2.dll

dumpbin /exports tqsllib2.dll

To copy to clipboard, switch view to plain text mode 

causes the linker to crash so I cannot even inspect the symbols that it exports.

[waynew]

None of that surprises me. Wysota said something in an earlier post that indicated it wasn't too great.

I exchanged emails with the author and he said he really only provided the pre-built dll for Windows developers using Visual Basic and I know there are several Windows programs out there that are successfully using that approach.

When I built the library on Windows using Mingw, I used the current versions of openssl, expat, and zlib and it built ok.

I have gotten the tqsl_init() function to return success as follows:

QLibrary tqsllib2;
  tqsllib2.setFileName("c:/cpp/qt_projects/lib_test2/debug/tqsllib2.dll");
  tqsllib2.load();
 
  qDebug() << "is tqsllib2 loaded ? " <<  tqsllib2.isLoaded();
  qDebug() << "lib load error is " << tqsllib2.errorString();
 
 int ret;
 typedef int (*MyPrototype) ();
 
 MyPrototype tqsl_init = (MyPrototype) tqsllib2.resolve("tqsl_init");
 if (tqsl_init)
 {
    ret = tqsl_init();
 }
 qDebug() << "ret is now " << ret;

QLibrary tqsllib2;
  tqsllib2.setFileName("c:/cpp/qt_projects/lib_test2/debug/tqsllib2.dll");
  tqsllib2.load();

  qDebug() << "is tqsllib2 loaded ? " <<  tqsllib2.isLoaded();
  qDebug() << "lib load error is " << tqsllib2.errorString();

 int ret;
 typedef int (*MyPrototype) ();

 MyPrototype tqsl_init = (MyPrototype) tqsllib2.resolve("tqsl_init");
 if (tqsl_init)
 {
    ret = tqsl_init();
 }
 qDebug() << "ret is now " << ret;

To copy to clipboard, switch view to plain text mode 

Now I am working on getting the tqsl_getStationLocation function to work.

However, I want to be able to offer my application on Linux and Mac as well as Windows and if I'm not going to be able to compile the library for the other O/S and won't be able to use the library I built on Windows, then I think I am going to give up on adding the features to my application that the library offers.

Am I correct in assuming I won't be able to use the dll I built under Windows to create versions of my application for Linux and Mac? If that is the case, then I'm giving up on it unless they re-write the library.

Thanks again for all of your help, you have gone above and beyond what one would expect on the forum and I truly appreciate it. I'm sorry it turned out to be a waste of your time.

[norobro]

Waynew,

I have been following your travails with tsqllib. Not being a windows guy, I can't help you with your dll problem but I wanted to let you know that the Debian repositories have a package (tqsllib-dev) that is being maintained with the most recent patches being about a year old. One of the patches addresses the problem that Timoteo had:

-#elif (OPENSSL_VERSION_NUMBER & 0xfffff000) ==0x00907000
+#elif ((OPENSSL_VERSION_NUMBER & 0xfffff000) == 0x00907000 || (OPENSSL_VERSION_NUMBER & 0xfffff000) == 0x00908000)

-#elif (OPENSSL_VERSION_NUMBER & 0xfffff000) ==0x00907000
+#elif ((OPENSSL_VERSION_NUMBER & 0xfffff000) == 0x00907000 || (OPENSSL_VERSION_NUMBER & 0xfffff000) == 0x00908000)

To copy to clipboard, switch view to plain text mode 

I compiled the lib from source and ran your test program successfully.

Norm

[Timoteo]

Gaw, just my luck. Well, I'm a fairly stubborn guy so I would have probably ignored the package anyway, but that is great to know.