Re: No way to tell when `long long' is or is not supported?
On Sun, Sep 08, 2002 at 11:50:17PM -0400, Garrett Wollman wrote: > GCC used to define a macro __STRICT_ANSI__ when `-ansi' was given on > the command line. The current version does not do this, It seems to work for me: $ cat foo.c #ifdef __STRICT_ANSI__ #error __STRICT_ANSI__ #endif $ /usr/bin/cc -ansi foo.c foo.c:2:2: #error __STRICT_ANSI__ The problem is it is also set for this: $ /usr/bin/cc -std=c99 foo.c foo.c:2:2: #error __STRICT_ANSI__ As you mentioned, this is now not a good test to decide if 'long long' is supported. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Ncurses official patch to solve xterm ac= problem, please commit.
This patch comes from Thomas. Please commit it to solve missing ACS characters problem with recent XFree entries termcap spam. This is the change I made to comp_parse.c (compare with similar logic in parse_entry.c): Index: ncurses/tinfo/comp_parse.c Prereq: 1.51 --- ncurses-5.2-20020824+/ncurses/tinfo/comp_parse.cSat Aug 10 20:59:06 2002 +++ ncurses-5.2-20020901/ncurses/tinfo/comp_parse.c Sat Aug 31 13:14:56 2002 @@ -52,7 +52,7 @@ #include #include -MODULE_ID("$Id: comp_parse.c,v 1.51 2002/08/11 00:59:06 tom Exp $") +MODULE_ID("$Id: comp_parse.c,v 1.52 2002/08/31 17:14:56 tom Exp $") static void sanity_check(TERMTYPE *); NCURSES_IMPEXP void NCURSES_API(*_nc_check_termtype) (TERMTYPE *) = sanity_check; @@ -81,8 +81,8 @@ NCURSES_EXPORT_VAR(ENTRY *) _nc_head = 0; NCURSES_EXPORT_VAR(ENTRY *) _nc_tail = 0; - static void - enqueue(ENTRY * ep) +static void +enqueue(ENTRY * ep) /* add an entry to the in-core list */ { ENTRY *newp = _nc_copy_entry(ep); @@ -461,9 +461,17 @@ || PRESENT(enter_reverse_mode))) _nc_warning("no exit_attribute_mode"); #endif /* __UNUSED__ */ - PAIRED(enter_standout_mode, exit_standout_mode) - PAIRED(enter_underline_mode, exit_underline_mode) + PAIRED(enter_standout_mode, exit_standout_mode); + PAIRED(enter_underline_mode, exit_underline_mode); } + +/* we do this check/fix in postprocess_termcap(), but some packagers + * prefer to bypass it... + */ +if (acs_chars == 0 + && enter_alt_charset_mode != 0 + && exit_alt_charset_mode != 0) + acs_chars = strdup(VT_ACSC); /* listed in structure-member order of first argument */ PAIRED(enter_alt_charset_mode, exit_alt_charset_mode); -- Thomas E. Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Release building broken for -current
jhay> md5 died on zero length files. You will have to upgrade the machine or jhay> at least do a buildworld with new source before you try a release again. Ya, that's exactly the problem on my buildbox... Thank you for the info. But if new md5(1) doesn't used by during a release, it's yet another similar problem to be fixed, since current "make release" don't (actually, cannot) update its own chroot sandbox before starting final release procedures... -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No way to tell when `long long' is or is not supported?
GCC used to define a macro __STRICT_ANSI__ when `-ansi' was given on the command line. The current version does not do this, which breaks detection of whether `long long' is allowed. (For some reason this is not hit in -current builds, but I have made some fixes to which trigger it in every program which sets WARNS.) Rather than trying to deduce whether `long long' is supported from other macros, I simply modified the compiler driver to tell us. (BTW, the `-posix' flag is utterly useless and should go.) If anyone has a better way to accomplish this, I'm all ears. (I suspect that the removal of __STRICT_ANSI__ was intentional, since it's not clear what that should mean in the face of multiple C language standards. The trouble is that C89 (implied by `-ansi') is otherwise indistinguishable from C89+GCC-extensions (implied by the absence of `-ansi'), and we need to make both cases work properly.) -GAWollman Index: freebsd-spec.h === RCS file: /home/ncvs/src/contrib/gcc/config/freebsd-spec.h,v retrieving revision 1.2 diff -u -r1.2 freebsd-spec.h --- freebsd-spec.h 10 May 2002 19:05:07 - 1.2 +++ freebsd-spec.h 8 Sep 2002 18:34:29 - @@ -85,12 +85,13 @@ the final CPP_PREDEFINES value. */ #define FBSD_CPP_PREDEFINES \ - "-D__FreeBSD__=5 -D__FreeBSD_cc_version=53 -Dunix -D__KPRINTF_ATTRIBUTE__ -Asystem=unix -Asystem=bsd -Asystem=FreeBSD" + "-D__FreeBSD__=5 -D__FreeBSD_cc_version=54 -Dunix -D__KPRINTF_ATTRIBUTE__ +-Asystem=unix -Asystem=bsd -Asystem=FreeBSD" #endif /* ! FREEBSD_NATIVE */ /* Provide a CPP_SPEC appropriate for FreeBSD. We just deal with the GCC - option `-posix', and PIC issues. */ + option `-posix', and PIC issues. Also deal with the problem of + detecting support for the `long long' type. */ #define FBSD_CPP_SPEC "\ %(cpp_cpu) \ @@ -98,6 +99,8 @@ %{munderscores: -D__UNDERSCORES__} \ %{maout: %{!mno-underscores: -D__UNDERSCORES__}} \ %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} \ + %{!ansi:%{!std=*:-D__LONG_LONG_SUPPORTED}%{std=gnu*:-D__LONG_LONG_SUPPORTED}}\ + %{std=c99:-D__LONG_LONG_SUPPORTED}\ %{posix:-D_POSIX_SOURCE}" /* Provide a STARTFILE_SPEC appropriate for FreeBSD. Here we add To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] C++ fix for flex
On Sat, Sep 07, 2002 at 11:55:08PM -0400, Craig Rodrigues wrote: > Hi, > > As I am fixing some of the C++ ports for GCC 3.2, I found a problem with lex. > The following patch is required for lex to generate code which > can compile with GCC 3.2. It applies to /usr/src/usr.bin/lex Committed. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/var/tmp/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sun Sep 8 18:17:50 PDT 2002 -- >>> Kernel build for GENERIC completed on Sun Sep 8 19:23:03 PDT 2002 -- >>> Kernel build for LINT started on Sun Sep 8 19:23:04 PDT 2002 -- ===> LINT config: Error: device "apm_saver" is unknown config: Error: device "cy" is unknown config: Error: device "cy" does not take a count config: 3 errors WARNING: kernel contains GPL contaminated ext2fs filesystem FYI: static unit limits for vcoda are set: NVCODA=4 FYI: static unit limits for dgb are set: NDGB=1 FYI: static unit limits for card are set: NCARD=1 FYI: static unit limits for meteor are set: NMETEOR=1 *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons in rcng ? - SOLVED
On Sun, 8 Sep 2002, Andrew Lankford wrote: > > What I've noticed is that vidcontrol refuses to change the console mode > to anything other than 80x25 or 80x30. I had it set at 80x60, but CURRENT > no longer likes that. I've also noticed that starting up XFree4.2.0's server > switches my console from 80x30 back to 80x25. Funky. > > In any case, I don't know anything about problems with /etc/rc.d/syscons, > but perhaps vidcontrol or the kernel is the culprit. > > Andrew Lankford > > >Hello, > > > >With the latest changes (1.8, 5th of Sep) to /etc/rc.d/syscons, syscons > >doesn't get initialized on my 5.0-CURRENT. > > > >Have I missed some new configuration options? > > > > > Very simple: /usr/src/etc/rc.d/syscons misses line run_rc_command "$1" Regards, Vladimir -- Vladimir Kushnir - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Termcap broken?
Adam Kranzel wrote: > I'm getting the error "Terminal must backspace." when trying to run > Slash'EM (a Nethack-derived game). I'm not sure what's gotten broken, > but if I copy over the termcap and termcap.db from a 4.6-STABLE machine > (of mid-August), it works again. Any suggestions on how to fix this? > My TERM environment variable is set to "xterm-color" right now, but > changing it to "xterm" doesn't seem to make a difference. The best thing to do would be to look at the source code for the program, and see what is making it spit out the message, and figure out how to correct that. One common issue in this are is terminals whose left arrow emits ASCII BS (^H) instead of having a seperate escape sequence (e.g. Televideo, Wyse, Hazeltine terminals). Another is people who define the PC console backspace key to send ASCII DEL instead of ASCII BS. The last is when there is no such thing as a backspace that is non-destructive (e.g. some terminals do not allow you to use ASCII BS sent to the terminal to move the curosr left, without actually erasing the character under the cursor). Like I said: look at the code, and find out what entries make it emit the error message that you are seeing. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 package build with gcc32 complete (HELP NEEDED!!)
On Sun, Sep 08, 2002 at 12:18:41PM +0200, Eirik Nygaard wrote: > I got some free time on my hands and will try to fix some ports, already fixed >sysutils/logmon. Thanks! Kris msg42760/pgp0.pgp Description: PGP signature
Re: troubles with the new GCC -- anyone else?
On Sun, Sep 08, 2002 at 02:30:06PM -0400, Mikhail Teterin wrote: > Is it just me, or do others have troubles too? I upgraded yesterday: Did you try the gcc patch Alexander posted the other day? Kris msg42759/pgp0.pgp Description: PGP signature
Termcap broken?
Hi... I'm getting the error "Terminal must backspace." when trying to run Slash'EM (a Nethack-derived game). I'm not sure what's gotten broken, but if I copy over the termcap and termcap.db from a 4.6-STABLE machine (of mid-August), it works again. Any suggestions on how to fix this? My TERM environment variable is set to "xterm-color" right now, but changing it to "xterm" doesn't seem to make a difference. thanks -Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unable to buildworld (new record, 18")
On 08-Sep-2002 (13:56:34/GMT) Giorgos Keramidas wrote: > There have been at least two gcc upgrades since then. I believe the > easiest way to upgrade to today's -current would be to install a > fairly recent snapshot from http://snapshots.jp.FreeBSD.org/ instead > of trying to debug the many ways in which a buildworld can fail. I'm obstinate :) I have tryed with a middle version (1 jul 2002) but it fails without and with make includes before build, now I'm trying with cvsup from 15 aug 2002 (as written by Munish Chopra on 1 sep: IIRC current was in good shape between August 12-15, 17, 18, 22-24) and it is still compiling (I'm crossing fingers)... If it complete (I hope it complete) is -CURRENT of 15 aug 2002 a reasonable version to install and to use to jump to today ones? Any comment? Thanks again, Riccardo. PS: It stopped on stage 4:libraries, something about crypt, now is running again with -DNO_WERROR -DNOCLEAN -DNOCRYPT ;^) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: troubles with the new GCC -- anyone else?
On Sun, Sep 08, 2002 at 02:30:06PM -0400, Mikhail Teterin wrote: > Is it just me, or do others have troubles too? I upgraded yesterday: > > mi@celsius:~ (101) cc -v > Using built-in specs. > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 3.2.1 [FreeBSD] 20020901 (prerelease) > > With ``-march=pentium2 -mmmx'' > > . there is a file or two in XFree86-4-Server, that cause an Internal Compiler > Error -- fixed with ``-march=pentium2 -mno-mmx'' (same trouble existed with > the previous version, AFAIR) > > . one file in libiconv causes ICE -- the workaround above does not work. But > ``-march=pentium -mmmx'' works. > > . in the kdelibs3, the kdecore/kkeyserver_x11.cpp will not compile regardless > of the architecture or optimization flags -- the ICE is in GCC's > cp/cp-lang.c:130, due, it seems, to the initialization complexity. Can't > think of a workaround :-\ Please submit preprocessed sources which trigger ICE to GCC's problem reporting database. There is very little (if anything at all) FreeBSD developers could and should do to help you with that. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unable to buildworld (new record, 18")
In message: <[EMAIL PROTECTED]> Riccardo Torrini <[EMAIL PROTECTED]> wrote: > > After some unsuccesfull buildworld I tryed updating includes but got > the same error. May be because my -CURRENT is pre-gcc_3.1 ? > Can I (Must I?) upgrade to an intermediate version between May and now? There have been at least two gcc upgrades since then. I believe the easiest way to upgrade to today's -current would be to install a fairly recent snapshot from http://snapshots.jp.FreeBSD.org/ instead of trying to debug the many ways in which a buildworld can fail. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: troubles with the new GCC -- anyone else?
There is problem with several ports and gcc 3.2, which ports got the problem is maped and is put out on the web: http://bento.freebsd.org/errorlogs/5-latest/, some has been fixed. On Sun, Sep 08, 2002 at 02:30:06PM -0400, Mikhail Teterin wrote: > Is it just me, or do others have troubles too? I upgraded yesterday: > > mi@celsius:~ (101) cc -v > Using built-in specs. > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 3.2.1 [FreeBSD] 20020901 (prerelease) > > With ``-march=pentium2 -mmmx'' > > . there is a file or two in XFree86-4-Server, that cause an Internal Compiler > Error -- fixed with ``-march=pentium2 -mno-mmx'' (same trouble existed with > the previous version, AFAIR) > > . one file in libiconv causes ICE -- the workaround above does not work. But > ``-march=pentium -mmmx'' works. > > . in the kdelibs3, the kdecore/kkeyserver_x11.cpp will not compile regardless > of the architecture or optimization flags -- the ICE is in GCC's > cp/cp-lang.c:130, due, it seems, to the initialization complexity. Can't > think of a workaround :-\ > > Yours, > > -mi > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Eirik Nygaard <[EMAIL PROTECTED]> PGP Key: 83C55EDE msg42754/pgp0.pgp Description: PGP signature
Re: troubles with the new GCC -- anyone else?
On Sun, Sep 08, 2002 at 02:30:06PM -0400, Mikhail Teterin wrote: > Is it just me, or do others have troubles too? I upgraded yesterday: > > mi@celsius:~ (101) cc -v > Using built-in specs. > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 3.2.1 [FreeBSD] 20020901 (prerelease) > > With ``-march=pentium2 -mmmx'' > Do not use -march=... -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
troubles with the new GCC -- anyone else?
Is it just me, or do others have troubles too? I upgraded yesterday: mi@celsius:~ (101) cc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20020901 (prerelease) With ``-march=pentium2 -mmmx'' . there is a file or two in XFree86-4-Server, that cause an Internal Compiler Error -- fixed with ``-march=pentium2 -mno-mmx'' (same trouble existed with the previous version, AFAIR) . one file in libiconv causes ICE -- the workaround above does not work. But ``-march=pentium -mmmx'' works. . in the kdelibs3, the kdecore/kkeyserver_x11.cpp will not compile regardless of the architecture or optimization flags -- the ICE is in GCC's cp/cp-lang.c:130, due, it seems, to the initialization complexity. Can't think of a workaround :-\ Yours, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons in rcng ?
What I've noticed is that vidcontrol refuses to change the console mode to anything other than 80x25 or 80x30. I had it set at 80x60, but CURRENT no longer likes that. I've also noticed that starting up XFree4.2.0's server switches my console from 80x30 back to 80x25. Funky. In any case, I don't know anything about problems with /etc/rc.d/syscons, but perhaps vidcontrol or the kernel is the culprit. Andrew Lankford >Hello, > >With the latest changes (1.8, 5th of Sep) to /etc/rc.d/syscons, syscons >doesn't get initialized on my 5.0-CURRENT. > >Have I missed some new configuration options? > > >Sincerely, >Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[no subject]
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Release building broken for -current
> > when bulding release on -current I get (since a couple of days): > > > rm -rf /R/stage/dists > > mkdir -p /R/stage/dists > > rolling base/base tarball > > mtree: line 0: dumpdates: No such file or directory > > *** Error code 1 > > > > Stop in /usr/src/release. > > Somehow dumpdates didn't get installed into > /R/stage/trees/base/usr/share/examples/etc md5 died on zero length files. You will have to upgrade the machine or at least do a buildworld with new source before you try a release again. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sio problems?
In message <[EMAIL PROTECTED]>, Wesley Morgan writes: >The sio driver was touched recently for the PUC stuff... Not sure if that >is the source of my problem, but suddenly I am seeing many many many of >these: > >sio1: 22 more interrupt-level buffer overflows (total 2943) > >Just started recently. Seems to happen most often when I cvsup. Happens >with and without ACPI, with and without using a shared interrupt. The changes to the PUC driver does not have anything to do with this I think. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sio problems?
The sio driver was touched recently for the PUC stuff... Not sure if that is the source of my problem, but suddenly I am seeing many many many of these: sio1: 22 more interrupt-level buffer overflows (total 2943) Just started recently. Seems to happen most often when I cvsup. Happens with and without ACPI, with and without using a shared interrupt. -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Clock runs too fast
In message <[EMAIL PROTECTED]>, Craig Rodrigues writes: >I reset my timecounter: >sysctl kern.timecounter.hardware=i8254 > >Now the clock seems to run at a more reasonable rate. > >Is there a problem with the ACPI code or with my >hardware (an ASUS P5A-B motherboard from about 3 or 4 years ago). > >How can I default to i8254 as my default timer? Is there >something I should put in device.hints? Put it in /etc/rc.early: sysctl kern.timecounterhardware=i8254 I have not been able to understand in what way this board fails :-( Does the time run uniformly fast, ie: 7 minutes every 5, all the time, or is it erratic ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make installworld cannot find files in /usr/bin
On Sat, 7 Sep 2002, Craig Rodrigues wrote: > I did a cvsup from a few hours ago, and rebuilt the world. > make buildworld worked fine. > > make installworld failed: > ===> usr.sbin/ppp^M > install -s -o root -g network -m 4554 ppp /usr/sbin > m4 /usr/src/usr.sbin/ppp/ppp.8.m4 >ppp.8 > m4: not found > > I also had similar problems in /usr/src/share/termcap, because > the Makefile there could not find /usr/bin/cap_mkdb and > /usr/bin/ex. > > I worked around the problem by replacing references > to m4, cap_mkdb, and ex > in /usr/src/usr.sbin/ppp/Makefile and /usr/src/share/termcap/Makefile > with fully qualified path names. > > Any ideas what could cause this? Some local problem with timestamps, together with a bug in bsd.files.mk (it uses a hack to create dependencies, and this results in things being rebuilt at install time if something is out of date; building things at install times is an error and the error happens to be detected because some utilities needed for building are not in $PATH). > My environment has /usr/bin in its PATH. Also, if I manually > cd to either of those directories and do: make install, then > it finds the programs in /usr/bin with no problem. The error is not detected in this case because there are too many utilities in $PATH. Building at install time would still fail if the relevant obj directories are not writable. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Clock runs too fast
Craig Rodrigues schrieb: >Hi, > >I have been having this problem with -current for the past 2 weeks now >(I am new to -current and just started using it 2 weeks ago). >I just did a cvsup and rebuilt the kernel and rebuilt the world. > >My clock seems to be running too fast, and I keep resetting it >with ntpdate. > >[...] > >Now the clock seems to run at a more reasonable rate. > >Is there a problem with the ACPI code or with my >hardware (an ASUS P5A-B motherboard from about 3 or 4 years ago). > >How can I default to i8254 as my default timer? Is there >something I should put in device.hints? > I had similar problems with a Gigabyte GA-5AX (also with ALi Aladdin V chipset). Without setting debug.acpi.disable = "timer" the clock runs twice as fast as it should be. This problem seems to be introduced in the ACPI update around July 2001. I didn't find any solution other than disabling ACPI timecounter. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/var/tmp/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> share/termcap script, 36: Pattern not found script, 36: Ex command failed: pending commands discarded *** Error code 1 Stop in /var/tmp/des/src/share/termcap. *** Error code 1 Stop in /var/tmp/des/src/share. *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Release building broken for -current
Hi all, when bulding release on -current I get (since a couple of days): > rm -rf /R/stage/dists > mkdir -p /R/stage/dists > rolling base/base tarball > mtree: line 0: dumpdates: No such file or directory > *** Error code 1 > > Stop in /usr/src/release. Somehow dumpdates didn't get installed into /R/stage/trees/base/usr/share/examples/etc Later then I got same problems for: /R/stage/trees/base/usr/share/tmac/mm/locale /R/stage/trees/base/usr/share/tmac/mm/se_locale ... and others. All the problems seem to be with files of size 0, so maybe the problem is with mtree. Hopefully this can be get fixed so a new snapshot release with the new gcc can be built. Best regards -- Udo Schweigert, Siemens AG | Voice : +49 89 636 42170 CT IC CERT, Siemens CERT | Fax: +49 89 636 41166 D-81730 Muenchen / Germany | email : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
syscons in rcng ?
Hello, With the latest changes (1.8, 5th of Sep) to /etc/rc.d/syscons, syscons doesn't get initialized on my 5.0-CURRENT. Have I missed some new configuration options? Sincerely, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ste driver broken
Greetings, I recently upgraded one machine to a recent -CURRENT, and the NIC (DLink 550 TX) fails to be properly initialized. The rest of the system is pretty vanilla : Athlon XP, with Via chipset. Here is the relevant part of dmesg: ste0: port 0x9800-0x987f mem 0xe900-0xe97f irq 7 at device 11.0 on pci0 /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from /usr/src/sys/pci/if_ste.c:937 /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from /usr/src/sys/pci/if_ste.c:937 lock order reversal 1st 0xc25b69a4 ste0 (network driver) @ /usr/src/sys/pci/if_ste.c:937 2nd 0xc0318600 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:317 /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from /usr/src/sys/pci/if_ste.c:937 /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from /usr/src/sys/pci/if_ste.c:937 /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from /usr/src/sys/pci/if_ste.c:937 ste0: Ethernet address: 00:50:ba:71:be:ea ste0: MII without any phy! device_probe_and_attach: ste0 attach returned 6 By replacing the current version of /usr/src/sys/pci/if_ste.c by version 1.33 I am able to obtain a correctly working system. This is a part of the new dmesg: ste0: port 0x9800-0x987f mem 0xe900-0xe97f irq 7 at device 11.0 on pci0 /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from /usr/src/sys/pci/if_ste.c:906 /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from /usr/src/sys/pci/if_ste.c:906 lock order reversal 1st 0xc26039a4 ste0 (network driver) @ /usr/src/sys/pci/if_ste.c:906 2nd 0xc0487c00 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:317 /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from /usr/src/sys/pci/if_ste.c:906 /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from /usr/src/sys/pci/if_ste.c:906 /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from /usr/src/sys/pci/if_ste.c:906 ste0: Ethernet address: 00:50:ba:71:be:ea miibus0: on ste0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from /usr/src/sys/pci/if_ste.c:244 The main difference between the working and current revision of if_ste.c is very small and doesn't add anything new. I think it should be removed. -- François Tigeot| AFNIC http://www.nic.fr/ | mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 package build with gcc32 complete (HELP NEEDED!!)
I got some free time on my hands and will try to fix some ports, already fixed sysutils/logmon. On Fri, Sep 06, 2002 at 11:58:17AM -0700, Kris Kennaway wrote: > All ports maintainers/committers: please take a look at > > http://bento.freebsd.org/errorlogs/5-latest/ > > and consider fixing some ports. With the new gcc compiler we now have > over 900 packages that are failing to build (an all-time record, > AFAIK). Many of these are simple to fix and require less than 5 > minutes of your time. Thanks for any help you can provide. > > Kris > -- Eirik Nygaard <[EMAIL PROTECTED]> Http://kverka.org/~eirik/ PGP Key: 83C55EDE msg42740/pgp0.pgp Description: PGP signature
Re: Unable to buildworld (new record, 18")
>> Original Message << On 9/7/02, 11:20:48 PM, Riccardo Torrini <[EMAIL PROTECTED]> wrote regarding Re: Unable to buildworld (new record, 18"): > On 07-Sep-2002 (21:00:28/GMT) Riccardo Torrini wrote: > >> Have you read through UPDATING? > > Yes, more and more ... I added -DNO_WERROR without luck > > I also found two PR speaking about wchar_t (31864 and 40084). > > I'm about to remove contrib/gcc tree and cvsuping again... > No, same error :( Any other ideas? [...] Have you tried making new includes? Ciao, Salvo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libmd bug on -CURRENT
On Sat, 7 Sep 2002, Bruce A. Mah wrote: > If memory serves me right, Bruce Evans wrote: > > libmd is also broken for some cases involving pipes. IIRC, this is > > caused by the bogus st_size checks in the same function. st_size is > > only valid for regular files. > > It's puzzling that the call to lseek(2) doesn't always return an error > in these cases as well (as the manpage seems to imply). Yet, one can do > md5(1) on a pipe: > > tomcat:bmah% cat /etc/motd | md5 > 9caae6eae6f9c2dfea77d6a5fae2e93c > tomcat:bmah% md5 /etc/motd > MD5 (/etc/motd) = 9caae6eae6f9c2dfea77d6a5fae2e93c I don't remember exactly which case(s) are broken. The above works, but cat /dev/motd | md5 /dev/stdin doesn't -- it gives the seek error. I think the open() in mdXFileChunk() gets used for the latter but not when stdin is used directly. This is with /dev/stdin not on devfs or fdescfs. Named pipes seem to work too: mkfifo p; md5 < p & cat /etc/motd >p# same result as md5 /etc/motd > > The loop in the function fails to to terminate if read() returns 0, > > which can probably happen if the file shrinks underneath us. > > Maybe add a check after the read(2), so that if it returns zero, we set > n = 0? It's not clear to me what result should be returned in the case > of trying to compute a checksum on a file that shrinks in the middle of > the computation. Writes that change the file underneath us will make a mess of the result. Hmm ... detecting changes is very easy, at least for regular files - just use fstat() and compare ctimes. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Clock runs too fast
On Sat, Sep 07, 2002 at 11:19:52PM -0400, Craig Rodrigues wrote: > Is there a problem with the ACPI code or with my > hardware (an ASUS P5A-B motherboard from about 3 or 4 years ago). Several people (including me) have reported this problem with this motherboard. Poul had a look at it, but couldn't figure out why the clock was running fast - I'd guess the hardware is busted in some obscure way. (I may have a look at it once I have the machine running -current again. At the moment it is my NAT box, so it is running -stable). David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unable to buildworld (new record, 18")
On 07-Sep-2002 (21:55:22/GMT) Giorgos Keramidas wrote: >> /usr/include/sys/_types.h:71: declaration does not declare anything >> *** Error code 1 > Which revision of /usr/include/sys/_types.h do you have? # ident /usr/include/sys/_types.h /usr/include/sys/_types.h: $FreeBSD: src/sys/sys/_types.h,v 1.7 2002/08/25 19:26:31 mike Exp $ # ident /usr/include/stdlib.h /usr/include/stdlib.h: $FreeBSD: src/include/stdlib.h,v 1.41 2002/09/06 11:23:32 tjr Exp $ > What is at, around, and near line 71 of /usr/include/sys/_types.h ? # cat -n /usr/include/sys/_types.h | grep -C4 "71" 67 * character set plus one extra value (WEOF), and must be at least 16 bits. 68 */ 69 typedef int __ct_rune_t; 70 typedef __ct_rune_t __rune_t; 71 typedef __ct_rune_t __wchar_t; 72 typedef __ct_rune_t __wint_t; 73 74 /* 75 * mbstate_t is an opaque object to keep conversion state during multibyte After some unsuccesfull buildworld I tryed updating includes but got the same error. May be because my -CURRENT is pre-gcc_3.1 ? Can I (Must I?) upgrade to an intermediate version between May and now? Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message