On 2/16/16 2:55 AM, Outback Dingo wrote:
> seems current is broken due to a missing file
> /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error:
> 'config_local.h' file not found
>
It's fixed now.
--
Regards,
Bryan Drewery
___
On 19 Jul, O'Connor, Daniel wrote:
On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
However, Crochet _does_ build on the NFS client _and_ when the
source tree isn't in /usr/src which makes this issue very strange
:-/
I've
On Sun, Jul 19, 2015 at 11:05:48PM -0700, Don Lewis wrote:
On 19 Jul, O'Connor, Daniel wrote:
On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
However, Crochet _does_ build on the NFS client _and_ when the
source tree
On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
However, Crochet _does_ build on the NFS client _and_ when the source
tree isn't in /usr/src which makes this issue very strange :-/
I've seen similar errors in rescue... (no
On Sat, 2015-07-18 at 10:26 -0700, Simon J. Gerraty wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
However, Crochet _does_ build on the NFS client _and_ when the source
tree isn't in /usr/src which makes this issue very strange :-/
I've seen similar errors in rescue... (no NFS) though I
O'Connor, Daniel dar...@dons.net.au wrote:
So, it seems MAKEOBJDIRPREFIX only works as an environmental variable
Weird, I could have sworn I have set it on the command line and had it
work, but..
In most normal usage you will likely not notice a difference.
It is only when a makefile is
On 20 Jul 2015, at 04:29, Simon J. Gerraty s...@juniper.net wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
But this did not..
make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64
Nor should it.
There are several makefiles in the tree that expect to be able to
change
O'Connor, Daniel dar...@dons.net.au wrote:
Yeah the subject is wrong (I just updated it).
I just did a build like so and it worked..
env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld
That's the right way to use it.
But this did not..
make -j 8 buildworld
On Sun, Jul 19, 2015 at 10:31:36AM -0600, Ian Lepore wrote:
I've been following this saga (on irc and here) as much as I have time
for, and I can't escape the feeling that it is the directory structure
at fault somehow, but I can't quite put my finger on it.
I never (ever) build from
Given that we have (or at least had at one time) some of those magical
... paths that cause bmake to search up the hierarchy for its .mk
files, I wonder if an odd relationship between src and obj dir confuses
it, or if it somehow wanders into a wrong src tree while searching?
Based on
On 20 Jul 2015, at 11:40, Simon J. Gerraty s...@juniper.net wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
So, it seems MAKEOBJDIRPREFIX only works as an environmental variable
Weird, I could have sworn I have set it on the command line and had it
work, but..
In most normal usage
O'Connor, Daniel dar...@dons.net.au wrote:
However, Crochet _does_ build on the NFS client _and_ when the source
tree isn't in /usr/src which makes this issue very strange :-/
I've seen similar errors in rescue... (no NFS) though I cannot
quite recall the cause other than it seems very
On 18 Jul 2015, at 13:59, Tim Kientzle t...@kientzle.com wrote:
Crochet defaults MAKEOBJDIRPREFIX to ${WORKDIR}/obj if you have not already
set it to something else. (This avoids cross-polluting the builds if you do
regular manual cross-builds on the same machine.)
If you’re having
On Jul 16, 2015, at 9:57 PM, O'Connor, Daniel dar...@dons.net.au wrote:
On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote:
r285066 fixed a POLA violation w.r.t. the old NFS client where the new
client didn't return an EEXIST error return for symlink or mkdir to userland.
On 17 Jul 2015, at 14:27, O'Connor, Daniel dar...@dons.net.au wrote:
On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote:
r285066 fixed a POLA violation w.r.t. the old NFS client where the new
client didn't return an EEXIST error return for symlink or mkdir to userland.
The
Daniel O'Conner wrote:
I am seeing the following breakage when building -current and the source is
on NFS
make -j 4 buildworld
...
--- rescue.all__D ---
--- rescue ---
MAKEOBJDIRPREFIX=/usr/obj/src/FreeBSD-HEAD/rescue/rescue make -f rescue.mk
exe
--- sbin.all__D ---
--- pfctl_qstats.o
On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote:
r285066 fixed a POLA violation w.r.t. the old NFS client where the new
client didn't return an EEXIST error return for symlink or mkdir to userland.
The behaviour of not returning this error to userland (which was inherited
On Sunday, February 03, 2013 11:26:53 am O. Hartmann wrote:
CURRENT, as of recent Revision 246285 (see below) fails and
crashes/reboots on an Ivy-Bridge platform (see below). Since the box
does not have debugging switched on (not yet, will do eventually
Monday), Last thing I see on screen is
Am 02/04/13 20:50, schrieb John Baldwin:
On Sunday, February 03, 2013 11:26:53 am O. Hartmann wrote:
CURRENT, as of recent Revision 246285 (see below) fails and
crashes/reboots on an Ivy-Bridge platform (see below). Since the box
does not have debugging switched on (not yet, will do eventually
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uninitialized
On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote:
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34 +0300:
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
On 18.01.2013 22:37, David Wolfskill wrote:
On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote:
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-01-18 13:39:01 -0500, John-Mark Gurney wrote:
Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34
+0300:
On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov
a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all) cc -O2 -pipe
From: Poul-Henning Kamp [EMAIL PROTECTED]
Date: Fri, 01 Mar 2002 15:07:48 +0100
/flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:324: size of ar
ray `remotehost' has non-integer type
/flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:327: syntax err
or before
Niels Chr. Bank-Pedersen [EMAIL PROTECTED] writes:
On Thu, Dec 06, 2001 at 02:26:31AM +0100, Martin Heller wrote:
The 'make buildworld' stops while doing the 'make depend'-stage in the
usr.sbin/keyserv/ directory with an 'Error 2' .
Sources 2h old , current system 24h.
I think the
On Thu, Dec 06, 2001 at 02:26:31AM +0100, Martin Heller wrote:
The 'make buildworld' stops while doing the 'make depend'-stage in the
usr.sbin/keyserv/ directory with an 'Error 2' .
Sources 2h old , current system 24h.
I think the breakage is actually pam related and occurs in
usr.bin/login:
My log is:
=== usr.bin/login
rm -f .depend
mkdep -f .depend -a-DLOGIN_ACCESS -DLOGALL -I/usr/obj/usr/src/i386/usr/include
/usr/src/usr.bin/login/login.c /usr/src/usr.bin/login/login_access.c
/usr/src/usr.bin/login/login_fbtab.c
In file included from /usr/src/usr.bin/login/login.c:78:
In message [EMAIL PROTECTED] Harti Brandt writes:
: Version 1.83 of that file breaks the GENERIC build. You probably meant to
: write:
Just fixed.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Poul-Henning Kamp [EMAIL PROTECTED] wrote:
=== usr.bin/fetch
/flat/src/usr.bin/fetch/fetch.c: In function `main':
/flat/src/usr.bin/fetch/fetch.c:757: `vtty' undeclared (first use in this function)
Noticed this in my `make release' attempt yesterday, too.
--
cheers, Jorg
On Mon, 28 May 2001 21:45:02 +0200, Joerg Wunsch wrote:
=== usr.bin/fetch
/flat/src/usr.bin/fetch/fetch.c: In function `main':
/flat/src/usr.bin/fetch/fetch.c:757: `vtty' undeclared (first use in this function)
Noticed this in my `make release' attempt yesterday, too.
Fixed in
On Wed, May 02, 2001 at 08:27:36AM -0700, David Wolfskill wrote:
Just glanced through cvs-all; didn't see commits more recent than my last
CVSup:
CVSup started from cvsup14.freebsd.org at Tue May 1 03:47:00 PDT 2001
CVSup ended from cvsup14.freebsd.org at Tue May 1 03:55:45 PDT 2001
Did
Date: Wed, 2 May 2001 18:28:18 +0200
From: Anton Berezin [EMAIL PROTECTED]
CVSup started from cvsup14.freebsd.org at Tue May 1 03:47:00 PDT 2001
CVSup ended from cvsup14.freebsd.org at Tue May 1 03:55:45 PDT 2001
Did you do another buildworld between these CVSup's?
CVSup started from
On Wed, May 02, 2001 at 06:28:18PM +0200, Anton Berezin wrote:
On Wed, May 02, 2001 at 08:27:36AM -0700, David Wolfskill wrote:
It looks like the recent BSDPAN change has a problem - I am looking into
it.
The error occurred during stage 4: make dependencies:
===
Date: Thu, 15 Mar 2001 15:52:45 -0500
From: Michael Lucas [EMAIL PROTECTED]
Is it just me?
[breakage elided -- dhw]
Stop in /usr/src/usr.bin/kdump.
*** Error code 1
Didn't happen for me; CVSup started at 23:47 yesterday, completed at
Thu Mar 15 01:09:38 PST 2001.
Built just fine; runs
It seems Andrzej Tobola wrote:
Make that me too ...
I diagnosed problem - sys/sys/ata.h commited by sos is probably the culprit:
Its fixed, sorry, too many source trees here...
-Sren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
On Thu, 7 Dec 2000 [EMAIL PROTECTED] wrote:
I'm not a constraints expert either, but I noticed that when I try to
build a kernel WITHOUT any optimization, I get a failure in
/usr/src/sys/i386/atomic.h .
# make atomic.o
cc -c -O0 -pipe -Wall -Wredundant-decls -Wnested-externs
...
On Fri, 8 Dec 2000, John Baldwin wrote:
On 08-Dec-00 [EMAIL PROTECTED] wrote:
John,
I'm not a constraints expert either, but I noticed that when I try to
build a kernel WITHOUT any optimization, I get a failure in
/usr/src/sys/i386/atomic.h .
Compiling a kernel with anything
On 08-Dec-00 [EMAIL PROTECTED] wrote:
John,
I'm not a constraints expert either, but I noticed that when I try to
build a kernel WITHOUT any optimization, I get a failure in
/usr/src/sys/i386/atomic.h .
Compiling a kernel with anything but -O for optimization is not supported. gcc
I hit on it by accident (I normally compile with -O). That said, your
claim that gcc with no optimization generates incorrect code is
kind of counter-intuitive, wouldn't you say ?
I think you missed my point, I was just illustrating that optimizer seems
to affect (in my case apparently negate)
RE: possibly related data point - (was) Re: Current Broken!
On 08-Dec-00 [EMAIL PROTECTED] wrote:
I hit on it by accident (I normally compile with -O). That said,
your
claim that gcc with no optimization generates incorrect code is
kind of counter-intuitive, wouldn't you say ?
I've see
On 08-Dec-00 [EMAIL PROTECTED] wrote:
I hit on it by accident (I normally compile with -O). That said, your
claim that gcc with no optimization generates incorrect code is
kind of counter-intuitive, wouldn't you say ?
I've seen it do weird things with -O0 (mostly with C++). :) It's just
John,
I'm not a constraints expert either, but I noticed that when I try to
build a kernel WITHOUT any optimization, I get a failure in
/usr/src/sys/i386/atomic.h .
# make atomic.o
cc -c -O0 -pipe -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes
On Fri, 21 Jul 2000, Ollivier Robert wrote:
Am I the only one with this ?
cc -O -pipe -I. -I/src/src/lib/libncurses
-I/src/src/lib/libncurses/../../contrib/ncurses/ncurses
-I/src/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS
I saw that yesterday, and fixed it by:
cd /usr/src
make includes
cd /sys/i386/conf
config -r CRITTER
cd ../../compile/CRITTER
make depend
make
In message [EMAIL PROTECTED], Christopher Masto writes:
Yesterday and today, after a cvsup and
45 matches
Mail list logo
