Re: -current build failure after SVN r340130

Confirmed to be fixed by SVN r340134 - thanks! On 11/4/18 1:50 PM, Michael Butler wrote: > ===> libexec/dma/dma-mbox-create (all) > Building > /usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o > In file included from /usr/src/contrib/dma/dma-mbox-create.c:51: >

Re: -current build failure after SVN r340130

On Sun, Nov 04, 2018 at 01:50:31PM -0500, Michael Butler wrote: > ===> libexec/dma/dma-mbox-create (all) > Building > /usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o > In file included from /usr/src/contrib/dma/dma-mbox-create.c:51: >

-current build failure after SVN r340130

===> libexec/dma/dma-mbox-create (all) Building /usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o In file included from /usr/src/contrib/dma/dma-mbox-create.c:51: /usr/obj/usr/src/amd64.amd64/tmp/usr/include/capsicum_helpers.h:161:1: error: all paths through this function

Re: Fixed with r289221 (was: Re: CURRENT: build failure with clang 3.7.0)

On Tue, 13 Oct 2015 18:30:08 +0200 Dimitry Andric wrote: > On 10 Oct 2015, at 19:39, Dimitry Andric wrote: > > > > On 10 Oct 2015, at 18:12, O. Hartmann wrote: > > ... > >> Is there any chance that the failure of clang 3.7.0

Fixed with r289221 (was: Re: CURRENT: build failure with clang 3.7.0)

On 10 Oct 2015, at 19:39, Dimitry Andric wrote: > > On 10 Oct 2015, at 18:12, O. Hartmann wrote: > ... >> Is there any chance that the failure of clang 3.7.0 with some AVX-equipted >> Intel >> processors gets fixed soon? > > I reported the bug

Re: CURRENT: build failure with clang 3.7.0

Am Fri, 9 Oct 2015 23:07:18 +0200 Dimitry Andric schrieb: > On 07 Oct 2015, at 13:33, O. Hartmann wrote: > ... > > The buildworld error when building with CXXFLAGS+= -std=c++11 > > is > > then > > > > [...] > > cc -O2 -pipe -O3 -O3

Re: CURRENT: build failure with clang 3.7.0

On 10 Oct 2015, at 18:12, O. Hartmann wrote: ... > Is there any chance that the failure of clang 3.7.0 with some AVX-equipted > Intel > processors gets fixed soon? I reported the bug upstream, did number of bisections to drill down to the root cause (hopefully), and

Re: CURRENT: build failure with clang 3.7.0

On 07 Oct 2015, at 13:33, O. Hartmann wrote: ... > The buildworld error when building with CXXFLAGS+= -std=c++11 is > then > > [...] > cc -O2 -pipe -O3 -O3 -pipe -march=native -I. > -I/usr/obj/usr/src/lib/ncurses/menu/../ncurses >

Re: CURRENT: build failure with clang 3.7.0

On Wed, 07 Oct 2015 13:50:54 -0700 John Baldwin wrote: > On Wednesday, October 07, 2015 09:09:50 PM O. Hartmann wrote: > > Am Wed, 07 Oct 2015 11:03 -0700 > > John Baldwin schrieb: > > > > > On Wednesday, October 07, 2015 01:33:23 PM O. Hartmann wrote: > > >

Re: CURRENT: build failure with clang 3.7.0

On Wednesday, October 07, 2015 09:09:50 PM O. Hartmann wrote: > Am Wed, 07 Oct 2015 11:03 -0700 > John Baldwin schrieb: > > > On Wednesday, October 07, 2015 01:33:23 PM O. Hartmann wrote: > > > On Wed, 7 Oct 2015 13:23:48 +0200 > > > Dimitry Andric wrote: > >

CURRENT: build failure with clang 3.7.0

I hit on a box this nasty/sticky error when performing buildworld. /usr/src is on r288980 svn status gives #: [src] svn st ? .snap ? .sujournal ? etc/rc.d/tests ? sys/amd64/conf/HAGENVONTRONJE By the way, it seems that etc/rc.d/tests doesn't get deleted via "make

Re: CURRENT: build failure with clang 3.7.0

> On Oct 7, 2015, at 00:37, O. Hartmann wrote: > > I hit on a box this nasty/sticky error when performing buildworld. … > By the way, it seems that etc/rc.d/tests doesn't get deleted via "make > delete-old”. make delete-old only cleans up things installed to the

Re: CURRENT: build failure with clang 3.7.0

Am Wed, 07 Oct 2015 11:03 -0700 John Baldwin schrieb: > On Wednesday, October 07, 2015 01:33:23 PM O. Hartmann wrote: > > On Wed, 7 Oct 2015 13:23:48 +0200 > > Dimitry Andric wrote: > > > > > On 07 Oct 2015, at 09:37, O. Hartmann

Re: CURRENT: build failure with clang 3.7.0

On Wed, 7 Oct 2015 13:23:48 +0200 Dimitry Andric wrote: > On 07 Oct 2015, at 09:37, O. Hartmann wrote: > > > > I hit on a box this nasty/sticky error when performing buildworld. > > > > /usr/src is on r288980 > ... > > --- ieee802_11_common.o ---

Re: CURRENT: build failure with clang 3.7.0

On 07 Oct 2015, at 09:37, O. Hartmann wrote: > > I hit on a box this nasty/sticky error when performing buildworld. > > /usr/src is on r288980 ... > --- ieee802_11_common.o --- ... > -c >

Re: CURRENT: build failure with clang 3.7.0

On Wednesday, October 07, 2015 01:33:23 PM O. Hartmann wrote: > On Wed, 7 Oct 2015 13:23:48 +0200 > Dimitry Andric wrote: > > > On 07 Oct 2015, at 09:37, O. Hartmann wrote: > > > > > > I hit on a box this nasty/sticky error when performing

CURRENT BUILD FAILURE sys/modules/cxgbe

cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-omit-frame-pointer

Re: CURRENT BUILD FAILURE sys/modules/cxgbe

On Mon, 2013-10-07 at 16:52 -0400, Outback Dingo wrote: cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq

Re: CURRENT BUILD FAILURE sys/modules/cxgbe

On Mon, Oct 7, 2013 at 5:00 PM, Ian Lepore i...@freebsd.org wrote: On Mon, 2013-10-07 at 16:52 -0400, Outback Dingo wrote: cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe -DHAVE_KERNEL_OPTION_HEADERS

Re: CURRENT BUILD FAILURE sys/modules/cxgbe

On Oct 7, 2013, at 23:04, Outback Dingo outbackdi...@gmail.com wrote: On Mon, Oct 7, 2013 at 5:00 PM, Ian Lepore i...@freebsd.org wrote: On Mon, 2013-10-07 at 16:52 -0400, Outback Dingo wrote: cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc

r241879 -current build failure in lib/libwrap

Output of buildworld: http://pastebin.com/z0r03QpZ thanks -kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: -current build failure

On 24 Jul 2012, at 23:43, Konstantin Belousov wrote: As kan rightfully notes, the assumption that %fs:0 == *%fs:0 holds for userspace on amd64, and the same is true for %gs userspace on i386. The change you committed to clang/llvm/whatever it called just breaks useful optimization for

Re: -current build failure

On Wed, Jul 25, 2012 at 09:03:58AM +0100, David Chisnall wrote: On 24 Jul 2012, at 23:43, Konstantin Belousov wrote: As kan rightfully notes, the assumption that %fs:0 == *%fs:0 holds for userspace on amd64, and the same is true for %gs userspace on i386. The change you committed to

Re: -current build failure

On 23 Jul 2012, at 20:53, David Chisnall wrote: On 23 Jul 2012, at 20:18, Konstantin Belousov wrote: Longer description is that pc_curthread is offset 0 if %gs-based. The dereferenced pointer point to the struct thread, which contains td_proc pointer at offset 8. Instead, clang seems to

Re: -current build failure

On Tue, Jul 24, 2012 at 10:08:13PM +0100, David Chisnall wrote: On 23 Jul 2012, at 20:53, David Chisnall wrote: On 23 Jul 2012, at 20:18, Konstantin Belousov wrote: Longer description is that pc_curthread is offset 0 if %gs-based. The dereferenced pointer point to the struct thread,

Re: -current build failure

On Sun, Jul 22, 2012 at 09:01:19PM +0300, Konstantin Belousov wrote: [Why don't you bother to configure your mail client properly ? Answering to email with 500+ long lines is not trivial] On Sun, Jul 22, 2012 at 06:18:12PM +0100, David Chisnall wrote: On 21 Jul 2012, at 22:16, Konstantin

Re: -current build failure

On 23 Jul 2012, at 20:18, Konstantin Belousov wrote: Longer description is that pc_curthread is offset 0 if %gs-based. The dereferenced pointer point to the struct thread, which contains td_proc pointer at offset 8. Instead, clang seems to dereference td_proc from offset 8 based on %gs, or

Re: -current build failure

On 21 Jul 2012, at 22:16, Konstantin Belousov wrote: On Sat, Jul 21, 2012 at 04:00:45PM -0400, Kim Culhan wrote: On Fri, Jul 20, 2012 at 11:40 AM, Dimitry Andric d...@freebsd.org wrote: On 2012-07-20 16:49, Kim Culhan wrote: Seeing this for r:238655 ... In file included from

Re: -current build failure

[Why don't you bother to configure your mail client properly ? Answering to email with 500+ long lines is not trivial] On Sun, Jul 22, 2012 at 06:18:12PM +0100, David Chisnall wrote: On 21 Jul 2012, at 22:16, Konstantin Belousov wrote: On Sat, Jul 21, 2012 at 04:00:45PM -0400, Kim Culhan

Re: -current build failure

On 2012-07-21 01:16, Konstantin Belousov wrote: On Fri, Jul 20, 2012 at 10:07:05PM +0100, David Chisnall wrote: On 20 Jul 2012, at 17:33, Konstantin Belousov wrote: It is not related to dtrace at all, and indeed OFFSETOF_CURTHREAD is 0. This is a bug in clang, we compile our kernel in

Re: -current build failure

On Sat, Jul 21, 2012 at 01:35:26PM +0200, Dimitry Andric wrote: On 2012-07-21 01:16, Konstantin Belousov wrote: On Fri, Jul 20, 2012 at 10:07:05PM +0100, David Chisnall wrote: On 20 Jul 2012, at 17:33, Konstantin Belousov wrote: It is not related to dtrace at all, and indeed

Re: -current build failure

On Sat, Jul 21, 2012 at 02:43:16PM +0300, Konstantin Belousov wrote: On Sat, Jul 21, 2012 at 01:35:26PM +0200, Dimitry Andric wrote: On 2012-07-21 01:16, Konstantin Belousov wrote: On Fri, Jul 20, 2012 at 10:07:05PM +0100, David Chisnall wrote: On 20 Jul 2012, at 17:33, Konstantin

Re: -current build failure

On 21 Jul 2012, at 00:16, Konstantin Belousov wrote: Ok, I stand corrected. But the standard does not say what you claim either. It only specifies that NULL pointer is unequal to any pointer to object or function (implicitely saying that you can create a C object or function pointer to which

Re: -current build failure

On Sat, Jul 21, 2012 at 12:59:07PM +0100, David Chisnall wrote: On 21 Jul 2012, at 00:16, Konstantin Belousov wrote: Ok, I stand corrected. But the standard does not say what you claim either. It only specifies that NULL pointer is unequal to any pointer to object or function (implicitely

Re: -current build failure

On Fri, Jul 20, 2012 at 11:40 AM, Dimitry Andric d...@freebsd.org wrote: On 2012-07-20 16:49, Kim Culhan wrote: Seeing this for r:238655 ... In file included from /usr/src/sys/modules/dtrace/dtrace/../../../sys/pcpu.h:44: ./machine/pcpu.h:226:13: error: indirection of non-volatile null

Re: -current build failure

On Sat, Jul 21, 2012 at 04:00:45PM -0400, Kim Culhan wrote: On Fri, Jul 20, 2012 at 11:40 AM, Dimitry Andric d...@freebsd.org wrote: On 2012-07-20 16:49, Kim Culhan wrote: Seeing this for r:238655 ... In file included from /usr/src/sys/modules/dtrace/dtrace/../../../sys/pcpu.h:44:

Re: -current build failure

On Sat, Jul 21, 2012 at 5:16 PM, Konstantin Belousov kostik...@gmail.com wrote: On Sat, Jul 21, 2012 at 04:00:45PM -0400, Kim Culhan wrote: On Fri, Jul 20, 2012 at 11:40 AM, Dimitry Andric d...@freebsd.org wrote: On 2012-07-20 16:49, Kim Culhan wrote: Seeing this for r:238655 ... In

-current build failure

Seeing this for r:238655 === dtrace/dtrace (depend) @ - /usr/src/sys machine - /usr/src/sys/amd64/include x86 - /usr/src/sys/x86/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f

Re: -current build failure

On 2012-07-20 16:49, Kim Culhan wrote: Seeing this for r:238655 ... In file included from /usr/src/sys/modules/dtrace/dtrace/../../../sys/pcpu.h:44: ./machine/pcpu.h:226:13: error: indirection of non-volatile null pointer will be deleted, not trap [-Werror,-Wnull-dereference]

Re: -current build failure

On Fri, Jul 20, 2012 at 05:40:32PM +0200, Dimitry Andric wrote: On 2012-07-20 16:49, Kim Culhan wrote: Seeing this for r:238655 ... In file included from /usr/src/sys/modules/dtrace/dtrace/../../../sys/pcpu.h:44: ./machine/pcpu.h:226:13: error: indirection of non-volatile null

Re: -current build failure

On 20 Jul 2012, at 17:33, Konstantin Belousov wrote: It is not related to dtrace at all, and indeed OFFSETOF_CURTHREAD is 0. This is a bug in clang, we compile our kernel in freestanding environment. The copies of the C spec that I have do not differentiate between freestanding and hosted

Re: -current build failure

On Fri, Jul 20, 2012 at 10:07:05PM +0100, David Chisnall wrote: On 20 Jul 2012, at 17:33, Konstantin Belousov wrote: It is not related to dtrace at all, and indeed OFFSETOF_CURTHREAD is 0. This is a bug in clang, we compile our kernel in freestanding environment. The copies of the C spec

CPUTYPE cr*p (Was: [kris@FreeBSD.org: 5.0-CURRENT build failure of ports you maintain])

- Forwarded message from Kris Kennaway [EMAIL PROTECTED] - One or more ports that you maintain are currently unbuildable under FreeBSD 5.0-CURRENT/i386 on the FreeBSD package-building cluster. [...] - End forwarded message - ... gmake[2]: Entering directory

Re: CPUTYPE cr*p (Was: [kris@FreeBSD.org: 5.0-CURRENT build failure of ports you maintain])

As Matthew N. Dodd wrote: I really /hate/ this CPU feature crap. So do I. I've also found that the only way to reliablly disable it is to comment it out from sys.mk. Maybe i should do this using a preconfigure script in my port... :-) -- cheers, Jorg .-.-. --... ...--

Re: CPUTYPE cr*p (Was: [kris@FreeBSD.org: 5.0-CURRENT build failure of ports you maintain])

On Mon, Nov 18, 2002 at 02:14:58PM +0100, Joerg Wunsch wrote: What am i supposed to do in order to get cross-compilation working properly? I've already tried a number of things, and my -current from August at least gave in when setting MACHINE_ARCH=avr for the cross-coimpilation.

Re: CPUTYPE cr*p (Was: [kris@FreeBSD.org: 5.0-CURRENT build failure of ports you maintain])

As Kris Kennaway wrote: What am i supposed to do in order to get cross-compilation working properly? NO_CPU_CFLAGS=yes This is documented in make.conf. At least not in my version of make.conf's man page. Just checked, neither in the current version. I (and obviously not only I) wish

Re: CPUTYPE cr*p (Was: [kris@FreeBSD.org: 5.0-CURRENT build failure of ports you maintain])

On Mon, Nov 18, 2002 at 08:57:24PM +0100, Joerg Wunsch wrote: As Kris Kennaway wrote: What am i supposed to do in order to get cross-compilation working properly? NO_CPU_CFLAGS=yes This is documented in make.conf. At least not in my version of make.conf's man page. Just

Re: CPUTYPE cr*p (Was: [kris@FreeBSD.org: 5.0-CURRENT build failure of ports you maintain])

On Mon, 18 Nov 2002 12:08:49 -0800, Kris Kennaway [EMAIL PROTECTED] said: It's described in the file itself. Can you please file a PR about the missing manpage documentation? make.conf is no longer installed in -current. A user trying to understand why some glop is being added automatically

Re: CPUTYPE cr*p (Was: [kris@FreeBSD.org: 5.0-CURRENT build failure of ports you maintain])

On Mon, Nov 18, 2002 at 06:15:24PM -0500, Garrett Wollman wrote: On Mon, 18 Nov 2002 12:08:49 -0800, Kris Kennaway [EMAIL PROTECTED] said: It's described in the file itself. Can you please file a PR about the missing manpage documentation? make.conf is no longer installed in -current.