0

I'm trying to compile a quickfix program on Ubuntu but I get undefined references to FIX::, as if the -lquickfix option were not placed in the g++ command. Actually, I get the same result without this link option.

First I've downloaded, compiled, and run the test of quickfix. Everything worked fine. I did the sudo make install and checked the library was cached after runing sudo ldconfig: 

$ ldconfig -p | grep quickfix
libquickfix.so.16 (libc6,x86-64) => /usr/local/lib/libquickfix.so.16
libquickfix.so (libc6,x86-64) => /usr/local/lib/libquickfix.so

This is the g++ command I used:

$ g++ -fexceptions -finline-functions -lquickfix -lpthread -lxml2 -std=c++11 Application.cpp tradeclient.cpp -o tradeclient

BTW, I've run the same quickfix intallation steps on Debian and the compile command worked fine.

I've read posts like Libraries in /usr/local/lib not found, used the -L option for link directories, and -I for include paths but I'm still not finding a solution.

hector
  • 907
  • 1
  • 9
  • 23
  • [Your linkage consumes libraries before the object files that refer to them](https://stackoverflow.com/a/43305704/1362568) – Mike Kinghan Feb 27 '18 at 07:58
  • Possible duplicate of [What is an undefined reference/unresolved external symbol error and how do I fix it?](https://stackoverflow.com/questions/12573816/what-is-an-undefined-reference-unresolved-external-symbol-error-and-how-do-i-fix) – Mike Kinghan Feb 27 '18 at 07:59
  • I've realized that indeed there was a problem in the order of arguments of g++ command. Placing `Application.cpp` and `tradeclient.cpp` at the end causes the undefined references; if I place them at first, before -l options, it works. What confused me was that this command worked fine in Debian regardless where I place these two files. I'm not sure yet why that happens. – hector Mar 01 '18 at 16:13
  • Hi. Pre-Debian 7, linkage was old-school (as RedHat & friends still are). Dependency order was enforced for static libraries not shared libraries (which were all linked whether needed or not). Debian 7 went over to dependency order for all libraries and Debian-based distros (Ubuntu etc.) followed suit. Maybe your Debian host is pre-7? – Mike Kinghan Mar 01 '18 at 16:21
  • Hi Mike, in my case, I tried on Debian 7, 8, and 9, always with the same results: order seems not to matter. On the other hand, on Ubuntu 16 and 17 the order does matter. – hector Mar 01 '18 at 20:21
  • Very interesting, I'll check it out too. Thanks! – Mike Kinghan Mar 01 '18 at 20:34

1 Answers1

0

This example shows that the linking argument order using g++ may or may not matter depending on the OS you’re using.

main.cpp:

extern int x_global;
int y_func(int a);

int main(int argc, char *argv[]) {
  int x = x_global + 1;
  return y_func(x);
}

x.cpp:

int x_global = 2;

y.cpp:

int y_func(int a) {
  return a + 1;
}

Given these three files, we can create 'shared libraries' on which main.cpp depends:

$ g++ -shared x.cpp -o libx.so
$ g++ -shared y.cpp -o liby.so

Now, we can compile our main function by linking the respective libraries:

$ g++ main.cpp -L. -ly -lx

To execute the program, first we need to set LD_LIBRARY_PATH for the compiler to find the newly created 'shared libraries':

$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:.
$ ./a.out

And we can immediately check the result:

$ echo $? 
4

If we are on Ubuntu 16 or 17, the compile command is dependent on the order of its arguments. For example, this won’t link properly yielding an undefined reference:

$ g++ -L. -ly main.cpp -lx
/tmp/ccYWLawS.o: In function `main':
main.cpp:(.text+0x21): undefined reference to `y_func(int)'
collect2: error: ld returned 1 exit status

Check out that this won’t link neither:

$ g++ -L. -ly -lx main.cpp
/tmp/ccEYEAtM.o: In function `main':
main.cpp:(.text+0x11): undefined reference to `x_global'
main.cpp:(.text+0x21): undefined reference to `y_func(int)'
collect2: error: ld returned 1 exit status

But if your are on Debian 7, 8, or 9 these two aforementioned examples will compile without a problem. Account that we've worked with shared (or dynamic) libraries (*.so) here. When we work with static libraries (*.a), the order does matter for both OSs.

I've written this post based on the reading recommendation from Mike Kinghan and Beginner's Guide to Linkers article.

hector
  • 907
  • 1
  • 9
  • 23