If you have any say over the C/C++ code, you should bite the bullet and compile with -ansi -pedantic -Wall (ANSI C/C++, all warnings), and fix anything it turns up.

You may want to go further. Zack W:

``For modern C code, -Wstrict-prototypes, -Wmissing-prototypes, -Wwrite-strings are all a good idea. The last will require you to go and stick `const' in front of thousands of char *'s, but when we turned it on for GCC's own code, we found a couple dozen bugs that would never have been exposed otherwise.
-pedantic (which can be used without -ansi/-std=foo) is also a good move, although it can be as obnoxious as -W under some conditions.
The various -Wcast-* switches can be helpful, but can also prevent you from doing things that I personally think are good practice, such as throwing away all the non-const pointers to a write-once structure in malloced memory once you've done initializing it.
For typical Unix code, -ansi is not indicated, if only because it may cause the library headers to suppress prototypes for all the routines that are in POSIX but not C89, and that can do bad things - e.g. lseek() should not be implicitly declared.

A diatribe from Darren Moffat about static linking

[Posted to the `openssh-unix-dev' mailing list in March, 2001; edited very lightly.]

Static linking is evil and I really wish it wasn't supported anymore, see the following list of reasons why.

Issues with static linking

uStatic linking reduces the overhead when the program is started up, mainly because relocations and other start-up activities are done at compile time. However, static linking is generally discouraged. Here are some reasons:

Static linking prevents libc_psr.so.1 from working for platform specifics. This library automatically enables dynamically linked programs from linking in platform specific versions of various library routines which are optimized for a particular platform.
Static linking greatly increases working set size and disk footprint.
Statically linked executables are not necessarily binary compatible between releases. eg. statically linked programs that use libsocket will failed if compiled on 2.5.1 or less and run on 2.6
Running a static binary compiled on the base could cause a program to bypass some security checks when running under Trusted Solaris. This doesn't open a vulnerability but might mean a program won't get the extra privilege it was configured with.
Patches to system libaries for bug fixes and performance enhancements are not automatically picked up by the application. Consider security fixes to libc not being available to your application.
Some debugging libraries/tools will fail to work properly. eg. malloc debugging.
Localistation via setlocale(3c) / gettext(3c) is not supported when libc is statically linked.

When to use static linking

The binary is critical to system operation when in single user-mode either for the startup of the OS or for disaster recovery.
Statically linking a private (internal) libarary is okay.

Don'ts

Statically link against libc Statically link against libdl