Programming

Whether it is a .so shared and dynamic library, a .a static library or a .o static object file, you need prototypes and such. A .h may support several subroutines, which maybe all or part of a library. It's nice to try to keep the sizeof the .h down, generally. For something like a RDBMS access library, there is often one include file, but it can include many others. That's very convenient, but the .h files can be kept small.

If the actual memory consuming objects are instantiated in the library not the .h, you can include excess .h files with no runtime cost, as the linker will only pull in the dynamic objects the code actually uses.

Not only are .so files dynamically linked, they are memory mapped and the ram pages that support them are shared by all linked processes. That is why the mnemonic is shared object. It saves ram and increases cache hit rates. You can even find ways to put main() in the shared library - code can look at the name it was exec()'d on, so 100 processes can run the same main() (one per library).

I can't see how the problem can be missing prototypes. That wouldn't get "symbol not found" errors on basic things like "operator delete( void * )" at final link time.

Missing prototypes should fail at compile time, not link time.

It's like he's linking against the wrong C++ runtime. Maybe that's the problem? A way out-of-date C++ runtime?

Well, begin at the beginning. cerr is really std::cerr cerr - C++ Reference

Someone has to say use std somewhere. C++ Basic Input/Output

Code:

The standard error stream (cerr):
 
The predefined object cerr is an instance of ostream class. The cerr object is said to be attached to the standard error device, 
which is also a display screen but the object cerr is un-buffered and each stream insertion to cerr causes its output to appear immediately.
 
The cerr is also used in conjunction with the stream insertion operator as shown in the following example.
 
#include <iostream> 
using namespace std; 
int main( ){
    char str[] = "Unable to read....";
    cerr << "Error message : " << str << endl;
}
 
When the above code is compiled and executed, it produces following result:
 
Error message : Unable to read....

My cerr declaration lookup:

Code:

CScope WWW 201211
 
Find this C symbol: 'cerr'
  /opt/aCC/include/iostream/iostream.h  <global>            626  extern ostream_withassign cerr ;
  /opt/aCC/include/iostream/iostream.h  <global>            780  #define cerr ((ostream_withassign&)__tcerr)

OK, what does the mangled name look like in whatever C++ runtime the OP's link step is looking in? And what's the mangled name in his object files?

The nm command will tell you: Man Page for nm (opensolaris Section 1) - The UNIX and Linux Forums

I never care what mangled names are for the past couple decades or so, as I am generally satisfied that they are mangled in C++ and 'extern "C++" { ... }', and not in C or 'extern "C" { ... }', and if the mangling and arguments and return and name are right, they link.

You may not care how the mangled names are created and what they look like, but the linker sure does.

Hence the OP's error messages.

Well, mangling has nothing to do with linkage errors that looking at the name will solve. C++ objects are mangled, C objects are not, and we have the keys to tell the linker which is which.

The first error is cerr, which is c++ called in c++, so mangling is irrelevant. Not either defining std as the default package or using the long name meant the name did not link, for the real name is std::cerr even before mangling. Is there any contention about that? Can we see what the fixed code produces, once this line is added:

Code:

using namespace std;