为什么C程序针对C ++库编译并与C编译器链接，然后在运行时进行SIGILL？

Question

I recently had a problem with a 3rd party plugin that I wrote on IBM AIX. It took considerable time to track down. The plugin was in the form of a C executable. The executable was compiled against 3rd party libraries. A new version of those libraries was provided for a mandatory upgrade.

When compiled and linked with the IBM C compiler 12.1 my existing code would produce a binary that would work if the timezone was set using OLSON and crash with SIGILL and no backtrace available if the timezone was set using POSIX.

I was able to track down the crash to a call to the 3rd party API fairly quickly using debug printfs to a log file and flushing the log file. But it took some time for the 3rd party provider to mention that the new version of the API introduced the use of C++ libraries in their own code.

The problem was resolved by compiling with the IBM C compiler but linking with the IBM C++ linker (xlC).

So my questions are:

1) Why didn't the C linker fail to produce a valid executable?

A semi-valid binary must have been produced or the code would not have worked under OLSON timezone. That means all the symbols were present and any name mangling was handled (though possibly not correctly)

2) How do I determine if the binary produced by compiler and linker is valid?

The only way I can think to do this is to fully excercise the code as much as possible with unit testing.

3) How do I prevent similar from occuring for different code?

Should I always link with a C++ linker? That doesn't seem right to me.

I apologize that I can't post code, but I am not at liberty to do this.

Answer 1

Zsigmond has a lot of good statements. We need at least to see the link line and its options to help you much. Very often, open source links with "ignore unresolved symbols" because they don't understand the import files. So, the link will succeed in producing an utterly useless binary -- cause that is why it was asked to do.