>>> 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
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
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
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:
> > >
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 ':
> >
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
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
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:
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
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...)
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
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:
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,
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
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]
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
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:
17 matches
Mail list logo