Linux gcc 链接问题

Question

I have two libraries , named ( lib1 and lib2) , both are not dependent on each other. I do not have control over how these libraries are built. When I try to link them the order of linking dictates on different behaviors within the final executable,

For example:

If I link them as [1]

gcc $(CC_FLAGS) -o app.out -llib1 -llib2 

everything works fine

But, if I link them as following [2]

gcc $(CC_FLAGS) -o app.out -llib2 -llib1 

A segmentation fault occurs during executable run.

Any advice or pointer on the cause of this problem would be helpful.

Update:

Both of these libraries are dependent on another dynamic library, which is Apache Thrift ( Version 0.11.0) the segfault occurs on lib1 if it is compiled [1] option above, and exception occurs on lib2 if it compiled with option [2] above.

Update 2

The issue is due to global namespace violations between the libraries. Since thrift uses IDL mechanism to generate source files, Both libraries ( somehow ) defined the same namespace for their IDL definitions, hence such behavior was observed. Accepting the answer below as correct one since it addresses the question indirectly.

Thank you.

Answer 1

Is it possible that there resides a symbol (same name) in both of those libs?

Which one the linker will use to resolve an usage of such a symbol depends on the order (not sure where I've read this).

(HINT: This is just a guess)

So lets assume lib1 defines this function:

void foo( int, char* );

And lib2 defines:

void foo( int );

And somewhere we have a call like:

foo( 42 );

Now if the linker finds the definition of lib1, this foo most probably will get funny garbage as its 2nd argument.

Update (reaction to uptdate of question)

It is hard to make precise statements with the insight we have. So I can only point out some guesses and hope they'll help you. So sorry for my inaccuracy here. But I've no idea how else I could continue:

Guess 1 :

Update says: " segfault occurs on lib1 if it is compiled [1] option above, and exception occurs on lib2 if it compiled with option [2] "

ABI incompatible exception handling in lib1? Something like this ?

Guess 2 (Or should I name it "story"):

Our code inherits (and implements) an abstract class declared in thrift header. This impl then gets passed to lib1/lib2 (through our conflicting symbol) which perform calls to this impl. But lib1 used a different thrift header during compilation (or used conditional compiling, or used another version of thrift).