man strlen
You probably need to include string.h or strings.h.
Yes, see 'man strlen' for your system and copy the includes.
There are significant differences between 4.2 and 5.8 as far as C++ source code and C++ compilers are concerned. For starters you are going to have to provide prototypes for each function either through a header or in the source code itself.
yes when i included string.h it is working fine..it just a sample code
but for my entire project to migrate, any helpful information plzz ,as i vent found even in migration guide to include additional libraries.
---------- Post updated at 12:12 AM ---------- Previous update was at 12:05 AM ----------
I am facing linking issues in the project i feel it is because of the standard libraries, i included standard libraies of SUN CC 5.8
actually code is written in SUN CC 4.3
will theire be any compilation option to resolve linking issues
any solution to this problem is highly appriciated
Thanks in advance,
Revathi
Assuming that this is the problem you're still seeing, have you recompiled everything with the new compiler?
It looks like the compiler can't find the C++ run-time libraries. Or it can't find the proper version...
There's probably a command-line option for the CC command to have it emit intermediate steps, so we can see what commands are actually getting run, especially the final link step.
Or, you can just run that CC link command under truss, and just truss the execve() calls:
truss -f -t\!all -texecve -vexecve -a -e -o /output/file/name CC ...
You can also post here, where you're likely to get help from someone who actually works for Oracle on the Studio compilers:
yes, i have compiled all the code with the 5.8 compiler
Usually, good code uses #include and that provides any declaration or prototype, but if you wrote without prototypes, you have to add them to your includes, usually. I often put the calling code after the called code, so the prototype is the full subroutine, but if called externally, you need an include with a prototype (or hand made prototype copies all over the place, which is bad practice).
for a header file like iostream.h, there will be some .so file right, so do i need to link that .so file, if include header in my code, do i have to include corresponding .so file, explicitly???
as i could see
Iostream_init::Iostream_init(void)
Iostream_init::~Iostream_init(void)
these two prototypes in iostream.h, while linking i am getting Symbol referencing errors as mentioned in the thread.
so is there any way i can trace the corresponding .so file for .h file
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
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:
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:
using namespace std;
If the missing symbol mangled name looks something like "ZSt4cerr", the code is looking for the GNU C++ "cerr". If it looks like "__1cDstdEcerr", it's looking for the "standard" (non-compat=4) Solaris C++ runtime. If the code is looking for a simple "cerr", that's the "mangled" name in the Solaris compat=4 C++ runtime.
Dang. Whaddaya know?
Looks like the OP might be trying to link code compiled with "compat=4" with code that wasn't compiled with that option.
Too bad he seems to have abandoned this thread.
So, yeah, the specifics of the mangled name can and do provide a lot of information.
Never needed to know. It does what is needed. Yes, the original author is pages back?