Which compiler flag am I missing in my build on the so file?

Question

Consider the following three files, all in the same directory.

Lib.h

namespace Foo {
    void bar();
}

Lib.cc

namespace Foo {
    void bar() { }
}

App.cc

#include "Lib.h"
int main(){
    Foo::bar(); 
}

Here are the commands I tried:

g++ -std=c++11 -fPIC -shared -o Lib.o Lib.cc
g++ -std=c++11 -shared -o libLib.so Lib.o

g++  -std=c++11 -o App  App.cc -L. -lLib

Unfortunately, the last line gives the following undefined reference error.

g++  -std=c++11 -o App  App.cc -L. -lLib
/tmp/ccwtxTdl.o: In function `main':
App.cc:(.text+0x5): undefined reference to `Foo::bar()'
collect2: error: ld returned 1 exit status

I also tried the following with the same error.

g++ -std=c++11 -o App App.cc libLib.so

Here is the output of nm libLib.so, which does not appear to include bar.

0000000000201030 B __bss_start
0000000000201030 b completed.6992
                 w __cxa_finalize
00000000000004e0 t deregister_tm_clones
0000000000000550 t __do_global_dtors_aux
0000000000200e48 t __do_global_dtors_aux_fini_array_entry
0000000000201028 d __dso_handle
0000000000200e58 d _DYNAMIC
0000000000201030 D _edata
0000000000201038 B _end
00000000000005c8 T _fini
0000000000000590 t frame_dummy
0000000000200e40 t __frame_dummy_init_array_entry
00000000000005d8 r __FRAME_END__
0000000000201000 d _GLOBAL_OFFSET_TABLE_
                 w __gmon_start__
0000000000000490 T _init
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
0000000000200e50 d __JCR_END__
0000000000200e50 d __JCR_LIST__
                 w _Jv_RegisterClasses
0000000000000510 t register_tm_clones
0000000000201030 d __TMC_END__

Which compiler flag am I missing in my build on the so file?

I have already examined this question but it did not resolve the issue.

Note that I am trying to build a shared library out of Lib.cc and Lib.h, and then link App.cc against it. I am not trying to compile all the source files together.

why are you declaring `bar` but defining `Bar`? Is that a typo? You should know upper and lower case does matter in linking symbols. — PeterT, Nov 24 '14 at 17:07
the symbol table still has the capitalized version `_ZN3Foo3BarEv`, so if that's your actual output that would explain it — PeterT, Nov 24 '14 at 17:12
You are not using -L linker flag. Gcc won't search your current dir for libraries. What it finds when supplied with `-lLib` is a mystery. Try adding `-L.` to the link command. — n. m. could be an AI, Nov 24 '14 at 17:17
@n.m., Please see edits to the question, where `-L` has been added and the output of `nm` has been updated. — merlin2011, Nov 24 '14 at 17:32
When you post code, including build commands, please always copy and paste actual code that you have just tried. — n. m. could be an AI, Nov 24 '14 at 18:22
@n.m., That is a fair point. I originally typed it originally because it was so short and I didn't want to use the mouse. :P — merlin2011, Nov 24 '14 at 18:31

rodrigo · Accepted Answer · 2014-11-24T17:50:45.967

When you link a library with -lLib, the linker looks for a file named libLib.so in the standard library paths, but the current directory is not usually between them.

You have two options:

g++ -std=c++11 -o App App.cc -L. -lLib

Or else:

g++ -std=c++11 -o App App.cc libLib.so

Note, however, that when running the program, the dynamic linker will look for the library following its own rules, and those may not include the current directory either.

IIRC, using -L. -lLib will make the runtime dynamic linker look the library in the standard paths. So to make it work you'll have to export LD_LIBRARY_PATH=. or something like that. Or install the library in /usr/lib.

But if you use the full name of the SO to the linker, then the full path of that file will be stored in the executable header and all will just work... until you move/install the program, then it will break badly....

That, unles the SO file has been linked with the --soname option... You can check what is happening with the objdump -p App | grep NEEDED.

As you can see, rules of shared linking are complicated. That's why libtool was invented in the first place!

UPDATE:

You have an error here:

$ g++ -std=c++11 -fPIC -shared -o Lib.o Lib.cc

should be:

$ g++ -std=c++11 -fPIC -shared -o Lib.o -c Lib.cc

Your command makes Lib.o a shared library, not a object file. With your command, the following line:

$ g++ -std=c++11 -shared -o libLib.so Lib.o

builds a shared object without code, because Lib.o is not a shared object at all!.

I have updated the question with both typo corrections and addition of `-L` flag. I still get the same compiler error. Further, I tried using your second approach with the same result. — merlin2011, Nov 24 '14 at 17:31
Have you been able to reproduce the problem using my example and verify that your fix works for this example? I am legitimately curious because I want to make sure it is not a system configuration issue. — merlin2011, Nov 24 '14 at 17:34
@merlin2011: No, I did't check it. But I've have done it now and added a new suggestion. — rodrigo, Nov 24 '14 at 17:51

Which compiler flag am I missing in my build on the so file?

Lib.h

Lib.cc

App.cc

1 Answers1