Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Phil Blundell <philb@gnu.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] util-linux: Remove static libraries from -dev packages
Date: Wed, 26 Sep 2012 15:05:11 +0100	[thread overview]
Message-ID: <1348668311.8662.110.camel@ted> (raw)
In-Reply-To: <1348651706.31293.89.camel@phil-desktop>

On Wed, 2012-09-26 at 10:28 +0100, Phil Blundell wrote:
> On Wed, 2012-09-26 at 09:49 +0100, Richard Purdie wrote:
> > On Tue, 2012-09-25 at 18:11 -0400, Colin Walters wrote:
> > > On Tue, 2012-09-25 at 23:00 +0100, Phil Blundell wrote:
> > > 
> > > > That'd be inconsistent with other packages, since we do generally build
> > > > and ship the static libraries.  Having a big switch to turn off static
> > > > libraries globally seems like a fine plan, but I can't see any obvious
> > > > reason why the util-linux ones are any more useless than the rest.
> > > 
> > > Makes sense.  I wonder if there are actually any users of the static
> > > libraries.
> > > 
> > > For what it's worth in gnome-ostree I do just globally pass
> > > --disable-static by default.
> > 
> > I tested this a while back to see what performance difference it made.
> > The answer was "nothing too significant", I don't have the exact timings
> > handy. I do remember having to exclude sqlite-native from the list since
> > pseudo static links against it.
> 
> It's slightly surprising that it doesn't make that much of a difference,
> given that building static libraries does essentially double the number
> of compilations for library code.  Though, of course, glibc doesn't
> support --disable-static nowadays and there might be a few other big
> packages that have the same issue.
> 
> I guess that if you have enough cores, compilation count becomes
> something of a non-issue since it's one of the few things that does
> parallelize very well.  It might be interesting to repeat the
> measurements of --disable-static on a machine with only a few CPUs and
> see whether it makes more of a difference there.

Yes, admittedly I probably did test that in a highly parallel
environment and was focusing on the critical path timings as a result.

> Out of interest, why does pseudo static-link against sqlite anyway?

Given the crazy things that pseudo does and the way it works as an ld
preload that keeps itself preloaded, I'm guessing it stops itself having
to worry about finding its own libraries correctly. I just added a
package override for sqlite3-native which wasn't a big deal.

Cheers,

Richard




  reply	other threads:[~2012-09-26 14:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-25 12:54 [PATCH] util-linux: Remove static libraries from -dev packages Phil Blundell
2012-09-25 21:59 ` Colin Walters
2012-09-25 22:00   ` Phil Blundell
2012-09-25 22:11     ` Colin Walters
2012-09-26  8:49       ` Richard Purdie
2012-09-26  9:28         ` Phil Blundell
2012-09-26 14:05           ` Richard Purdie [this message]
2012-09-30 16:22             ` Phil Blundell
2012-09-26 14:50       ` Mark Hatle
2012-09-27 15:42 ` Saul Wold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1348668311.8662.110.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=philb@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox