[EMAIL PROTECTED] writes: > Paul Pluzhnikov wrote: >> Static linking is bad for many reasons, and you shouldn't be doing >> unless you really really know what you are doing. > > Oh? The issue here is that we have a very large number of servers, not > all which can be guaranteed to have all the required shared libraries > (or same versions) of that on the development server.
So link against archive versions of these libraries, but never link statically against "system" libraries, libpthread and libc in particular. > Could you elaborate on why static linking is bad? It is bad because completely statically-linked executable is guaranteed to work only on the same system it was built on (and only until the next libc update). In particular, no UNIX system guarantees backward compatibility for statically linked executables (older static exe may not run on newer OS). See also: http://people.redhat.com/drepper/no_static_linking.html > It is Linux, SuSE 9.2. The project I am working on links against > libqdbm, libiconv, libz and libpthread (nptl version). The value for > "i" was around 60000, and the size of each object was 72 bytes. That's reserving over 4MB of space on the stack -- not at good idea. Do this twice in a row (one function that does this calls another function that also does this) and you exceed default thread stack of 8MB, and get dangerously close to 10MB default stack limit on many modern distributions. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
