Re: status of WITH_SHARED_TOOLCHAIN

[Dimitry Andric]

On 25 Dec 2016, at 19:21, Nikolai Lifanov  wrote:
> 
> I would like to understand why WITH_SHARED_TOOLCHAIN is not the default.

This has been a long standing tradition.  Mainly, because you could
theoretically rescue yourself out of some bad situations by being able
to compile yourself out of it, since statically linked executables won't
break if e.g. libc.so or ld-elf.so is screwed up.  This is also the
reason that /sbin/init and /rescue/rescue are statically linked.

Additionally, it could give a minor performance improvement, that is if
the slowdown caused by dynamic linking is not offset by reading a larger
executable.


> My Raspberry Pi 3 is self-hosting with -j4 and doesn't run out of memory
> if the toolchain is shared. Is there a downside to this option?

I normally always use WITH_SHARED_TOOLCHAIN, and I have yet to encounter
any problem with it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: status of WITH_SHARED_TOOLCHAIN

[David Chisnall]

On 25 Dec 2016, at 19:21, Nikolai Lifanov  wrote:
> 
> Hi list,
> 
> I would like to understand why WITH_SHARED_TOOLCHAIN is not the default.
> My Raspberry Pi 3 is self-hosting with -j4 and doesn't run out of memory
> if the toolchain is shared. Is there a downside to this option?

Yes, there is a noticeable performance hit.  Buildworld takes 20-50% longer 
with a shared toolchain.  I don’t know if anyone has done any profiling of rtld 
to see if there’s any space for optimisation there (I suspect very little).

David



smime.p7s
Description: S/MIME cryptographic signature

status of WITH_SHARED_TOOLCHAIN

[Nikolai Lifanov]

Hi list,

I would like to understand why WITH_SHARED_TOOLCHAIN is not the default.
My Raspberry Pi 3 is self-hosting with -j4 and doesn't run out of memory
if the toolchain is shared. Is there a downside to this option?

Thanks,

- Nikolai Lifanov



signature.asc
Description: OpenPGP digital signature