On 2011-04-16, Philip Ashmore wrote:
> Nobody thought to mention that static linking can dramatically
> increase performance, or to put it the other way around, dynamic
> linking can incur serious runtime penalties.
At the expence of more RAM in use if multiple instances of the problem
are runnin
Hi there.
Nobody thought to mention that static linking can dramatically increase
performance,
or to put it the other way around, dynamic linking can incur serious
runtime penalties.
I don't want to encourage everyone to start static linking everywhere
just to get a
few percentage points in
"Steve M. Robbins" writes:
> On Sat, Apr 16, 2011 at 09:55:34AM +0200, Goswin von Brederlow wrote:
>> Given the cost that involves and that nobody has screamed about it in
>> the last 10 years I would opt for rephrasing it to "as needed". The
>> would reflect the current practice best.
>
> I don'
On Sat, Apr 16, 2011 at 09:47:08AM +0200, Andreas Metzler wrote:
> Steve M. Robbins wrote:
> >> As I've come to understanding, nowadays many libraries doesn't allow
> >> trivial static linkage,
> > I don't follow; it's generally as simple as using -static on
> > the link line. Pretty trivial.
>
]] Russell Coker
Hi,
| After Lenny was released I developed fixes for a number of serious library
| bugs that caused an important application written for one of my clients to
| crash. As some of the deployment platforms couldn't be guaranteed to have
the
| patched versions of the libraries
On Sat, Apr 16, 2011 at 09:55:34AM +0200, Goswin von Brederlow wrote:
> "Steve M. Robbins" writes:
>
> >> As I've come to understanding, nowadays many libraries doesn't allow
> >> trivial static linkage,
> >
> > I don't follow; it's generally as simple as using -static on
> > the link line. Pret
On Sat, 16 Apr 2011, Goswin von Brederlow wrote:
> Static linking of libc6 basically never makes sense. The same can be
> said for many other libs.
Yes, static linking of libc6 is a corner case that makes entirely statically
linked programs a bad idea. However mostly statically linked programs
"Steve M. Robbins" writes:
>> As I've come to understanding, nowadays many libraries doesn't allow
>> trivial static linkage,
>
> I don't follow; it's generally as simple as using -static on
> the link line. Pretty trivial.
Which a) might not be simple to get the build system to do and b) is fa
Steve M. Robbins wrote:
>> As I've come to understanding, nowadays many libraries doesn't allow
>> trivial static linkage,
> I don't follow; it's generally as simple as using -static on
> the link line. Pretty trivial.
[...]
Unless your are trying to link against a library that uses other
libra
> As I've come to understanding, nowadays many libraries doesn't allow
> trivial static linkage,
I don't follow; it's generally as simple as using -static on
the link line. Pretty trivial.
> and that it's generally not recommended to
> link statically in packages.
That is completely separate f
2011/4/16 Carl Fürstenberg:
> Thus I think we should consider updating the policy to either specify
> that a development package should provide a static library if
> possible, or that it shouldn't provide unless there are reasonable
> reasons for inclusions.
IMO Debian should err on the side of n
Currently section 8.3 in the policy specifies that "The static library
(libraryname.a) is usually provided in addition to the shared
version", i.e. it doesn't provides any guidelines if a development
package should or shouldn't provide a static library at all. Also it's
a question whenever packages
12 matches
Mail list logo
