0

I have inherited a code project that contains several individual libraries of code that compile separately and then are linked in the compiled tools. It's supposed to be a Chinese menu of what each tool wants. This all written on Linux, in C++, with Qt. There are several issues with the current design, but I'm learning to deal.

This latest issue has me really dumbfounded. The main library is the Utilities. It contains a handful of classes and it compiles into a .a library file. Another library is our DatabaseInterfaces. It has class files that refer to header files from Utilities (they are all shared) but the CPP files are not included in DatabaseInterfaces. DatabaseInterfaces also compiles into a .a library. Finally, we have a CMDPrompt tool that imports both the Utilities.a and DatabaseInterfaces.a libraries. CMDPrompt does not compile. Instead, I get several errors indicating that I have an undefined reference for one of the objects in Utilities.

After several different attempts to fix this, I finally directly included the CPP file in the CMDPrompt.pro. It worked or at least it is now finding new undefined references for other classes in Utilities. This confirms to me that somehow the projects are not linking correctly. I would have expected that because the Utilities library is linked in I would have gotten all of the H/CPP goodness with it. I suspect the problem is that the DatabaseInterfaces library is compiling against the H files only and needs the same Utilities.a library. I tried adding that LIB into the DatabaseInterfaces.pro, but it didn't have any effect.

I am not a C++ programmer by training and while I believe I understand the main points of the linking process, I am obviously missing something. Here are my questions. Given the relationship between the different libraries, how should the linker work? Why is the DatabaseInterfaces.a compiling at all with just the H files? What is the best way to resolve this issue?

BSD
  • 329
  • 3
  • 13
  • 1
    You need to link the libraries in the right order - it sounds like Utilities.a needs to be linked last. I don't know how you do that in Qt but that's what you need to achieve. – Paul Sanders Jul 21 '20 at 21:28
  • An experienced C++ developer is needed to research and investigate this code base and its build system, sorry. There's nothing anyone will be able to tell you without inspecting the actual code and the makefile. For starters, `.a` libraries do not contain header files, contrary to your impression. Bottom line: an experienced developer is needed to unravel this. This cannot be remotely debugged on stackoverflow. – Sam Varshavchik Jul 21 '20 at 21:29
  • @PaulSanders and that seems to have fixed it. I'd be very interested to know why the order of the linking would make a difference, but I can probably follow those bread crumbs. I'd like to give you credit for the answer. Would you mind posting your comment as a full answer? Maybe even add a bit more about the explanation. Thanks again. – BSD Jul 21 '20 at 21:41
  • @SamVarshavchik Thanks for the information on .a files. Helping me to clarify a misconception is always welcome. That is how one gains experience with a new language, right? I'll be able to follow up on that to learn more about them. – BSD Jul 21 '20 at 21:45
  • 1
    @BSD OK, I've done that. When linking libraries, the GNU linker only looks for symbol references that appear in the preceding files, so if you link things in the wrong order some symbol references remain unsatisfied at the end of the linking process. – Paul Sanders Jul 21 '20 at 21:47
  • 1
    Now that I know what to look for, I found a related question. https://stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause-errors-in-gcc – BSD Jul 21 '20 at 21:50

1 Answers1

1

You need to link the libraries in the right order - it sounds like Utilities.a needs to be linked last. I don't know how you do that in Qt but that's what you need to achieve.

Paul Sanders
  • 24,133
  • 4
  • 26
  • 48
  • Might this also be related to the operating system? The original code ran on a Windows system while I am on Linux. I am finding that this error exists in multiple other tools. Once I fix the order, everything runs. So if the code I inherited was in working order before it was sent to me, the original order must have worked. This makes me suspect that the order is not important in Windows. Or maybe just Windows + Qt? – BSD Jul 21 '20 at 21:59
  • 1
    That's correct. The Windows (MSVC) linker doesn't care about the order in which you supply the libraries on the command line. – Paul Sanders Jul 21 '20 at 22:01