You are here:

C++/C/C++ dynamic linking ?



I noticed some C/C++ applications need to go through compile, link process when we install them in a UNIX, for example, install Oracle on Linux operation system.

I think that is because C/C++ doesn't only support static link, is that right?
I wonder if there are some xxx.o files inside the installation program?
If installing on Windows operation system, does it still need to link?


In fact ISO standard C++ has _no_ support for dynamic linking. This is an operating environment thing.

I am not sure where you are coming from (thought wise) with the dynamic linking assumption. If a product needs to be compiled before it is used then it will need to be linked to produce the executable product(s) of the build process, be they applications or runtime libraries (dlls or shared object libraries).

The main reason that UNIX/Linux applications sometimes need rebuilding before installation is that there are so many variations between these systems! Often the first phase in the installation is configuration of the build environment and application source code - typically by setting up a collection of #define macros, and maybe even tool names (for example which C++ compiler is available g++, CC etc.) and capabilities.

The results are used to produce build scripts and to configure the source code, probably by having the source code include the configuration file with all the #define macros setup in it which are then checked in the code to select implementation variations using conditional compilation techniques:


// do it this way


// do it another way


// give up!
#  error "No support for some feature - cannot build on this platform"


I should mention that use of conditional compilation in this way can lead to very messy code if not carefully thought out.

A popular tool of this type is the GNU autoconf utility (see, manual at, and its related utilities such as automake.

A further difference would be in the object code format and native machine code used by the different OS variations. A SPARC processor for example is not going to execute Intel x86 code (at least not without a lot of help translating the machine code!). UNIX variations and Linux run on a wide variety of processor types.

MS Windows systems do not suffer so badly from this problem, although there are differences across versions of MS Windows they are not as widely different, although you will notice that Windows applications tend to specify which versions they are intended for. They are usually distributed pre-built - partly because Windows is used by many more less technical users. The current processor types that Windows versions run on is much less wide: Intel x86, AMD/Intel x64, and (for some servers) Intel Itanium, so the choice of machine code flavours has reduced to three, with 32-bit x86 being by far the most common, and often the only supported variation. The executable format is of course fixed!

However some Windows applications and tools are delivered in source form (or can be). Often these are open source products with UNIX/Linux and maybe other operating system versions. In such cases you still go though some sort of configuration / build phase to the installation, even if it is just running the correct make file for the Windows/compiler combination. Even so I have noticed that many such applications come with pre-build Windows installation packages...

I also note that if there are pre-built Linux installation packages they tend to be for a subset of all the possible variations, most usually 32-bit x86 builds in RPM or Debian package formats.

Just for balance I have recently been using the Boost libraries (see which have their own build system. I spent quite a bit of time getting everything to build on Windows XP Professional x64 Edition for 32-bit and 64-bit targets (mainly because 64 bit Windows targets are not properly supported by the Boost libraries at present). When I came to see how to build them for my Linux installation I found to my delight that they had already been installed pre-built and configured for me, presumably when I installed Linux (OK the version is one minor version number behind the one I downloaded and installed for Windows, but I have not had any problems so far!).  


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.