Den 02/05/2012 kl. 13.56 skrev John Baldwin:
Static version:
* 0.09 ms spent execve'ing /usr/bin/make
* The rest is mostly sysctl calls
Dynamic version:
* 0.09 ms spent execve'ing ./dynamicmake and /libexec/ld-elf.so.1
* 0.18 ms spent loading libc.so.7 (incl. reading /etc/libmap.conf and
On Thursday, May 03, 2012 5:18:15 am Erik Cederstrand wrote:
Den 02/05/2012 kl. 13.56 skrev John Baldwin:
Static version:
* 0.09 ms spent execve'ing /usr/bin/make
* The rest is mostly sysctl calls
Dynamic version:
* 0.09 ms spent execve'ing ./dynamicmake and /libexec/ld-elf.so.1
On Tuesday, May 01, 2012 6:46:04 pm Erik Cederstrand wrote:
Den 01/05/2012 kl. 15.55 skrev Gary Palmer:
If you want a high-level view of what goes on run
ldd `which ls`
check that it has libraries to load and doesn't say not a dynamic ELF
executable, and then run:
ktrace ls
On Apr 30, 2012, at 6:41 AM, Erik Cederstrand wrote:
Can anyone explain to me why the dynamically linked version is significantly
slower? What are the extra steps involved compared to a statically linked
binary?
At the risk of dramatically over-simplifying….
When a static binary is
Den 01/05/2012 kl. 07.52 skrev Tim Kientzle:
On Apr 30, 2012, at 6:41 AM, Erik Cederstrand wrote:
Can anyone explain to me why the dynamically linked version is significantly
slower? What are the extra steps involved compared to a statically linked
binary?
At the risk of dramatically
On Tue, May 01, 2012 at 01:53:58PM +0200, Erik Cederstrand wrote:
Den 01/05/2012 kl. 07.52 skrev Tim Kientzle:
On Apr 30, 2012, at 6:41 AM, Erik Cederstrand wrote:
Can anyone explain to me why the dynamically linked version is
significantly slower? What are the extra steps involved
Den 01/05/2012 kl. 15.55 skrev Gary Palmer:
If you want a high-level view of what goes on run
ldd `which ls`
check that it has libraries to load and doesn't say not a dynamic ELF
executable, and then run:
ktrace ls
kdump | more
All the system calls related to resolving and
Den 26/04/2012 kl. 22.30 skrev Chris Rees:
On 26 April 2012 20:15, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 26/04/2012 20:01, Chris Rees wrote:
hydra# cd /usr/ports time make MAKE=~crees/bin/make-static index
Generating INDEX-9 - please wait.. Done.
729.770u 120.841s
On Sat, Apr 28, 2012 at 11:03:17AM +0100, Bob Bishop wrote:
Yes. You to have a statically linked /rescue/sh on board, so what's the
point of /bin/sh being dynamic?
While you and I agree on this, the primary reason we went with a
dynamically linked root was for PAM and NSS support -- which are
Hi,
On 28 Apr 2012, at 04:12, David O'Brien wrote:
On Thu, Apr 26, 2012 at 12:38:03PM +0100, Bob Bishop wrote:
Apparently, current dependencies are much more spread, e.g. /bin/sh
is dynamically linked [etc]
That seems like a bad mistake, because it would prevent even booting
single-user
On Apr 28, 2012, at 3:03 AM, Bob Bishop wrote:
On 28 Apr 2012, at 04:12, David O'Brien wrote:
On Thu, Apr 26, 2012 at 12:38:03PM +0100, Bob Bishop wrote:
Apparently, current dependencies are much more spread, e.g. /bin/sh
is dynamically linked [etc]
That seems like a bad mistake,
On Thu, Apr 26, 2012 at 05:41:40PM +0400, Ruslan Ermilov wrote:
On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote:
I think it is time to stop building the toolchain static. I was told that
original reasoning for static linking was the fear of loosing the ability
to
On Fri, Apr 27, 2012 at 11:58:59AM +0300, Konstantin Belousov wrote:
On Thu, Apr 26, 2012 at 05:41:40PM +0400, Ruslan Ermilov wrote:
On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote:
[...]
Patch below makes the dynamically linked toolchain a default, adding an
On Fri, Apr 27, 2012 at 02:58:06PM +0400, Ruslan Ermilov wrote:
Regarding your patch...
By placing SHARED_TOOLCHAIN to __DEFAULT_NO_OPTIONS list in
bsd.own.mk, you already had MK_SHARED_TOOLCHAIN set to no by
default, which preserves the current status quo of building
toolchain static. But
On Thu, Apr 26, 2012 at 12:38:03PM +0100, Bob Bishop wrote:
Apparently, current dependencies are much more spread, e.g. /bin/sh
is dynamically linked [etc]
That seems like a bad mistake, because it would prevent even booting
single-user if rtld/libraries are broken.
When one enters single
On Thu, Apr 26, 2012 at 07:52:01AM -0400, John Baldwin wrote:
You could use /rescue/sh as your single-user shell. Of course, that would
perhaps let you still be able to recompile things if you had a static
toolchain. :)
Having the toolchain static has saved me in exactly this way.
--
--
I think it is time to stop building the toolchain static. I was told that
original reasoning for static linking was the fear of loosing the ability
to recompile if some problem appears with rtld and any required dynamic
library. Apparently, current dependencies are much more spread, e.g. /bin/sh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 26 Apr 2012, at 10:35, Konstantin Belousov wrote:
I think it is time to stop building the toolchain static. I was told that
original reasoning for static linking was the fear of loosing the ability
to recompile if some problem appears with
On Thursday, April 26, 2012 7:38:03 am Bob Bishop wrote:
Hi,
On 26 Apr 2012, at 10:35, Konstantin Belousov wrote:
I think it is time to stop building the toolchain static. I was told that
original reasoning for static linking was the fear of loosing the ability
to recompile if some
On 26 Apr 2012, at 12:38, Bob Bishop wrote:
Hi,
On 26 Apr 2012, at 10:35, Konstantin Belousov wrote:
I think it is time to stop building the toolchain static. I was told that
original reasoning for static linking was the fear of loosing the ability
to recompile if some problem appears
Den 26/04/2012 kl. 11.35 skrev Konstantin Belousov:
I think it is time to stop building the toolchain static. I was told that
original reasoning for static linking was the fear of loosing the ability
to recompile if some problem appears with rtld and any required dynamic
library. Apparently,
On 2012-04-26 13:53, David Chisnall wrote:
...
I did some benchmarks a little while ago, and there was, I think, about a 5%
slowdown on buildworld with a dynamically linked clang vs a statically linked
one on x86-64. Ideally, I'd want the bootstrap compiler to be statically
linked but the
Oops, just replied privately before:
On Apr 26, 2012 12:39 PM, Chris Rees utis...@gmail.com wrote:
On Apr 26, 2012 10:36 AM, Konstantin Belousov kostik...@gmail.com
wrote:
I think it is time to stop building the toolchain static. I was told that
original reasoning for static linking was
On Thu, Apr 26, 2012 at 07:52:01AM -0400, John Baldwin wrote:
On Thursday, April 26, 2012 7:38:03 am Bob Bishop wrote:
Hi,
...
You could use /rescue/sh as your single-user shell. Of course, that would
perhaps let you still be able to recompile things if you had a static
toolchain. :)
On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote:
I think it is time to stop building the toolchain static. I was told that
original reasoning for static linking was the fear of loosing the ability
to recompile if some problem appears with rtld and any required dynamic
On Apr 26, 2012 2:42 PM, Ruslan Ermilov r...@freebsd.org wrote:
On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote:
I think it is time to stop building the toolchain static. I was told
that
original reasoning for static linking was the fear of loosing the
ability
to
On 26/04/2012 20:01, Chris Rees wrote:
hydra# cd /usr/ports time make MAKE=~crees/bin/make-static index
Generating INDEX-9 - please wait.. Done.
729.770u 120.841s 7:45.10 182.8%920+2676k 5251+116484io 7750pf+0w
hydra# time make MAKE=~crees/bin/make-dynamic index
Generating
On 26 April 2012 20:15, Matthew Seaman m.sea...@infracaninophile.co.uk wrote:
On 26/04/2012 20:01, Chris Rees wrote:
hydra# cd /usr/ports time make MAKE=~crees/bin/make-static index
Generating INDEX-9 - please wait.. Done.
729.770u 120.841s 7:45.10 182.8% 920+2676k 5251+116484io
28 matches
Mail list logo
