I just got this failure during a make -j12 buildworld on head r280837.
--- realinstall ---
sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.o
/usr/obj/usr/src/tmp/usr/lib/crtbegin.o
sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.o
Hi,
a recently cvsupped copy of the RELENG_5_0 branch breaks in usr.bin/kdump:
=== usr.bin/kdump
sh /usr/src/usr.bin/kdump/mkioctls /usr/obj/usr/src/i386/usr/include
ioctl.c
/usr/src/usr.bin/kdump/mkioctls: awk: Argument list too long
/usr/src/usr.bin/kdump/mkioctls: awk: Argument list too
On Wed, Nov 20, 2002 at 14:54:12 +0200, Ruslan Ermilov wrote:
Index: b.c
===
RCS file: /home/ncvs/src/contrib/one-true-awk/b.c,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 b.c
David, this variant is nice enough. Please,
On Tue, Dec 03, 2002 at 11:09:20AM +0300, Andrey A. Chernov wrote:
On Wed, Nov 20, 2002 at 14:54:12 +0200, Ruslan Ermilov wrote:
Index: b.c
===
RCS file: /home/ncvs/src/contrib/one-true-awk/b.c,v
retrieving revision 1.1.1.2
On Thu, Nov 01, 2001 at 05:58:08PM -0800, David O'Brien wrote:
On Fri, Nov 02, 2001 at 04:44:12AM +0300, Andrey A. Chernov wrote:
Next bad thing discovered about new awk just looking at sourse code: it
not support locale (collating in regexp ranges too, of course). We just
make great
On Tue, Nov 19, 2002 at 14:52:02 +0200, Ruslan Ermilov wrote:
It seems that this patch has never been committed. This is a critical
bug that should be fixed before 5.0-RELEASE is out.
I agree. There is no locale yet and I never see that patch.
--
Andrey A. Chernov
http://ache.pp.ru/
On Wed, Nov 20, 2002 at 04:38:38AM +0300, Andrey A. Chernov wrote:
On Tue, Nov 19, 2002 at 14:52:02 +0200, Ruslan Ermilov wrote:
It seems that this patch has never been committed. This is a critical
bug that should be fixed before 5.0-RELEASE is out.
I agree. There is no locale yet and I
On Wed, Nov 20, 2002 at 14:27:53 +1100, Tim Robbins wrote:
On Wed, Nov 20, 2002 at 04:38:38AM +0300, Andrey A. Chernov wrote:
On Tue, Nov 19, 2002 at 14:52:02 +0200, Ruslan Ermilov wrote:
It seems that this patch has never been committed. This is a critical
bug that should be fixed
I have an error for a week and cannot make buildworld.
Where can I find panic other than real panic?
=== sbin/gbde
: : : :
cc -O -pipe -mcpu=pentiumpro -I/usr/src/sbin/gbde/../../sys -Werror -Wall
-Wno-format-y2k -Wno-uninitialized -c template.c
cc1: warnings being treated as errors
Yamada Ken Takeshi wrote:
I have an error for a week and cannot make buildworld.
Where can I find panic other than real panic?
=== sbin/gbde
: : : :
cc -O -pipe -mcpu=pentiumpro -I/usr/src/sbin/gbde/../../sys -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c template.c
cc1: warnings
Thank you for your prompt reply.
From: walt [EMAIL PROTECTED]
: ::
I can't see how line 222 includes an implicit declaration of 'panic'.
Is your file different?
I do not know why compiler says line 222, but it is
below 222 and my latest source says;
# cat
On Sat, Oct 26, 2002 at 10:13:02PM +0900, Yamada Ken Takeshi wrote:
# cat rijndael/rijndael-api-fst.c
::::
switch (cipher-mode) {
case MODE_ECB:
for (i = numBlocks; i 0; i--) {
rijndaelEncrypt(input,
Thank you!
From: Craig Rodrigues [EMAIL PROTECTED]
You don't have the latest sources. Did you use cvsup it
update your sources? If you used cvsup, then you
need to add src-sys-crypto to your cvsup file.
It was my cvsup prroblem. Fixed!!
msg45379/pgp0.pgp
Description: PGP
I ran into this also, and a bit of fiddling with a debugger was
un-enlightening -- it was segfaulting on a write to
__collate_substitute_table in parse.y. The pointer to the table didn't
appear to be corrupted, and it should have been in writable memory. It
also appeared to be properly aligned.
I don't know if I'm the only one having this problem, but I haven't
been able to make a complete buildworld for a couple of
days now. The last time I upgraded was arround August 5.
I have been getting a signal 11 consistently in the same spot.
=== secure/usr.sbin/sshd
=== share
===
I got that but a recent cvsup fixed it. Not sure what the problem was but
there were a few patches to colldef on Wednesday.
-Nate
On Thu, 15 Aug 2002, Mike Makonnen wrote:
I don't know if I'm the only one having this problem, but I haven't
been able to make a complete buildworld for a couple
On 12:10-0700, Aug 15, 2002, Mike Makonnen wrote:
I don't know if I'm the only one having this problem, but I haven't
been able to make a complete buildworld for a couple of
days now. The last time I upgraded was arround August 5.
I have been getting a signal 11 consistently in the same
Using 5-current code as of Apr/17/2002 15:00:00 GMT:
# pwd
/usr/src/gnu/usr.bin/groff/src/preproc/eqn
# ident Makefile
Makefile:
$FreeBSD: src/gnu/usr.bin/groff/src/preproc/eqn/Makefile,v 1.3
2002/04/11 11:06:03 ru Exp $
# make -n neqn
make: don't know how to make neqn. Stop
#
On Thu, Apr 18, 2002 at 10:29:23AM +0900, Makoto Matsushita wrote:
Using 5-current code as of Apr/17/2002 15:00:00 GMT:
# pwd
/usr/src/gnu/usr.bin/groff/src/preproc/eqn
# ident Makefile
Makefile:
$FreeBSD: src/gnu/usr.bin/groff/src/preproc/eqn/Makefile,v 1.3
2002/04/11
dwcjr Yeah, your make is broken, try rebuilding make by itself and
dwcjr install it then try the buildworld again
Ah, sorry. I've missed what src/usr.bin/make/str.c rev 1.19 said. I
just rebuilt make(1) and confirmed that it works again. Thanks.
-- -
Makoto `MAR' Matsushita
To Unsubscribe:
On Thu, 1 Nov 2001, Alfred Perlstein wrote:
Although I admit the fallout has been somewhat painful, let's
try to make do with it, if we disconnect the new awk I feel
that we will keep repeating this cycle, basically each activation
will see new problems requiring another disconnect. Let's
Dag-Erling Smorgrav wrote:
David O'Brien [EMAIL PROTECTED] writes:
because `echo' nicely removes \n's from env vars when it prints them.
des@des ~% foo='bar
quote baz'
des@des ~% echo $foo
bar
baz
des@des ~% /bin/echo $foo
bar
baz
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
On 02-Nov-2001 (12:58:55/GMT) Cyrille Lefevre wrote:
because `echo' nicely removes \n's from env vars when it prints them.
des@des ~% foo='bar
quote baz'
des@des ~% echo $foo
bar
baz
des@des ~% /bin/echo $foo
bar
baz
humm! what shell ($SHELL) are you using ?
Here (5.0-CURRENT 31-Oct
David O'Brien [EMAIL PROTECTED] writes:
because `echo' nicely removes \n's from env vars when it prints them.
des@des ~% foo='bar
quote baz'
des@des ~% echo $foo
bar
baz
des@des ~% /bin/echo $foo
bar
baz
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL
This is a quick heads-up.
If you have built -CURRENT within the last couple of days, and if you try
to use that (recently-built -CURRENT) as the host system for building
-CURRENT, the 3 patches I posted last night do appear to get through
the build process, but the result is a system that does
On Thu, Nov 01, 2001 at 11:42:13 -0800, David O'Brien wrote:
Mostly agreed. This has not been at all as smooth as I thought it would
be. Before going down this path, I would like to see if the current
state of the world isn't usable. I think (hope) all the nits are out
now. #6 is
On Fri, Nov 02, 2001 at 04:44:12AM +0300, Andrey A. Chernov wrote:
Next bad thing discovered about new awk just looking at sourse code: it
not support locale (collating in regexp ranges too, of course). We just
make great backward step switching to it.
I have a patch for that.
--
-- David
On Thu, Nov 01, 2001 at 11:04:13 -0800, David Wolfskill wrote:
Circumvention is to use /boot/loader.old, if it was built with gawk, or
somehow build a new loader after applying a patch that accomplishes
what this one does:
#
-# Note! This script uses strftime() which is a gawk-ism, and
* Sheldon Hearn [EMAIL PROTECTED] [011101 13:27] wrote:
On Thu, 01 Nov 2001 22:08:36 +0300, Andrey A. Chernov wrote:
No, awk should be fixed instead to conform POSIX specs, or switched back
to gawk.
It's not a binary decision. What we should probably do is:
1) Disconnect bwk-awk
On Thu, Nov 01, 2001 at 09:23:12PM +0200, Sheldon Hearn wrote:
No, awk should be fixed instead to conform POSIX specs, or switched back
to gawk.
It's not a binary decision. What we should probably do is:
1) Disconnect bwk-awk from the build.
2) Connect gawk to the build.
3) Fix
On Thu, 01 Nov 2001 13:31:04 CST, Alfred Perlstein wrote:
Although I admit the fallout has been somewhat painful, let's
try to make do with it, if we disconnect the new awk I feel
that we will keep repeating this cycle, basically each activation
will see new problems requiring another
On Thu, Nov 01, 2001 at 09:42:18PM +0200, Sheldon Hearn wrote:
Although I admit the fallout has been somewhat painful, let's
try to make do with it, if we disconnect the new awk I feel
that we will keep repeating this cycle, basically each activation
will see new problems requiring
Date: Wed, 31 Oct 2001 08:34:16 -0800 (PST)
From: David Wolfskill [EMAIL PROTECTED]
mkdep -f .depend -a-I/usr/obj/usr/src/i386/usr/include /usr/src/usr.bin/jot/jot.c
cd /usr/src/usr.bin/jot; make _EXTRADEPEND
echo jot: /usr/obj/usr/src/i386/usr/lib/libc.a .depend
=== usr.bin/kdump
sh
=== usr.bin/jot
rm -f .depend
mkdep -f .depend -a-I/usr/obj/usr/src/i386/usr/include /usr/src/usr.bin/jot/jot.c
cd /usr/src/usr.bin/jot; make _EXTRADEPEND
echo jot: /usr/obj/usr/src/i386/usr/lib/libc.a .depend
=== usr.bin/kdump
sh /usr/src/usr.bin/kdump/mkioctls
CVSup-ed one hour ago.
mkdep -f .depend -a-DINET6 -DPIM -DIOCTL_OK_ON_RAW_SOCKET -DHAVE_GETIFADDRS
-DHAVE_STDARG_H -I/usr/obj/src/src/i386/usr/include /src/src/usr.sbin/pim6sd/mld6.c
/src/src/usr.sbin/pim6sd/mld6_proto.c /src/src/usr.sbin/pim6sd/inet6.c
/src/src/usr.sbin/pim6sd/kern.c
On Thu, 6 Jul 2000 15:49:27 +0200
Ollivier Robert [EMAIL PROTECTED] said:
roberto /src/src/usr.sbin/pim6sd/cftoken.l:47: y.tab.h: No such file or directory
roberto mkdep: compile failed
roberto *** Error code 1
Thank you for reporting.
I just fixed.
Index: Makefile
Is my system environment broken?
I think so.
Thank you.
/usr/src tree on my system seemd to be broken.
I removed entire src tree and re-cvsuped it,
then I got no compile error at that point.
Thanks.
--- shige [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
My system is 4.0-CURRENT at Jan 31.
I try to upgrade it to -current (5-current),
but I get the following breakage.
Is my system environment broken?
Thanks!
--
stage 2: build tools
On Thu, May 18, 2000 at 12:51:42AM +0900, Shigeyuki Fukushima wrote:
My system is 4.0-CURRENT at Jan 31.
I try to upgrade it to -current (5-current),
but I get the following breakage.
Is my system environment broken?
I think so.
--
-- David ([EMAIL PROTECTED])
Disclaimer: Not
Anyone else, or am I special?
==ml
=== usr.bin/systat
cc -O -pipe -I/usr/src/usr.bin/systat/../../sys -I/usr/obj/usr/src/i386/usr/include
-c /usr/src/usr.bin/systat/cmds.c
cc -O -pipe -I/usr/src/usr.bin/systat/../../sys -I/usr/obj/usr/src/i386/usr/include
-c
Already fixed.
In message [EMAIL PROTECTED], Michael Lucas writes:
Anyone else, or am I special?
=== usr.bin/systat
cc -O -pipe -I/usr/src/usr.bin/systat/../../sys -I/usr/obj/usr/src/i386/usr/include
-c /usr/src/usr.bin/systat/iostat.c
In file included from
On Thu, 27 Apr 2000 12:52:21 +0100, "Peter Edwards (local)"
[EMAIL PROTECTED] said:
Compiling 5.0-CURRENT on 4.0-STABLE generates problems in getconf:
I got caught out by gperf version skew. gperf is now a build-tool (as
it should always have been) so this problem should be fixed in your
On Thu, Apr 27, 2000 at 12:46:43PM -0400, Garrett Wollman wrote:
I got caught out by gperf version skew. gperf is now a build-tool (as
it should always have been) so this problem should be fixed in your
next update.
Was this not ``make buildworld'' tested, or is there a change to
On Thu, Apr 27, 2000 at 12:46:43PM -0400, Garrett Wollman wrote:
I got caught out by gperf version skew. gperf is now a build-tool (as
it should always have been) so this problem should be fixed in your
next update.
cc -pipe -O -DSHELL -I. -I/FBSD/src/bin/sh -Wall -Wformat-static
On Thu, 27 Apr 2000 12:23:20 -0700, "David O'Brien" [EMAIL PROTECTED] said:
Was this not ``make buildworld'' tested, or is there a change to
gnu/usr.bin/gperf/Makefile you forgot to commit?
I am obviously *way* out of date with the state of the build
system I was trying to quickly get
Buildworld on 5.0-CURRENT is breaking here:
=== usr.bin/netstat
cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.bin/netstat/if.c
cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.bin/netstat/inet.c
cc -O -pipe -Wall
make -j8 buildworld fails with these messages for a second day in a row:
cd /usr/src/secure/lib/libssl; make _EXTRADEPEND
=== librsausa
mkdir: openssl: File exists
*** Error code 1
cp /usr/src/secure/lib/librsausa/../libcrypto/opensslconf-i386.h \
openssl/opensslconf.h
1 error
*** Error code 2
1
rm -f /usr/include/openssl* and rebuild.
* Alexander N. Kabaev ([EMAIL PROTECTED]) [000420 09:59]:
make -j8 buildworld fails with these messages for a second day in a row:
cd /usr/src/secure/lib/libssl; make _EXTRADEPEND
=== librsausa
mkdir: openssl: File exists
*** Error code 1
cp
On Thu, 20 Apr 2000, Alexander N. Kabaev wrote:
make -j8 buildworld fails with these messages for a second day in a row:
cd /usr/src/secure/lib/libssl; make _EXTRADEPEND
=== librsausa
mkdir: openssl: File exists
There is a dependency problem which is only biting some people here..for
On Thu, Jan 13, 2000 at 06:53:25AM -0500, Daniel Eischen wrote:
On Wed, 12 Jan 2000, David O'Brien wrote:
I don't see why a plain function like mkstemp() should be written so
specially. Couldn't all the hiding/changing done for threads be done
w/in open() itself? Neither HP-UX 10.30
On Wed, Jan 19, 2000 at 01:36:43AM -0800, David O'Brien wrote:
On Thu, Jan 13, 2000 at 06:53:25AM -0500, Daniel Eischen wrote:
On Wed, 12 Jan 2000, David O'Brien wrote:
I don't see why a plain function like mkstemp() should be written so
specially. Couldn't all the hiding/changing done
No, I was just busy doing other things.
There is potentially one good reason to leave these changes in place for
now: they allow proper thread cancellation in libc_r as it stands right
now. This seems to me like a good enough reason to leave the changes as is
until our grand new threads
On Wed, Jan 19, 2000 at 12:21:50PM -0500, Daniel Eischen wrote:
No, I was just busy doing other things.
There is potentially one good reason to leave these changes in place for
now: they allow proper thread cancellation in libc_r as it stands right
now. This seems to me like a good
On Wed, 19 Jan 2000, Jason Evans wrote:
On Wed, Jan 19, 2000 at 12:21:50PM -0500, Daniel Eischen wrote:
I guess I'm confused as to why you can't do what you need with
_XXX (internally used, non-cancellable function) and XXX (weak
reference to _XXX) within libc. libc_r would provide XXX
Jason Evans wrote:
Doen't that method still have the problem of propagating cancellation
points within the libc code? In another email I argued for the need for
three names, and your response was that three names aren't needed in the
context of the next-generation threads library, but it
What we had before the _libc_XXX name additions would have worked
as long as all internal uses of XXX inside libc were changed to
_XXX, and, when building for libc_r, all renamed (hidden) system
calls need _XXX defined as weak symbols to _thread_sys_XXX.
Actually, you don't even need to
On Wed, 12 Jan 2000, John Polstra wrote:
Jason Evans [EMAIL PROTECTED] wrote:
2) Make a separate copy of mktemp.c to remove the internal dependency.
I think this is the best approach -- likewise for getobjformat.c,
I agree. egcs provided "mkstemp.c" to handle the problem, but this
On Wed, 12 Jan 2000, David O'Brien wrote:
On Wed, Jan 12, 2000 at 07:00:01PM -0800, John Polstra wrote:
The buildworld problem that I introduced is due to cc_fbsd directly
compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my
opinion a questionable practice, since it
In article [EMAIL PROTECTED],
David O'Brien [EMAIL PROTECTED] wrote:
On Wed, Jan 12, 2000 at 07:00:01PM -0800, John Polstra wrote:
I _really_ don't like it when a program reaches waaay over into an
unrelated directory for its sources.
We already do that all over the place. :-)
We
With my CURRENT-tre updated within an hour ago ... Buildworld is broken.
cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H
-DDEFAULT_TARGET_VERSION=\ "2.95.2\"
-DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\"
-DPREFIX=\"/usr/obj/usr/src/i386/usr\"
On Wed, Jan 12, 2000 at 02:57:41PM +0100, Pascal Hofstee wrote:
With my CURRENT-tre updated within an hour ago ... Buildworld is broken.
cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H
-DDEFAULT_TARGET_VERSION=\ "2.95.2\"
-DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\"
On Wed, Jan 12, 2000 at 11:16:38AM -0800, Jason Evans wrote:
On Wed, Jan 12, 2000 at 02:57:41PM +0100, Pascal Hofstee wrote:
With my CURRENT-tre updated within an hour ago ... Buildworld is broken.
cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H
-DDEFAULT_TARGET_VERSION=\
On Wed, Jan 12, 2000 at 11:16:38AM -0800, Jason Evans wrote:
On Wed, Jan 12, 2000 at 02:57:41PM +0100, Pascal Hofstee wrote:
With my CURRENT-tre updated within an hour ago ... Buildworld is broken.
cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H
-DDEFAULT_TARGET_VERSION=\
The buildworld problem that I introduced is due to cc_fbsd directly
compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my
opinion a questionable practice, since it adds dependencies to the
internals of the libc code, which has just been proven to bite. =)
Aesthetics aside, I'm not
In article [EMAIL PROTECTED],
Jason Evans [EMAIL PROTECTED] wrote:
The buildworld problem that I introduced is due to cc_fbsd directly
compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my
opinion a questionable practice, since it adds dependencies to the
internals of the libc
On Wed, Jan 12, 2000 at 07:00:01PM -0800, John Polstra wrote:
The buildworld problem that I introduced is due to cc_fbsd directly
compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my
opinion a questionable practice, since it adds dependencies to the
internals of the libc
66 matches
Mail list logo
