On Tue, Jul 14, 2020 at 02:49:00AM +0200, Joerg Sonnenberger wrote:
> Replacing malloc is just as invalid from a strict standard compliance
> perspective, so *shrug*
Why is that?
We have e.g. shells/standalone-tcsh that does it. Is it broken now?
Martin
Updating src tree:
P src/distrib/sets/lists/man/mi
P src/doc/CHANGES
P src/etc/wscons.conf
P src/libexec/httpd/Makefile.boot
P src/libexec/httpd/bozohttpd.8
P src/libexec/httpd/bozohttpd.c
P src/libexec/httpd/small/Makefile
P src/sbin/wsconsctl/wsconsctl.8
P src/share/dict/web2
P
On Mon, Jul 13, 2020 at 04:28:56PM -0700, Greg A. Woods wrote:
> At Tue, 14 Jul 2020 00:28:46 +0200, Joerg Sonnenberger wrote:
> Subject: Re: recent changes to pthread_fork.c:fork() cause static linking to
> fail if the app provides its own malloc()
> >
> > On Mon, Jul 13, 2020 at 03:05:17PM
At Tue, 14 Jul 2020 00:28:46 +0200, Joerg Sonnenberger wrote:
Subject: Re: recent changes to pthread_fork.c:fork() cause static linking to
fail if the app provides its own malloc()
>
> On Mon, Jul 13, 2020 at 03:05:17PM -0700, Greg A. Woods wrote:
> > I think it is the following change (and
On Mon, Jul 13, 2020 at 03:05:17PM -0700, Greg A. Woods wrote:
> I think it is the following change (and perhaps more similar/related
> changes) which breaks static linking of applications which wish to
> supply their own implementation of malloc(), and which call, e.g.,
> fork():
I consider it a
I think it is the following change (and perhaps more similar/related
changes) which breaks static linking of applications which wish to
supply their own implementation of malloc(), and which call, e.g.,
fork():
This is because fork() now calls _malloc_prefork(), and if the
application's
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
successful build:
2020.07.13.10.35.17 jruoho src/libexec/httpd/small/Makefile,v 1.4
2020.07.13.10.46.10 mrg src/sys/uvm/uvm_physseg.c,v 1.16
2020.07.13.11.14.12 nia
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.07.13.05.52.50.
An extract from the build.sh output follows:
mv -f radeon_ci_dpm.d.tmp radeon_ci_dpm.d
---
Hello, all.
On 2020/07/06 17:03, Masanobu SAITOH wrote:
Hi, all.
On 2020/06/29 12:53, Kengo NAKAHARA wrote:
Hi,
On 2020/06/28 0:24, Patrick Welche wrote:
Trying a today's -current/amd64 with DIAGNOSTIC/DEBUG/LOCKDEBUG, I can
boot multiuser without a network. If I log in as root, as soon as
