unknown soundcard
My "Terratec 128i PCI" soundcard probes as "unknown" in current: pci0: unknown card (vendor=0x125d, dev=0x1969) at 13.0 irq 17 Here are the labels read from the chip on the soundcard: ESS Solo-1 ES1938S G438 TTUB43833S P4,214,125 System is: FreeBSD werner.test.privat.priv 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue Dec 28 14:46:12 CET 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/SMP-WERNER i386 What can I do to make it work ? Werner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
broken ppp
current's new ppp discards the "#0001"-part from my german telekom account and makes it impossible to connect to my provider. It worked ~ 2 weeks ago with current and works also in 3.4-Stable. Werner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SUBMIT: compat.linux.pathmunge
On Tue, 28 Dec 1999, Doug White wrote: Hello fellow hackers, I've written up a short patch to add a sysctl to control the appending of /compat/linux/ to path requests in Linux mode. We had to get ADSM's Linux client working on FreeBSD so we could do backups of our systems. Luckily it comes statically linked so all was needed was this sysctl and some creative redirections (there's a bug in the termio ioctl() emulation still...) to get it working. Funny... I was in the process of doing almost exactly the same changes. Initially, I've done this fo /tmp and /var only, because some software was creating lock files _and_ IPC keys using (obviously) normal /tmp and /var/tmp, and they ended up having very different values, which somehow confused it... Anyway, the solution I would suggest is to have more granularity instead of all-or-nothing. I'd suggest a linked list of paths, set up by compat.linux.pathmunge.paths, and the other sysctl to turn on the checking. If the *paths sysctl is empty, it's equivalent to your functionality. Comments? :-) Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
Amancio Hasty wrote: I really doubt that I am the only one here that can get XFree86 3.9.xxx -curr ent . Nevertheless if it can help out to fix the default compiler here is the infor mation which you reguested. Command Line executed to generate the output file and with the exception of t he gcc option "-E" it is the exact same command which failed to compile xf86vmod e.c The current official release (ports/lang/egcs) also has this problem. However, ports/lang/gcc-devel (the current snapshot) compiles this file OK. Looking at the changelog, it seems that there has been a *lot* of work on the reload/clobber/etc area. So, if you want to compile the current XFree86, it looks like it'll need the port. The bad news is that the cygnus folks are absolutely determined to not support any dual-format (a.out and elf) stuff for us, this means that you won't be able to build a.out libraries. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: broken ppp
On Wed, 29 Dec 1999, Werner Griessl wrote: current's new ppp discards the "#0001"-part from my german telekom account and makes it impossible to connect to my provider. While we are on the subject, ppp no longer runs an external chat script. This used to work: set login "\"!chat -f /etc/ppp/login -r /var/log/connect.log\"" -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: broken ppp
Bryan Liesner wrote: On Wed, 29 Dec 1999, Werner Griessl wrote: current's new ppp discards the "#0001"-part from my german telekom account and makes it impossible to connect to my provider. While we are on the subject, ppp no longer runs an external chat script. This used to work: set login "\"!chat -f /etc/ppp/login -r /var/log/connect.log\"" Heh, I'll join in too.. I've been having ppp abort on me a few times. Today it died with "Error: Request for mbuf size 2329 denied" after I attempted to do a 'show links' on an already established pppctl connection: Dec 29 10:38:27 haywire ppp[882]: tun0: Phase: Unknown protocol 0x80fb (compression on single link in multilink group control) Dec 29 10:38:27 haywire ppp[882]: tun0: LCP: 1: SendProtocolRej(15) state = Opened Dec 29 10:39:24 haywire ppp[882]: tun0: Phase: 1: HDLC errors - FCS: 0, ADDR: 0, COMD: 0, PROTO: 1 (pppctl connects here) Dec 29 10:55:10 haywire ppp[882]: tun0: Phase: Connected to client from 202.12.86.2:41555 Dec 29 10:55:12 haywire ppp[882]: tun0: Command: 202.12.86.2:41555: passwd (and here I type 'show links') Dec 29 10:55:55 haywire ppp[882]: tun0: Phase: 1: HDLC errors - FCS: 2, ADDR: 0, COMD: 0, PROTO: 0 Dec 29 10:55:55 haywire ppp[882]: tun0: Warning: lqr_Input: magic 0x428bf108 is wrong, expecting 0x14ae603f Dec 29 10:55:56 haywire ppp[882]: tun0: Error: Request for mbuf size 2329 denied Dec 29 10:55:56 haywire ppp[882]: tun0: Phase: 202.12.86.2:41555: Client connection dropped. Dec 29 10:55:56 haywire ppp[882]: tun0: Phase: PPP Terminated (71). Dec 29 10:55:56 haywire ppp[882]: tun0: IPCP: mp: LayerDown: 202.12.86.2 Dec 29 10:55:56 haywire ppp[882]: tun0: IPCP: mp: SendTerminateReq(15) state = Opened Dec 29 10:55:56 haywire ppp[882]: tun0: IPCP: mp: State change Opened -- Closing Dec 29 10:55:56 haywire ppp[882]: tun0: CCP: mp: State change Stopped -- Closed Dec 29 10:55:56 haywire ppp[882]: tun0: CCP: mp: State change Closed -- Initial Dec 29 10:55:56 haywire ppp[882]: tun0: Warning: Del route failed: 0.0.0.0: Non-existent Dec 29 10:55:56 haywire ppp[882]: tun0: Error: Oops, destroying a datalink in state open (he's dead jim!) Dec 29 10:56:19 haywire ppp[882]: tun0: Phase: 1: Connect time: 1112 secs: 533725 octets in, 386209 octets out Dec 29 10:56:19 haywire ppp[882]: tun0: Phase: total 827 bytes/sec, peak 4972 bytes/sec on Wed Dec 29 10:56:19 1999 -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPFW
On Mon, 27 Dec 1999, Emre wrote: Not really. All my other boxes (NetBSD/OpenBSD) run -current so I'm used to be on the "bleeding edge" I figured it would be enabled by default, since FreeBSD promises to be _the_ Server O/S. Please see http://www.freebsd.org/handbook/cutting-edge.html#CURRENT This question was really freebsd-questions material and not the kind of thing which is appropriate for freebsd-current. If you're running FreeBSD-CURRENT you're expected to be familiar with the technicalities of FreeBSD (i.e. not just NetBSD/OpenBSD), which I'm not sure that you are, yet. It's not (just) about the danger to your own system, it's the hand-holding load on the developers when a FreeBSD neophyte thinks he's ready to run the developer's version :-( Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
question about egcs
Will egcs affect the size of the kernel or any other compiledcode? I read that the exception code can add a lot to the object size. -= jm =- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: question about egcs
On Wed, 29 Dec 1999 14:47:12 GMT, Jonathon McKitrick wrote: Will egcs affect the size of the kernel or any other compiledcode? Yes. Try it out for yourself and have a look, or hunt the -current mailing list archives. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
On Sun, 26 Dec 1999, Randy Bush wrote: mkdep -f .depend -a -I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/include -I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../include -I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/krb -I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kdb -I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm -I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/roken -I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb -I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm -I/usr/obj/usr/src/kerberosIV/lib/libkadm -I/usr/src/kerberosIV/lib/libkadm/../../include -DHAVE_CONFIG_H -I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -I/usr/obj/usr/src/i386/usr/include /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_cli_wrap.c /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_stream.c /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_supp.c /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.c /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/check_password.c In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:79, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_cli_wrap.c:30: /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:17: invalid macro name In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:82, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_cli_wrap.c:30: /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:13: warning: `ERROR_TABLE_BASE_' redefined /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:13: warning: this is the location of the previous definition /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:17: invalid macro name [SNIP] I saw these too when I was building with a fresh tree checked out from internat. Mark? :) Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
snapshot stability
Some time ago, Greg wrote: "USers looking for stability should be damn careful which version of the -current snapshot they run." As of right now, which would that be? The august CD snapshot release or the one available on the cvs servers right now? -= jm =- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: snapshot stability
On Wed, 29 Dec 1999 15:31:38 GMT, Jonathon McKitrick wrote: As of right now, which would that be? The august CD snapshot release or the one available on the cvs servers right now? If I were you, I'd hold out for 4.0-RELEASE, since it's just around the corner (January some time). Otherwise, just inhale and prepare to bleed. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
On Tue, 28 Dec 1999, David O'Brien wrote:
Perhaps a later snapshot of gcc will work .
GCC 2.95.2 is a *RELEASED* version. We don't use snapshots as the base
compiler. What every the problem is 4.0 will live with it unless someone
narrows down the problem more.
The latest Polygraph (ver 2.2.8) proxy-cache benchmarking source
(Available at http://www.ircache.net/Polygraph/) does not
compile on my very recent 4.0 system. (rebuilding world now...)
I get this error, after dl'ing polygraph-2.2.8-src.tar.gz, running
'configure', then running 'make':
...
c++ -g -O3 -Wall -Wwrite-strings -Woverloaded-virtual -Iinclude
-Ixstd/include -Ipgl/include -Ixparser/include -I.. -DHAVE_CONFIG_H -c
Connection.cc
In file included from include/PortMgr.h:29,
from Connection.cc:33:
include/LevelStat.h:55: invalid type `const char[1]' for default argument
to `const String '
*** Error code 1
Stop in /usr/home/andyf/src/polygraph/src.
*** Error code 1
Stop in /usr/home/andyf/src/polygraph.
The "offending" code looks like this:
ostream print(ostream os, const String pfx = "") const;
When I did a 'touch Connection.o ; make' it compiled another source file
that included PortMgr.h / LevelStat.h just fine, but bombed out elsewhere!
--
-- David([EMAIL PROTECTED])
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: snapshot stability
I read that the VM system has been revamped and egcs is the default compiler. Will either of these affect the average user besides larger binaries? Also, i'm wondering if maybe i should just wait until the 4.1 release for everything to settle down... -= jm =- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: snapshot stability
On Wed, 29 Dec 1999, Jonathon McKitrick wrote: I read that the VM system has been revamped and egcs is the default compiler. Will either of these affect the average user besides larger binaries? Actually, egcs WAS the default compiler. It is now (output of gcc -v): $ gcc -v Using builtin specs. gcc version 2.95.2 19991024 (release) - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: snapshot stability
In message [EMAIL PROTECTED] Sheldon Hearn writes: : If I were you, I'd hold out for 4.0-RELEASE, since it's just around the : corner (January some time). Otherwise, just inhale and prepare to : bleed. :-) I think that the January some time date may be optimistic given that we're not in feature freeze yet. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
auth 3bd2ca54 subscribe freebsd-current [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
auth 52898cdd subscribe freebsd-stable [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SUBMIT: compat.linux.pathmunge
Doug White wrote: Please let me know if you have comments/suggestions/etc. If no one whines too badly I'll commit these later this week and finally break my declaration against making kernel changes. :) I'm not sure I like this. Please hold off until I've got some time to think this over. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
XFree86 3.9.xxx was cvsup on December 24th I am sorry but this is sufficient information to reproduce the problem. Not if you actually want the problem solved. There's this thing called "making it easy on the people you're demanding things of" in order that they might have some chance of actually doing it. Insisting that someone cvsup the entire X source tree, as you've clearly *already* done, hardly falls into the category of attempting to save the gcc maintainers work in attempting to track down the problem you're complaining about. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
On Wed, 29 Dec 1999, Jordan K. Hubbard wrote: XFree86 3.9.xxx was cvsup on December 24th I am sorry but this is sufficient information to reproduce the problem. [snip] Insisting that someone cvsup the entire X source tree, as you've clearly *already* done, hardly falls into the category of attempting to save the gcc maintainers work in attempting to track down the problem you're complaining about. Hmmm... are "regular people" even allowed access to the XFree86 cvs server? I thought that was just reserved for XFree86 developers? Don't tell me we have to become XFree86 developers just to solve a simple gcc problem. :) BTW, I hope they release 3.9.17 soon - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
Sending out an attachment of that size to a public mailing list was hardly necessary, and the increasing stridency of your posts leading up to this only serve to indicate that you may be heading in the truly wrong direction with all this and seriously need to rethink your strategy before you do something that has people howling for your blood. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: snapshot stability
On Wed, 29 Dec 1999 15:31:38 GMT, Jonathon McKitrick wrote: As of right now, which would that be? The august CD snapshot release or the one available on the cvs servers right now? If I were you, I'd hold out for 4.0-RELEASE, since it's just around the corner (January some time). Otherwise, just inhale and prepare to bleed. :-) Despite the risk of bleeding, I have to say that I've installed several snaps (from the freebsd snapshot server) with excellent results. Now that spasm over the block device removal has gone away, things have been pretty darn stable for me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
I ain't done nuttin'!! I don't see the errors below, I see libroken breaking because libgcc.a can't be found. *grumble* M On Sun, 26 Dec 1999, Randy Bush wrote: mkdep -f .depend -a-I/usr/src/kerberosIV/lib/libkadm/../../../crypto/ke rberosIV/include -I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../include -I/usr /src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/krb -I/usr/src/kerbe rosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kdb -I/usr/src/kerberosIV/lib/ libkadm/../../../crypto/kerberosIV/lib/kadm -I/usr/src/kerberosIV/lib/libkadm/. ./../../crypto/kerberosIV/lib/roken -I/usr/obj/usr/src/kerberosIV/lib/libkadm/. ./../lib/libkrb -I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm -I/ usr/obj/usr/src/kerberosIV/lib/libkadm -I/usr/src/kerberosIV/lib/libkadm/../../ include -DHAVE_CONFIG_H -I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -I/usr/obj/usr/src/i386/usr/incl ude /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_c li_wrap.c /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/k adm_stream.c /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kad m/kadm_supp.c /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_er r.c /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/check_p assword.c In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerbe rosIV/lib/kadm/kadm_locl.h:79, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerbe rosIV/lib/kadm/kadm_cli_wrap.c:30: /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:17: inva lid macro name In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerbe rosIV/lib/kadm/kadm_locl.h:82, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerbe rosIV/lib/kadm/kadm_cli_wrap.c:30: /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:13: wa rning: `ERROR_TABLE_BASE_' redefined /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:13: warn ing: this is the location of the previous definition /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:17: in valid macro name [SNIP] I saw these too when I was building with a fresh tree checked out from internat. Mark? :) Kris -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
: : FreeBSD -current was last cvsup on my system on Dec 23 18:59. : : XFree86 3.9.xxx was cvsup on December 24th I am sorry but this is : sufficient information to reproduce the problem. : :No, it is not, because we can't *get* XFree86 3.9.xxx -current, so we :cannot reproduce it, can we? : :You either need to give us enough to build that part, or provide a :preprocessed file so we can feed the backends directly, or fix it yourself. Sure you can well, you can get close anyway. ftp ftp.xfree86.org cd snapshots get 3.9.16.tar.gz I've been keeping up to date myself hoping that the I128 driver (for the SGI flatscreen) would support the I^2 protocol the SGI uses to control backlight brightness, there being no external knob on the monitor to fiddle with. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
Sending out an attachment of that size to a public mailing list was
hardly necessary, and the increasing stridency of your posts leading
up to this only serve to indicate that you may be heading in the truly
wrong direction with all this and seriously need to rethink your
strategy before you do something that has people howling for your
blood.
- Jordan
Okay folks,
This is the scoop.
For the benefit of those which don't have access to the latest XFree86 release you can
download the file from ftp://rah.star-gate.com/pub/bug.c
uname -a
FreeBSD x.star-gate.com 4.0-CURRENT FreeBSD 4.0-CURRENT #2: Mon Dec 27 13:55:25 PST
1999 [EMAIL PROTECTED]:/usr/src/sys/compile/MUADIB i386
gcc -v
Using builtin specs.
gcc version 2.95.2 19991024 (release)
gcc -c -O2 bug.c
xf86vmode.c: In function `ProcXF86VidModeGetMonitor':
xf86vmode.c:1320: Unable to generate reloads for:
(insn 300 298 302 (parallel[
(set (reg:SI 0 %eax)
(fix:SI (fix:SF (subreg:SF (reg:SI 0 %eax) 0
(clobber (mem:HI (plus:SI (reg:SI 6 %ebp)
(const_int -34 [0xffde])) 0))
(clobber (mem:HI (plus:SI (reg:SI 6 %ebp)
(const_int -36 [0xffdc])) 0))
(clobber (mem:SI (plus:SI (reg:SI 6 %ebp)
(const_int -40 [0xffd8])) 0))
(clobber (scratch:HI))
] ) 145 {fix_truncsfsi2+1} (insn_list 293 (nil))
(expr_list:REG_DEAD (reg:SI 0 %eax)
(expr_list:REG_UNUSED (scratch:HI)
(nil
--
Without -O or -O2 the program compiles okay.
gcc -c bug.c
According to Peter, the ports/lang/gcc-devel (the current snapshot) appears to
compile this program fine -- that is the compiler bug has been fixed.
So there appears to be two solutions to get around this problem:
1. compile without -O
or
2. installed the latest snapshot of gcc.
Take Care Guys
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
-current runs really fine now (very performant)
Last days (week?) I silently complaint about slow/hanging xbuffy process and even mutt reading large inbox (20MB) was very very slow. Now it is again blindingly fast under -current SMP. Don't know, what change did it, but thanks to you all ! Andreas /// -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: broken ppp
Bryan Liesner wrote: On Wed, 29 Dec 1999, Werner Griessl wrote: current's new ppp discards the "#0001"-part from my german telekom account and makes it impossible to connect to my provider. While we are on the subject, ppp no longer runs an external chat script. This used to work: set login "\"!chat -f /etc/ppp/login -r /var/log/connect.log\"" Urk ! The version you have is now *FIXED*. The above line should read: set login "\"!chat \\-f /etc/ppp/login \\-r /var/log/connect.log\"" as the - sign should only be escaped once for the chat parsing and once for the argument parsing. I'll fix the docs and update README.changes. Heh, I'll join in too.. I've been having ppp abort on me a few times. Today it died with "Error: Request for mbuf size 2329 denied" after I attempted to do a 'show links' on an already established pppctl connection: Dec 29 10:38:27 haywire ppp[882]: tun0: Phase: Unknown protocol 0x80fb (compression on single link in multilink group control) Dec 29 10:38:27 haywire ppp[882]: tun0: LCP: 1: SendProtocolRej(15) state = Opened Dec 29 10:39:24 haywire ppp[882]: tun0: Phase: 1: HDLC errors - FCS: 0, ADDR: 0, COMD: 0, PROTO: 1 (pppctl connects here) Dec 29 10:55:10 haywire ppp[882]: tun0: Phase: Connected to client from 202.12.86.2:41555 Dec 29 10:55:12 haywire ppp[882]: tun0: Command: 202.12.86.2:41555: passwd (and here I type 'show links') Dec 29 10:55:55 haywire ppp[882]: tun0: Phase: 1: HDLC errors - FCS: 2, ADDR: 0, COMD: 0, PROTO: 0 Dec 29 10:55:55 haywire ppp[882]: tun0: Warning: lqr_Input: magic 0x428bf108 is wrong, expecting 0x14ae603f Dec 29 10:55:56 haywire ppp[882]: tun0: Error: Request for mbuf size 2329 denied I've no idea what tried to allocate this. It should be impossible to allocate an mbuf this size because it's illegal for either side to send a packet this size Even the CCP layer (which creates packets of a pretty much random size) allocates mbufs in smaller chunks and chains them, throwing the results away if they exceed the original packet size. Prior to my recent (user-)mbuf changes, this may have resulted in corruption later on (I think). Is there any chance of running under gdb and catching a stack trace when ppp calls AbortProgram() from m_get() ? Specifically, I'm interested in what's calling m_get() and why it's calling it with such a large value. Dec 29 10:55:56 haywire ppp[882]: tun0: Phase: 202.12.86.2:41555: Client connection dropped. Dec 29 10:55:56 haywire ppp[882]: tun0: Phase: PPP Terminated (71). Hmm, perhaps this message should be emitted at the end of AbortProgram(). It looks silly here - before all the complaints about shutting everything down in a hurry. Dec 29 10:55:56 haywire ppp[882]: tun0: IPCP: mp: LayerDown: 202.12.86.2 Dec 29 10:55:56 haywire ppp[882]: tun0: IPCP: mp: SendTerminateReq(15) state = Opened Dec 29 10:55:56 haywire ppp[882]: tun0: IPCP: mp: State change Opened -- Closing Dec 29 10:55:56 haywire ppp[882]: tun0: CCP: mp: State change Stopped -- Closed Dec 29 10:55:56 haywire ppp[882]: tun0: CCP: mp: State change Closed -- Initial Dec 29 10:55:56 haywire ppp[882]: tun0: Warning: Del route failed: 0.0.0.0: Non-existent Dec 29 10:55:56 haywire ppp[882]: tun0: Error: Oops, destroying a datalink in state open (he's dead jim!) Dec 29 10:56:19 haywire ppp[882]: tun0: Phase: 1: Connect time: 1112 secs: 533725 octets in, 386209 octets out Dec 29 10:56:19 haywire ppp[882]: tun0: Phase: total 827 bytes/sec, peak 4972 bytes/sec on Wed Dec 29 10:56:19 1999 -Bryan [.] Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
gcc compiler problem part deux
Forgot to post about this new feature of /usr/libexec/cpp :
1. Test file
foo.c
main() {
#ifdef __FreeBSD__
printf("hello\n");
#endif
}
1. old freebsd-current
2. gcc -v
Using builtin specs.
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
/usr/libexec/cpp foo.c
# 1 "foo.c"
main() {
printf("hello\n");
}
/usr/libexec/cpp has __FreeBSD_ defined --- and this is not
problem.
2. Now a very recent FreeBSD -current
gcc -v
Using builtin specs.
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
/usr/libexec/cpp foo.c
# 1 "foo.c"
main() {
}
Voila! the "printf " disappeared.
This behavior breaks the XFree86 3.9.17 build because the procedure
to build imake depends on /usr/libexec/cpp defining __FreeBSD__
I patched locally the imake build so just for FreeBSD it adds a
-D__FreeBSD__
I presumed that the latest /usr/libexec/cpp behavior is also going to
break other package. Again for me is not a problem because
after a few hours I managed to circumvent the new /usr/libexec/cpp
feature.
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
make world failure
[cvsupped today :-)] === usr.sbin/ifmcstat cc -O -pipe -DINET6 -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/i fmcstat/ifmcstat.c gzip -cn /usr/src/usr.sbin/ifmcstat/ifmcstat.8 ifmcstat.8.gz /usr/src/usr.sbin/ifmcstat/ifmcstat.c: In function `main': /usr/src/usr.sbin/ifmcstat/ifmcstat.c:109: storage size of `arpcom' isn't known Hope this helps someone :-) gjvc -- [gjvc] 4.4BSD 4.ever! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compiler problem part deux
This was discussed weeks ago, and the new behaviour is correct. You
should be using 'cc -E' instead.
Forgot to post about this new feature of /usr/libexec/cpp :
1. Test file
foo.c
main() {
#ifdef __FreeBSD__
printf("hello\n");
#endif
}
1. old freebsd-current
2. gcc -v
Using builtin specs.
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
/usr/libexec/cpp foo.c
# 1 "foo.c"
main() {
printf("hello\n");
}
/usr/libexec/cpp has __FreeBSD_ defined --- and this is not
problem.
2. Now a very recent FreeBSD -current
gcc -v
Using builtin specs.
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
/usr/libexec/cpp foo.c
# 1 "foo.c"
main() {
}
Voila! the "printf " disappeared.
This behavior breaks the XFree86 3.9.17 build because the procedure
to build imake depends on /usr/libexec/cpp defining __FreeBSD__
I patched locally the imake build so just for FreeBSD it adds a
-D__FreeBSD__
I presumed that the latest /usr/libexec/cpp behavior is also going to
break other package. Again for me is not a problem because
after a few hours I managed to circumvent the new /usr/libexec/cpp
feature.
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
On Wed, 29 Dec 1999, Amancio Hasty wrote: ! !Without -O or -O2 the program compiles okay. ! !gcc -c bug.c ! Ouch! This looks an awful lot like the last report with `GCC' and `problem' in the subject. As Matt just mentionned one or two posts ago, and as I observed in the last thread, have you tried making some of the variables `volatile?' Assuming of course that the code does compile well without the optimization flags, one would assume that the "problem" occurs because of caching of certain variable values in registers (not that this should be a problem, mind you; one would assume that the optimization isn't performed too well). Due to lack of time, and generally speaking, lack of experience with GCC, I haven't taken a detailed shot at debugging this. Bosko. -- Bosko Milekic Email: [EMAIL PROTECTED] WWW:http://pages.infinit.net/bmilekic/ -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compiler problem part deux
There are packages such as XFree86 which called directly the installed
cpp. Those packages which rely on the old behavior of /usr/libexec/cpp
for instance defining __FreeBSD__ are now broken .
This was discussed weeks ago, and the new behaviour is correct. You
should be using 'cc -E' instead.
Forgot to post about this new feature of /usr/libexec/cpp :
1. Test file
foo.c
main() {
#ifdef __FreeBSD__
printf("hello\n");
#endif
}
1. old freebsd-current
2. gcc -v
Using builtin specs.
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
/usr/libexec/cpp foo.c
# 1 "foo.c"
main() {
printf("hello\n");
}
/usr/libexec/cpp has __FreeBSD_ defined --- and this is not
problem.
2. Now a very recent FreeBSD -current
gcc -v
Using builtin specs.
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
/usr/libexec/cpp foo.c
# 1 "foo.c"
main() {
}
Voila! the "printf " disappeared.
This behavior breaks the XFree86 3.9.17 build because the procedure
to build imake depends on /usr/libexec/cpp defining __FreeBSD__
I patched locally the imake build so just for FreeBSD it adds a
-D__FreeBSD__
I presumed that the latest /usr/libexec/cpp behavior is also going to
break other package. Again for me is not a problem because
after a few hours I managed to circumvent the new /usr/libexec/cpp
feature.
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc compiler problem part deux
There are packages such as XFree86 which called directly the installed cpp. Those packages which rely on the old behavior of /usr/libexec/cpp for instance defining __FreeBSD__ are now broken . XFree86 is trivial to patch, since it already supports this behaviour (see our port), and other applications that expect cpp to define platform-specific symbols have always been broken. This was discussed weeks ago, and the new behaviour is correct. You should be using 'cc -E' instead. Forgot to post about this new feature of /usr/libexec/cpp : -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
Hi, We just have a buggy version of gcc and it appears that the register allocator is the main problematic area. This is not really a problem for me because what I first try out is a newer version of gcc if I can not get around the compile problem. At any rate remember that at least my reported compiler bug appears to be fixed in the latest gcc-devel port. On Wed, 29 Dec 1999, Amancio Hasty wrote: ! !Without -O or -O2 the program compiles okay. ! !gcc -c bug.c ! Ouch! This looks an awful lot like the last report with `GCC' and `problem' in the subject. As Matt just mentionned one or two posts ago, and as I observed in the last thread, have you tried making some of the variables `volatile?' Assuming of course that the code does compile well without the optimization flags, one would assume that the "problem" occurs because of caching of certain variable values in registers (not that this should be a problem, mind you; one would assume that the optimization isn't performed too well). Due to lack of time, and generally speaking, lack of experience with GCC, I haven't taken a detailed shot at debugging this. Bosko. -- Bosko Milekic Email: [EMAIL PROTECTED] WWW:http://pages.infinit.net/bmilekic/ -- -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compiler problem part deux
It is more of a question of whether the packages for FreeBSD expect /usr/libexec/cpp to define __FreeBSD__ and in my case XFree86. Once I managed to find out what was wrong it was indeed easy for me to fix. If the "other" applications managed to compile correctly on FreeBSD because of /usr/libexec/cpp then I don't consider them to be broken. There are packages such as XFree86 which called directly the installed cpp. Those packages which rely on the old behavior of /usr/libexec/cpp for instance defining __FreeBSD__ are now broken . XFree86 is trivial to patch, since it already supports this behaviour (see our port), and other applications that expect cpp to define platform-specific symbols have always been broken. This was discussed weeks ago, and the new behaviour is correct. You should be using 'cc -E' instead. Forgot to post about this new feature of /usr/libexec/cpp : -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compiler problem part deux
On Wed, 29 Dec 1999, Amancio Hasty wrote: There are packages such as XFree86 which called directly the installed cpp. Those packages which rely on the old behavior of /usr/libexec/cpp for instance defining __FreeBSD__ are now broken . ... and they will be fixed through bug reports. We now know what was causing your mishaps with XFree86, this has already been corrected in the port, but you are using the straight source. Perhaps our XFree86 liason can correct this behavior before XFree86 makes a release off of this branch. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
World fail
i=== libroken cc -O -pipe -I/usr/src/kerberosIV/lib/libroken/../../../crypto/kerberosIV/include -I/usr/obj/usr/src/kerberosIV/lib/libroken/../../include -I/usr/src/kerberosIV/lib/libroken/../../../crypto/kerberosIV/lib/roken -I/usr/obj/usr/src/kerberosIV/lib/libroken -I/usr/src/kerberosIV/lib/libroken/../../include -Wall -DHAVE_CONFIG_H -I/usr/obj/usr/src/kerberosIV/lib/libroken/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -I/usr/obj/usr/src/i386/usr/include -o make-print-version /usr/src/kerberosIV/lib/libroken/../../../crypto/kerberosIV/lib/roken/make-print-version.c /usr/obj/usr/src/i386/usr/libexec/elf/ld: cannot open libgcc.a: No such file or directory *** Error code 1 Stop in /usr/src/kerberosIV/lib/libroken. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
USB broken?
I'm running -current that's about a week old. I configed my kernel for USB support. After turning on the USB interface in BIOS kernel panics after it probes uchi0. Below is the panic screen, I don't have much else to go on. --- uhci0: Intel 82371SB USB Host Controller rev 0x01 int d irq 10 on pci0.7.2 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode mp_lock = 0002; cpuid = 0; lapic.id = fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0216a34 stack pointer = 0x10:0xc0313e18 frame pointer = 0x10:0xc0313e38 code segment= base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPC = 0 current progess = 0 () interrupt mask = net tty bio cam - SMP: XXX trap number = 12 panic: page fault mp_lock = 0002; cpuid = 0; lapic.id = --- -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB broken?
Of all the gin joints in all the towns in all the world, Eric D. Futch had to walk into mine and say: I'm running -current that's about a week old. Erm... are you sure? I'm having trouble believing you. I configed my kernel for USB support. After turning on the USB interface in BIOS kernel panics after it probes uchi0. Below is the panic screen, I don't have much else to go on. --- uhci0: Intel 82371SB USB Host Controller rev 0x01 int d irq 10 on pci0.7.2 kernel trap 12 with interrupts disabled See this kernel probe output here? This is not from a 4.0-CURRENT kernel from a week ago. This is what the probe output from a recent -current system should look like: uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 11 at device 7.2 on pci0 Notice the difference? It's been like that for a *long* time now. Therefore I can only conclude that either you're not actually running -current, or else you thought it would be okay to substitute in a really stale entry from a system log file from a 3.x system. Either way, you need to re-evaluate the situation and provide more info. Now rather than being vague, go back and show us what uname -a says on this allegedly -current system and show it to us. Show us the *entire* dmesg output too, while you're at it. Furthermore, you should be able to test USB support without recompiling the kernel. All you need to do is kldload usb. That will load the usb.ko kernel module, which should find the UHCI controller. From the panic message you showed here, you're using SMP. Have you tested it with a UP kernel? (Yes, it's supposed to work either way, but it would be nice if you would just test it to rule out some sort of SMP-related condition.) What you should do is this: - Compile a kernel with options DDB, but *WITHOUT* USB support. - Boot this kernel. - Type kldload usb - See if the system crashes. - If it does, it will drop into the debugger. - Type 'trace' - Report what it says. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Newpcm is broken again for mpg123 (ESS 1868 isa sound card)
Seigo Tanimura wrote: On Mon, 27 Dec 1999 16:08:01 +0900, Seigo Tanimura [EMAIL PROTECTED] said: Seigo Another fix was made on feeding and sucking pcm data. Now chn_wrfeed() Seigo and the other functions do not attempt excessive feeding during DMA Seigo transfer to eat up the whole processor. The patch is at: Ouch, the patch broke Rollemup, so I fixed just now. The URI is the same. Seigo http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991227.diff.gz I just recently did another cvsup, and now newpcm is broken again. When I try to play a clip with mpg123, I hear a very short burst of the beginning of the clip repeated indefinitely, like so: "ba ba ba ba ba ba ba ba ba ba ba ba ba ba". I have the ESS 1868, of course. Well, I (wisely) saved my old kernel as /kernel.good and just booted into that. Could you also say what was fixed if you get around to it? I'd to learn a little more about the sound driver. Thanks for your help. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB broken?
Oh hehe damn did it again. Keep getting my lists mixed up. This machine is running 3.4-stable and I should have probably posted this to -stable. Sorry about that... but I really do have 4.0-current running on another machine.. so I'm not totally crazy :) -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" On Wed, 29 Dec 1999, Bill Paul wrote: Of all the gin joints in all the towns in all the world, Eric D. Futch had to walk into mine and say: I'm running -current that's about a week old. Erm... are you sure? I'm having trouble believing you. I configed my kernel for USB support. After turning on the USB interface in BIOS kernel panics after it probes uchi0. Below is the panic screen, I don't have much else to go on. --- uhci0: Intel 82371SB USB Host Controller rev 0x01 int d irq 10 on pci0.7.2 kernel trap 12 with interrupts disabled See this kernel probe output here? This is not from a 4.0-CURRENT kernel from a week ago. This is what the probe output from a recent -current system should look like: uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 11 at device 7.2 on pci0 Notice the difference? It's been like that for a *long* time now. Therefore I can only conclude that either you're not actually running -current, or else you thought it would be okay to substitute in a really stale entry from a system log file from a 3.x system. Either way, you need to re-evaluate the situation and provide more info. Now rather than being vague, go back and show us what uname -a says on this allegedly -current system and show it to us. Show us the *entire* dmesg output too, while you're at it. Furthermore, you should be able to test USB support without recompiling the kernel. All you need to do is kldload usb. That will load the usb.ko kernel module, which should find the UHCI controller. From the panic message you showed here, you're using SMP. Have you tested it with a UP kernel? (Yes, it's supposed to work either way, but it would be nice if you would just test it to rule out some sort of SMP-related condition.) What you should do is this: - Compile a kernel with options DDB, but *WITHOUT* USB support. - Boot this kernel. - Type kldload usb - See if the system crashes. - If it does, it will drop into the debugger. - Type 'trace' - Report what it says. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
TAP driver for current
Hello All, I've written a small Ethernet TAP driver for FreeBSD-current. It is useful for Ethernet tunneling. I'm using it with VTUN (http://vtun.netpedia.net). The driver sources and description can be found at: http://home.earthlink.net/~evmax/tap-fbsd-current.tar.gz (~8K) It would be realy nice, if some of the commiters review the code and may be add it to the source tree. Thanks, and have a great New Year! emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compiler problem part deux
Forgot to post about this new feature of /usr/libexec/cpp : NO ONE should have ever have been using /usr/libexec/cpp directly. I have no idea where this usage came from. /usr/bin/cpp should have been used. 2. Now a very recent FreeBSD -current gcc -v Using builtin specs. gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) Yes this is very well known, and has been discussed on both Ports and Current several times. A new /usr/bin/ccp is in the works that is a real binary and not the shell script we have today. *IF* world had been buildable today, we would probably have a new /usr/bin/cpp that does everything you want it to. This behavior breaks the XFree86 3.9.17 build because the procedure to build imake depends on /usr/libexec/cpp defining __FreeBSD__ So use ``cc -E'' instead. Simple. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
On Thu, Dec 30, 1999 at 02:40:46AM +1100, Andy Farkas wrote: In file included from include/PortMgr.h:29, from Connection.cc:33: include/LevelStat.h:55: invalid type `const char[1]' for default argument to `const String ' ..snip.. The "offending" code looks like this: ostream print(ostream os, const String pfx = "") const; What is the prototype for this function? Hint take a look. You have bad (ie, now invalid by stricter compilers) C++ code. When I did a 'touch Connection.o ; make' it compiled another source file that included PortMgr.h / LevelStat.h just fine, but bombed out elsewhere! I can't even fathom what you expected to accomplish by this. Are you a programmer? -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compiler problem part deux
The usage came about oh about 8 years ago with the very first port of X to 386bsd by yours truly 8) Don't forget I did fix the problem on my X build and I am running the latest XFree86 3.9.xx on my other box. Take Care Forgot to post about this new feature of /usr/libexec/cpp : NO ONE should have ever have been using /usr/libexec/cpp directly. I have no idea where this usage came from. /usr/bin/cpp should have been used. 2. Now a very recent FreeBSD -current gcc -v Using builtin specs. gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) Yes this is very well known, and has been discussed on both Ports and Current several times. A new /usr/bin/ccp is in the works that is a real binary and not the shell script we have today. *IF* world had been buildable today, we would probably have a new /usr/bin/cpp that does everything you want it to. This behavior breaks the XFree86 3.9.17 build because the procedure to build imake depends on /usr/libexec/cpp defining __FreeBSD__ So use ``cc -E'' instead. Simple. -- -- David([EMAIL PROTECTED]) -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
On Wed, Dec 29, 1999 at 11:37:18AM -0800, Amancio Hasty wrote: This is the scoop. ..snip.. gcc -v Using builtin specs. gcc version 2.95.2 19991024 (release) ..snip.. Without -O or -O2 the program compiles okay. What other platforms w/gcc 2.95 have you tried to build this X11 version on? What other non-Linux platforms w/gcc 2.95 have you tried to build this X11 version on? Do you have a problem if you download the official GCC 2.95.2 release and build it the old GNU'fashion way? Does a purely stock GCC 2.95 bomb on this?? If so, it is a GCC problem and the issue should be raised with Cygnus. So there appears to be two solutions to get around this problem: ..snip.. 3. Raise this issue with Cygnus. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
3. Raise this issue with Cygnus. Not really Cygnus is the wrong organization to raise this issue . As someone else pointed out the gcc-devel port does not exhibit the bug which I posted. -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB broken?
I'm running 3.4-stable with source cvsup'd about a week ago. I configed my kernel for USB support. After turning on the USB interface in BIOS kernel panics after it probes uchi0. Below is the panic message plus trace. % uname -a FreeBSD quake.nyct.net 3.4-STABLE FreeBSD 3.4-STABLE #3: Wed Dec 29 21:17:59 EST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/QUAKE i386 --- uhci0: Intel 82371SB USB Host Controller rev 0x01 int d irq 10 on pci0.7.2 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode mp_lock = 0002; cpuid = 0; lapic.id = fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0216a74 stack pointer = 0x10:0xc0313e18 frame pointer = 0x10:0xc0313e38 code segment= base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPC = 0 current progess = 0 () interrupt mask = net tty bio cam - SMP: XXX kernel: type 12 trap, code=0 Stopped at INTREN+0x2c:movl%ecx,0(%edx) db trace INTREN(a,c01fd294,c0da1000,c028d14c,0) at INTREN+0x2c add_intrdesc(c0d93e20,400,c028a2f8,c0da1000,a) at add_intrdesc+0x29 intr_connect(c0d93e20,,a,c01fd294,c0da1000,c028d14c,0) at intr_connect+0x2e pci_map_int_right(c0751608,c01fd294,c0da1000,c028d14c,0) at pci_map_int_right+0x31 pci_map_int(c0751608,c01fd294,c0da1000,c028d14c,c0751608,20) at pci_map_int+0x16 uhci_pci_attach(c0751608,0) at uhci_pci_attach+0x75 pci_drvattach(c0751600,c0751600,0,7,c0322f68) at pci_drvattach+0x5f pci_probebus(0,c02637b2,0) at pci_probebus+0x53 pci_probe(0,c0322f98,c0214d70,c0322fac,c014a1f7) at pci_probe+0x39 pci_configure(c0322fac,c014a1f7,0,320c00,326000) at pci_configure+0xa configure(0) at configure+0x20 main(c0322fb8,0,8000,c0161189,c0403000) at main+0x83 begin() at begin+0x55 --- -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB broken?
Grr damn... please ignore.. I'm sorry.. not gonna post anything else. -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" On Wed, 29 Dec 1999, Eric D. Futch wrote: I'm running 3.4-stable with source cvsup'd about a week ago. I configed my kernel for USB support. After turning on the USB interface in BIOS kernel panics after it probes uchi0. Below is the panic message plus trace. % uname -a FreeBSD quake.nyct.net 3.4-STABLE FreeBSD 3.4-STABLE #3: Wed Dec 29 21:17:59 EST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/QUAKE i386 --- uhci0: Intel 82371SB USB Host Controller rev 0x01 int d irq 10 on pci0.7.2 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode mp_lock = 0002; cpuid = 0; lapic.id = fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0216a74 stack pointer = 0x10:0xc0313e18 frame pointer = 0x10:0xc0313e38 code segment= base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPC = 0 current progess = 0 () interrupt mask = net tty bio cam - SMP: XXX kernel: type 12 trap, code=0 Stopped at INTREN+0x2c:movl%ecx,0(%edx) db trace INTREN(a,c01fd294,c0da1000,c028d14c,0) at INTREN+0x2c add_intrdesc(c0d93e20,400,c028a2f8,c0da1000,a) at add_intrdesc+0x29 intr_connect(c0d93e20,,a,c01fd294,c0da1000,c028d14c,0) at intr_connect+0x2e pci_map_int_right(c0751608,c01fd294,c0da1000,c028d14c,0) at pci_map_int_right+0x31 pci_map_int(c0751608,c01fd294,c0da1000,c028d14c,c0751608,20) at pci_map_int+0x16 uhci_pci_attach(c0751608,0) at uhci_pci_attach+0x75 pci_drvattach(c0751600,c0751600,0,7,c0322f68) at pci_drvattach+0x5f pci_probebus(0,c02637b2,0) at pci_probebus+0x53 pci_probe(0,c0322f98,c0214d70,c0322fac,c014a1f7) at pci_probe+0x39 pci_configure(c0322fac,c014a1f7,0,320c00,326000) at pci_configure+0xa configure(0) at configure+0x20 main(c0322fb8,0,8000,c0161189,c0403000) at main+0x83 begin() at begin+0x55 --- -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: question about egcs
Will egcs affect the size of the kernel or any other compiledcode? Verses what other compiler?? Of course the compiler will affect the size of any compiled code. It may do worse, or even better. Various -O values will affect the size too. I read that the exception code can add a lot to the object size. As will whether the language is C or C++. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
On Wed, Dec 29, 1999 at 08:57:33PM +0200, Mark Murray wrote: I don't see the errors below, I see libroken breaking because libgcc.a can't be found. Can we track this down? Please post the output from cc -print-search-dirs cc -print-libgcc-file-name I also wouldn't mind to see the output from adding "-v" to CFLAGS in /etc/make.conf or somewhere closer to the problem. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
3. Raise this issue with Cygnus. Not really Cygnus is the wrong organization to raise this issue . Could you *please* explain why??? Gcc 2.96 will not be out before 4.0. So Gcc 2.95.x is what is going into 4.0. Now should a Gcc 2.95.3 were to come out, then we'd get a new compiler for 4.0. As someone else pointed out the gcc-devel port does not exhibit the bug which I posted. Lets think about this in FreeBSD terms -- 4.0 does not have some problem that 3.4-R does. However it wasn't known that 3.4-R had this problem and the reason why 4.0 does not have this problem is due to *tons* of code changes, not necessarily in response to this problem. Now would the FreeBSD Project like to know that there is a problem with 3.4-R that isn't in 4.0 along with a test case to show the problem? Would the FreeBSD Project, maybe just maybe be interested in fixing the problem and releasing a 3.5-R? Just like FreeBSD, EGCS has two code branches. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
On Thu, Dec 30, 1999 at 02:21:48PM +1100, Andy Farkas wrote: ...the idea was to continue the make process further along to where another source file that also included LevelStat.h got compiled, to check whether it bombs as well - it didn't. ``make -k'' might have been a better choice as you don't have to remember to rm the fake .o later. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
Gcc 2.96 will not be out before 4.0. So Gcc 2.95.x is what is going into 4.0. Now should a Gcc 2.95.3 were to come out, then we'd get a new compiler for 4.0. Lets think about this in FreeBSD terms -- 4.0 does not have some problem that 3.4-R does. However it wasn't known that 3.4-R had this problem and Hi, I am running FreeBSD -current and I got no clue as to what is going on FreeBSD 3.xxx. The problem was reported for FreeBSD -current. Okay, lets hope that gcc 2.9.53 comes out before the release of FreeBSD 4.0. Take Care -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
On Wed, Dec 29, 1999 at 07:43:07PM -0800, Amancio Hasty wrote: Gcc 2.96 will not be out before 4.0. So Gcc 2.95.x is what is going into 4.0. Now should a Gcc 2.95.3 were to come out, then we'd get a new compiler for 4.0. Lets think about this in FreeBSD terms -- 4.0 does not have some problem that 3.4-R does. However it wasn't known that 3.4-R had this problem and I am running FreeBSD -current and I got no clue as to what is I *REALIZE* THAT. I was making an _analogy_. The problem was reported for FreeBSD -current. The problem most likely needs to be reported for GCC 2.95, *NOT* FreeBSD. Okay, lets hope that gcc 2.9.53 comes out before the release of FreeBSD 4.0. Not unless someone like you gets involved and files a bug report with Cygnus. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc compile error
Hi David, Last time, the problem does not exist with the gcc-devel port which directly implies that the problem has been fixed so I see no point on reporting the bug to Cygnus. I can in the future report the bug to Cygnus if the bug has not been fixed in a subsequent snapshot. I will play with gcc-devel some tonite to see if I can use it for all my ports. Some background: I am working on XFree86 to help bring about yuv + scaling hardware support -- my main priority is X for I if get too side tracked I may miss my window of opportunity to hack . Take Care -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
_T defined in ctype.h collides with c++ library
I reported this issue as PR misc/15127, and
posted once to hackers but get no response at all.
In FreeBSD, _T and other two letter macros are
defined in ctype.h.
Some standard c++ library code use _T as local identifiers.
I mean the library that come with egcs-2.95.[12] and 2.96 191110.
/usr/include/g++/typemacros.h also defines _T. (in 3.3R, I'm
not sure on later versions)
So, I feel better to remove these two character defines from
ctype.h. This procedure would involve also change the code in
src/lib/libc/locale/{ctype,table}.c
Substitute _T with _CTYPE_T in ctype.h
and
#define _T _CTYPE_T
in src/lib/libc/locale/{ctype,table}.c
would reduce the undocumented global namespace pollution.
What do you think of this? Is this worth doing, or you won't
change that, or any better way to go?
I think that the c++ library should not use _T anyway, and
the use of _T is reported to libstdc++-v3 group with PR #19.
The usage of _T is not very few and I'm not sure
I found all of them.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
-current buildworld dies, retch.
Otay, please tell me how to fix: === usr.sbin/ifmcstat cc -O -pipe -DINET6 -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/ifmcstat/ifmcstat.c gzip -cn /usr/src/usr.sbin/ifmcstat/ifmcstat.8 ifmcstat.8.gz /usr/src/usr.sbin/ifmcstat/ifmcstat.c: In function `main': /usr/src/usr.sbin/ifmcstat/ifmcstat.c:109: storage size of `arpcom' isn't known I have for the last 12h: 1. retried cvsup'ing build; sleep (2x3600); 2. rm -rf /usr/src ; cvsup standard-supfile ; cd /usr/src ; make world Thanks, Russell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world broken
When I tried to compile my world this fail... I'm Running FreeBSD 4.0-CURRENT. sh /usr/src/tools/install.sh -c -o root -g wheel -m 555 /usr/src/usr.bin/yacc/yyfix.sh /usr/obj/usr/src/i386/usr/bin/yyfix sh /usr/src/tools/install.sh -c -s -o root -g wheel -m 555 yacc /usr/obj/usr/src/i386/usr/bin /usr/obj/usr/src/i386/usr/bin/byacc - /usr/obj/usr/src/i386/usr/bin/yacc cd /usr/src/usr.bin/colldef; make obj; make depend; make all; make install /usr/obj/usr/src/i386/usr/src/usr.bin/colldef created for /usr/src/usr.bin/colldef yacc -d /usr/src/usr.bin/colldef/parse.y *** Signal 12 Stop in /usr/src/usr.bin/colldef. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Any Idea ? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world broken
On Wednesday, 29 December 1999 at 23:17:29 -0600, juan wrote: When I tried to compile my world this fail... I'm Running FreeBSD 4.0-CURRENT. What date? /usr/obj/usr/src/i386/usr/src/usr.bin/colldef created for /usr/src/usr.bin/colldef yacc -d /usr/src/usr.bin/colldef/parse.y *** Signal 12 This looks like you've updated your source tree and have not built a new kernel. Try the new kernel first, then the buildworld. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
On Wed, Dec 29, 1999 at 08:57:33PM +0200, Mark Murray wrote: I don't see the errors below, I see libroken breaking because libgcc.a can't be found. Can we track this down? Please post the output from cc -print-search-dirs cc -print-libgcc-file-name I found it - its a binary that is used only during the build to construct a header file. Marcel is helping me sort it out. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current buildworld dies, retch.
On Wednesday, 29 December 1999 at 21:54:42 -0700, Russell L. Carter wrote: Otay, please tell me how to fix: === usr.sbin/ifmcstat cc -O -pipe -DINET6 -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/ifmcstat/ifmcstat.c gzip -cn /usr/src/usr.sbin/ifmcstat/ifmcstat.8 ifmcstat.8.gz /usr/src/usr.sbin/ifmcstat/ifmcstat.c: In function `main': /usr/src/usr.sbin/ifmcstat/ifmcstat.c:109: storage size of `arpcom' isn't known I think for this one you need to find who broke it and make him unbreak it. You may supply a pointy hat. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
