Re: build failure (gmake: static declaration of 'bsd_signal' follows non-static declaration)

2016-06-07 Thread Takeshi Nakayama
>>> chris...@astron.com (Christos Zoulas) wrote > In article <20160607231429.GA28753@quark>, > Patrick Welche wrote: > > > >Revert? > > I just did a full build and it works; you must have installed headers > without libc. Or just cleanup tools/gmake directory to reconfigure

Re: build failure (gmake: static declaration of 'bsd_signal' follows non-static declaration)

2016-06-07 Thread Christos Zoulas
In article <20160607231429.GA28753@quark>, Patrick Welche wrote: > >Revert? I just did a full build and it works; you must have installed headers without libc. christos

Re: build failure (gmake: static declaration of 'bsd_signal' follows non-static declaration)

2016-06-07 Thread Patrick Welche
On Tue, Jun 07, 2016 at 03:01:42PM -0700, bch wrote: > /usr/src/tools/gmake/../../external/gpl2/gmake/dist/main.c:521:1: > error: static declaration of 'bsd_signal' follows non-static > declaration > bsd_signal (int sig, bsd_signal_ret_t func) > ^ > In file included from

Re: gcc 5.4 and dhcpcd

2016-06-07 Thread Patrick Welche
On Tue, Jun 07, 2016 at 05:36:20PM +0100, Nick Hudson wrote: > On 06/07/16 16:44, Patrick Welche wrote: > > On Tue, Jun 07, 2016 at 03:28:26PM +0100, Patrick Welche wrote: > > > (I'm doing a MKUPDATE build, and hoping that > > > /usr/include/g++/bits/stl_alog.h:66:35: fatal error: > > >

Re: gcc 5.4 and dhcpcd

2016-06-07 Thread Patrick Welche
On Tue, Jun 07, 2016 at 08:10:58PM +0100, Roy Marples wrote: > On Tuesday 07 June 2016 15:28:26 Patrick Welche wrote: > > You probably already saw this... On -current/amd64: > > > > /usr/src/external/bsd/dhcpcd/dist/dhcp-common.c: In function > > 'dhcp_set_leasefile ': > >

build failure (gmake: static declaration of 'bsd_signal' follows non-static declaration)

2016-06-07 Thread bch
dependall-gmake ===> tools dependall ===> tools/gmake install-gmake ===> tools install ===> tools/gmake Making install in glob Making install in config Making install in po if test "make" = "gettext-tools"; then /bin/sh /usr/src/tools/gmake/../../external/gpl2/gmake/dist/config/mkinstalldirs

Re: gcc 5.3 version of libasan is broken

2016-06-07 Thread Rin Okuyama
On 2016/06/08 1:20, Christos Zoulas wrote: I am trying to avoid having all these ifdefs in the common code, so that the upstream has a better chance to accept them. My idea was to do something like it is done in sanitizer_syscall_linux_x86_64.inc (but differently) In our case I think we could

Re: gcc 5.3 version of libasan is broken

2016-06-07 Thread Christos Zoulas
In article , Christos Zoulas wrote: > >Or perhaps what you have is better... I think that the file is full >of messy ifdefs, and a couple of more won't hurt. It would be better >if someone refactored it. I'll commit your changes for now. Also:

Re: gcc 5.4 and dhcpcd

2016-06-07 Thread Roy Marples
On Tuesday 07 June 2016 15:28:26 Patrick Welche wrote: > You probably already saw this... On -current/amd64: > > /usr/src/external/bsd/dhcpcd/dist/dhcp-common.c: In function > 'dhcp_set_leasefile ': > /usr/src/external/bsd/dhcpcd/dist/dhcp-common.c:833:1: error: stack > protector no t protecting

Re: gcc 5.4 and dhcpcd

2016-06-07 Thread Nick Hudson
On 06/07/16 16:44, Patrick Welche wrote: On Tue, Jun 07, 2016 at 03:28:26PM +0100, Patrick Welche wrote: (I'm doing a MKUPDATE build, and hoping that /usr/include/g++/bits/stl_alog.h:66:35: fatal error: bits/uniform_int_dist.h: No such file or directory will go away with a successful build...)

Re: gcc 5.3 version of libasan is broken

2016-06-07 Thread Christos Zoulas
On Jun 8, 1:03am, rokuy...@rk.phys.keio.ac.jp (Rin Okuyama) wrote: -- Subject: Re: gcc 5.3 version of libasan is broken | On 2016/06/07 23:42, Christos Zoulas wrote: | > I think it is better to do what linux does and write an internal_syscall() | > macro that just DTRT's instead of

Re: gcc 5.3 version of libasan is broken

2016-06-07 Thread Rin Okuyama
On 2016/06/07 23:42, Christos Zoulas wrote: I think it is better to do what linux does and write an internal_syscall() macro that just DTRT's instead of special-casing each syscall. Sorry, I cannot grasp what you mean. Let me explain more in details what I did. First, I defined three macros:

Re: gcc 5.4 and dhcpcd

2016-06-07 Thread Patrick Welche
On Tue, Jun 07, 2016 at 03:28:26PM +0100, Patrick Welche wrote: > (I'm doing a MKUPDATE build, and hoping that > /usr/include/g++/bits/stl_alog.h:66:35: fatal error: bits/uniform_int_dist.h: > No such file or directory > will go away with a successful build...) According to the changelog,

Re: gcc 5.3 version of libasan is broken

2016-06-07 Thread Christos Zoulas
On Jun 7, 10:49pm, rokuy...@rk.phys.keio.ac.jp (Rin Okuyama) wrote: -- Subject: Re: gcc 5.3 version of libasan is broken | On 2016/06/07 8:58, Christos Zoulas wrote: | > This is what I was thinking. Perhaps it is easier to use syscall for ILP32 | > and __syscall for LP64. But then there is

gcc 5.4 and dhcpcd

2016-06-07 Thread Patrick Welche
You probably already saw this... On -current/amd64: /usr/src/external/bsd/dhcpcd/dist/dhcp-common.c: In function 'dhcp_set_leasefile ': /usr/src/external/bsd/dhcpcd/dist/dhcp-common.c:833:1: error: stack protector no t protecting local variables: variable length buffer [-Werror=stack-protector]

Re: gcc 5.3 version of libasan is broken

2016-06-07 Thread Rin Okuyama
On 2016/06/07 8:58, Christos Zoulas wrote: This is what I was thinking. Perhaps it is easier to use syscall for ILP32 and __syscall for LP64. But then there is lseek... Yes. And it fails for LP64BE. I made the revised patch, where 3 kinds of internal_syscall macros are provided for different

Automated report: NetBSD-current/i386 build failure

2016-06-07 Thread NetBSD Test Fixture
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 2016.06.07.06.14.18. An extract from the build.sh output follows: