help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mysterious support for dynamic arrays?


From: Paul Pluzhnikov
Subject: Re: Mysterious support for dynamic arrays?
Date: Fri, 27 Oct 2006 20:38:02 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux)

ondrugs@gmail.com 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]