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 r
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
> > > W
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 stati
Hi Dmitry,
I've been testing the follow-fork changes in GDB and ran into some weird
behavior. Without gdb, my test program (attached) prints something like:
fbsdvm% ./fe
fe(41042): initial process. Doing fork & exec...
fe(41043): child after fork. Doing exec...
fe(41043): child after exec. Exiti
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
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.
--
-
