Re: status of WITH_SHARED_TOOLCHAIN

2016-12-25 Thread 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

2016-12-25 Thread 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

2016-12-25 Thread 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

[Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference

2016-12-25 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863

--- Comment #12 from Antoine Brodin  ---
(In reply to Jan Beich (mail not working) from comment #11)
Unless the FreeBSD Security Officer changes his mind,  at 23:59 UTC December
31, 2016, FreeBSD 9.3, 10.1 and 10.2 will reach end-of-life and will no longer
be supported.

So 2017Q1 will not support those releases (unless so@ changes his mind).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference

2016-12-25 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863

--- Comment #11 from Jan Beich (mail not working)  ---
What's portmgr's plan for quarterly? Will 2017Q1 still support 9.x, 10.1, 10.2
and tag RELEASE_9_EOL at the end?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"