You are here:

C++/C++ Problem


Hi Ralph,
       I  have one problem with porting a C++ application originally developed on IBM compiler on solaris to Sun Forte CC compiler on solaris.

      The code is compiling OK on the solaris box except for some code which has got some IBM header files like istring.h,iset.h,ilists,h.

    The application is referring some functions out of these IBM header files which are not available on this server but on are available on other solaris box.

     If I import these IBM related Header files from the other solaris box and include these in one of the include directories of teh current solaris box will these compile? or do i have to import any other things other than this also without changing the code.

     Any help in this regard is appreciated.


In short your code will most likely compile with the header files in a suitable location - assuming the versions on the originating Sun box are compatible with your C++ compiler. Not all (in fact few) compilers are standard C++ compliant and I remember Sun as being one such offender although I am not familiar with the exact version(s) you are using. This also assumes that the 'imported' header files do not include other headers you have not (yet) 'imported'...

Now most code has some definitions of functions and global data (hopefully very little global data!) in implementation files traditionally having extensions like .cpp, .cxx., .cc or .C. These are the files actually compiled and that produce object code which is packaged for presentation to the linker directly as individual object code files, static library archives or fully linked shared object libraries.

The exception is code that uses templates which on some systems contains all the declarations and definitions in the header files included in each compilation module (translation unit). However, UN*X systems often use a template model that use a variation in which the templates are compiled as the result of a pre-link phase to the build (part of the linker's job). In such an implementation I found the template implementation code (in .cpp, .cxx, .cc, .C, etc. files) had to be in the same directory as the associated header file. In this case you would also require these files to be 'imported'.

So you will probably find that although the code compiles the target executable(s) will not link. You will have to find the libraries (static libXXX.a files or shared  object files) that contain the compiled definitions of the items declared but undefined in the 'imported' header files. If the 'imported' code just produces object files - then you might have to locate the implementation (.cpp, .cxx, .cc, .C) files and add them to your project (or create a separate library project for them) as usually such files are intermediate and can be deleted after a build.

Finally I can envisage that the resulting executable may not run if the imported code required access to other shared object libraries you do not have - or maybe have the wrong version of or have the location incorrectly specified. The main scenario I can think of is that of the imported code building a shared object library which your application then links against. A shared object library implies that that library had previously been linked on the system it originated on. If your system does not have all the shared object libraries it depends on available to it at runtime then your application will not run.  


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2017 All rights reserved.

[an error occurred while processing this directive]