Re: Page faults from bento cluster (Re: Problems reading vmcores)
On 31 Aug, Kris Kennaway wrote:
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
Looks like a NULL structure pointer dereference. It looks like the
access is four bytes into the structure.
#7 0xc021d91f in exec_elf32_imgact (imgp=0xda326bb4) at imgact_elf.c:607
#8 0xc022a9a2 in execve (td=0xc484c240, uap=0xda326d10)
at /usr/src/sys/kern/kern_exec.c:280
#9 0xc03a8a31 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135022716, tf_esi = 0, tf_ebp =
-1077940704, tf_isp = -634229388, tf_ebx = 135022736, tf_edx = 135022736, tf_ecx =
135022895, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134697908, tf_cs = 31,
tf_eflags = 659, tf_esp = -1077940748, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#10 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
I've seen other reports of similar crashes on the list. What version of
imgact_elf.c is this?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sparc64 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/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- === usr.bin/top In file included from /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:30: /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include/sys/param.h:75:27: sys/syslimits.h: No such file or directory /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include/sys/param.h:105:27: machine/param.h: No such file or directory /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include/sys/param.h:107:28: machine/limits.h: No such file or directory In file included from /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:32: /usr/home/des/tinderbox/sparc64/src/contrib/top/os.h:22:20: stdio.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/contrib/top/os.h:24:21: string.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/contrib/top/os.h:25:21: memory.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/contrib/top/os.h:26:21: stdlib.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:33:19: stdio.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:34:19: nlist.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:35:18: math.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:36:17: kvm.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:37:17: pwd.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:38:23: sys/errno.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:39:24: sys/sysctl.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:40:24: sys/dkstat.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:41:22: sys/file.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:43:22: sys/proc.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:44:22: sys/user.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:45:25: sys/vmmeter.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:46:26: sys/resource.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:47:24: sys/rtprio.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:50:20: stdlib.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:52:20: unistd.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:53:62: osreldate.h: No such file or directory cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cpp0': No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/usr.bin/top. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/usr.bin. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page faults from bento cluster (Re: Problems reading vmcores)
On 31 Aug, Kris Kennaway wrote:
Another page fault in umount
I haven't seen any reports of this one before.
#6 0xc0399a48 in calltrap () at {standard input}:98
#7 0xc029198d in vflush (mp=0xc5e6, rootrefs=0, flags=2) at vnode_if.h:309
#8 0xc0200eaa in devfs_unmount (mp=0xc5e6, mntflags=524288, td=0xc5855000)
at /usr/src/sys/fs/devfs/devfs_vfsops.c:130
#9 0xc028d9b4 in dounmount (mp=0xc5e6, flags=-974782464, td=0xc5855000)
at /usr/src/sys/kern/vfs_mount.c:1296
#10 0xc028d79c in unmount (td=0xc5855000, uap=0xda021d10)
at /usr/src/sys/kern/vfs_mount.c:1239
#11 0xc03a8a31 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134845070, tf_esi = 134950973,
tf_ebp = -1077938936, tf_isp = -637395596, tf_ebx = 0, tf_edx = 1, tf_ecx = 3, tf_eax
= 22, tf_trapno = 12, tf_err = 2, tf_eip = 134524579, tf_cs = 31, tf_eflags = 514,
tf_esp = -1077939060, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1050
#12 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
This code in vflush() bothers me:
mtx_lock(mntvnode_mtx);
loop:
for (vp = TAILQ_FIRST(mp-mnt_nvnodelist); vp; vp = nvp) {
/*
* Make sure this vnode wasn't reclaimed in getnewvnode().
* Start over if it has (it won't be on the list anymore).
*/
if (vp-v_mount != mp)
goto loop;
nvp = TAILQ_NEXT(vp, v_nmntvnodes);
mtx_unlock(mntvnode_mtx);
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
/*
* Skip over a vnodes marked VV_SYSTEM.
*/
if ((flags SKIPSYSTEM) (vp-v_vflag VV_SYSTEM)) {
VOP_UNLOCK(vp, 0, td);
mtx_lock(mntvnode_mtx);
continue;
}
/*
* If WRITECLOSE is set, flush out unlinked but still open
* files (even if open only for reading) and regular file
* vnodes open for writing.
*/
error = VOP_GETATTR(vp, vattr, td-td_ucred, td);
VI_LOCK(vp);
As near as I can tell the panic is happening in VOP_GETATTR(). It looks
to me like it would be possible for the vnode to be recycled between the
time when it passes the vp-v_mount test at the top of the loop and the
time when vn_lock() succeeds. Shouldn't we bump the vnode reference
count by calling vref() at the top of the loop and add the appropriate
calls to vrele()?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
On Sat, Aug 31, 2002 at 10:31:15PM -0700, Dag-Erling Smorgrav wrote: -- [...] -- Kernel build for GENERIC started on Sat Aug 31 22:28:29 PDT 2002 -- === aic7xxx/ahc (null): Unable to malloc scope object *** Error code 70 Um, what? I just did a buildworld, followed by a buildkernel KERNCONF=GENERIC and did not see this. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page faults from bento cluster (Re: Problems reading vmcores)
On Sun, 1 Sep 2002, Don Lewis wrote:
This code in vflush() bothers me:
mtx_lock(mntvnode_mtx);
loop:
for (vp = TAILQ_FIRST(mp-mnt_nvnodelist); vp; vp = nvp) {
/*
* Make sure this vnode wasn't reclaimed in getnewvnode().
* Start over if it has (it won't be on the list anymore).
*/
if (vp-v_mount != mp)
goto loop;
nvp = TAILQ_NEXT(vp, v_nmntvnodes);
mtx_unlock(mntvnode_mtx);
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
/*
* Skip over a vnodes marked VV_SYSTEM.
*/
if ((flags SKIPSYSTEM) (vp-v_vflag VV_SYSTEM)) {
VOP_UNLOCK(vp, 0, td);
mtx_lock(mntvnode_mtx);
continue;
}
/*
* If WRITECLOSE is set, flush out unlinked but still open
* files (even if open only for reading) and regular file
* vnodes open for writing.
*/
error = VOP_GETATTR(vp, vattr, td-td_ucred, td);
VI_LOCK(vp);
As near as I can tell the panic is happening in VOP_GETATTR(). It looks
to me like it would be possible for the vnode to be recycled between the
time when it passes the vp-v_mount test at the top of the loop and the
time when vn_lock() succeeds. Shouldn't we bump the vnode reference
count by calling vref() at the top of the loop and add the appropriate
calls to vrele()?
Rev.1.395 made some changes that I didn't like much here. The
VOP_GETATTR() is now done unconditionally. This pessimizes vflush()
and enlarges any race windows. I think WRITECLOSE is only used for
mount -u from rw to ro, so the pessimization exercises code that was
rarely used before.
Rev.1.394 called VOP_GETATTR() with the interlock held. This was wrong
but probably reduced race windows. The window seems to have been
opened before rev.1.394 by releasing mntvnode_slock before aquiring
the interlock. RELENG_4 doesn't release mntvnode_slock at that point
(it holds both locks across the VOP_GETATTR()).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sshd doesn't log hostname into utmp correctly
Hi,
Thu, 01 Aug 2002 16:39:45 +0900 の刻に「ume」、すなわち
Hajimu UMEMOTO [EMAIL PROTECTED] 氏曰く
ume Current sshd doesn't handle actual size of struct sockaddr correctly,
ume and does copy it as long as just size of struct sockaddr. So, sshd
ume deesn't log hostname into utmp correctly.
ume Here is a proposed patch to fix this problem. Please review it.
I discussed about this on [EMAIL PROTECTED] as use
requested. Then, this problem is occur only under FreeBSD because of
our hack.
However, this is potential problem of OpenSSH-portable, and they
agreed to fix this. But, there is no fixed version of
OpenSSH-portable available, yet.
This problem is serious and I received the claim from many people
especially from Japan. This problem is occur only when connecting via
IPv6, and there are many people who are using IPv6 in Japan.
So, I wish to fix this problem in time for 4.7-RELEASE. I wish to commit
this fix. Any objection or any idea?
Sincerely,
ume [2 sshd-loghost.diff text/x-patch; US-ASCII (7bit)]
ume Index: crypto/openssh/monitor.c
ume diff -u crypto/openssh/monitor.c.orig crypto/openssh/monitor.c
ume --- crypto/openssh/monitor.c.orig Thu Jul 11 08:04:07 2002
ume +++ crypto/openssh/monitor.c Thu Aug 1 15:21:58 2002
ume @@ -1113,8 +1113,8 @@
ume * the address be 0.0.0.0.
ume */
umememset(from, 0, sizeof(from));
ume + fromlen = sizeof(from);
umeif (packet_connection_is_on_socket()) {
ume - fromlen = sizeof(from);
umeif (getpeername(packet_get_connection_in(),
ume(struct sockaddr *) from, fromlen) 0) {
umedebug("getpeername: %.100s", strerror(errno));
ume @@ -1124,7 +1124,7 @@
ume/* Record that there was a login on that tty from the remote host. */
record_login(s-pid, s-tty, pw-pw_name, pw-pw_uid,
umeget_remote_name_or_ip(utmp_len, options.verify_reverse_mapping),
ume - (struct sockaddr *)from);
ume + (struct sockaddr *)from, fromlen);
ume }
ume static void
ume Index: crypto/openssh/session.c
ume diff -u crypto/openssh/session.c.orig crypto/openssh/session.c
ume --- crypto/openssh/session.c.orig Sun Jul 28 00:43:29 2002
ume +++ crypto/openssh/session.c Thu Aug 1 15:22:21 2002
ume @@ -721,8 +721,8 @@
ume * the address be 0.0.0.0.
ume */
umememset(from, 0, sizeof(from));
ume + fromlen = sizeof(from);
umeif (packet_connection_is_on_socket()) {
ume - fromlen = sizeof(from);
umeif (getpeername(packet_get_connection_in(),
ume(struct sockaddr *) from, fromlen) 0) {
umedebug("getpeername: %.100s", strerror(errno));
ume @@ -735,7 +735,7 @@
umerecord_login(pid, s-tty, pw-pw_name, pw-pw_uid,
umeget_remote_name_or_ip(utmp_len,
umeoptions.verify_reverse_mapping),
ume - (struct sockaddr *)from);
ume + (struct sockaddr *)from, fromlen);
ume #ifdef USE_PAM
ume/*
ume Index: crypto/openssh/sshlogin.c
ume diff -u crypto/openssh/sshlogin.c.orig crypto/openssh/sshlogin.c
ume --- crypto/openssh/sshlogin.c.orig Sat Jul 13 12:53:57 2002
ume +++ crypto/openssh/sshlogin.c Thu Aug 1 15:24:36 2002
ume @@ -66,12 +66,12 @@
ume */
ume void
ume record_login(pid_t pid, const char *ttyname, const char *user, uid_t uid,
ume -const char *host, struct sockaddr * addr)
ume +const char *host, struct sockaddr * addr, socklen_t addrlen)
ume {
umestruct logininfo *li;
umeli = login_alloc_entry(pid, user, host, ttyname);
ume - login_set_addr(li, addr, sizeof(struct sockaddr));
ume + login_set_addr(li, addr, addrlen);
umelogin_login(li);
umelogin_free_entry(li);
ume }
ume Index: crypto/openssh/sshlogin.h
ume diff -u crypto/openssh/sshlogin.h.orig crypto/openssh/sshlogin.h
ume --- crypto/openssh/sshlogin.h.orig Sat Jul 13 12:53:57 2002
ume +++ crypto/openssh/sshlogin.h Thu Aug 1 15:26:40 2002
ume @@ -16,7 +16,7 @@
ume void
ume record_login(pid_t, const char *, const char *, uid_t,
ume -const char *, struct sockaddr *);
ume +const char *, struct sockaddr *, socklen_t);
ume void record_logout(pid_t, const char *, const char *);
ume u_long get_last_login_time(uid_t, const char *, char *, u_int);
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Saturday, August 31, 2002, at 06:04 PM, Terry Lambert wrote: David O'Brien wrote: Because rather than leaving it alone for a while, they are already planning a 3.3. 8-). And comments on this list to that effect. I don't follow. The GCC group branches previous to a release and makes an initial + point releases from it. I thought it was the general consensus that the 3.1 version of the compiler was broken, and generated bad code, and that the 3.2 compiler had a lot of these problems corrected, but destroyed binary compatability with 3.1. Yes but if you go through and read gcc.gnu.org you will see that 3.2 can be configured on linux to use the multi-vendor ABI standard. Actually they have been trying to make this work all along and is probably why they break ABI compatibility. 3.1 has issues with template classes that use functions containing static variables [at least a pre-release of it did on Darwin/OS X]. This kind of bug made 3.2 necessary for some people [though I hope every time the fix something that their test-cases increases by one that would be smart anyway]. 3.2 is the more confident ABI and while there are no guarantees that 3.3 will work with 3.2... there seems to be better feelings about it. I guess the fear is that, if they are willing to destroy binary compatability between point releases, with another point release in the wings, it would be risky to pick the point release one behind to standardise upon. There will hopefully always be one behind its called progress. They haven't implemented export yet so they don't have a 100% compliant C++ compiler yet either... no reason to stop. It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. RedHat actually created a release that never occurred [2.96] in the gcc release chain... and if you use it, its actually a pretty nice compiler I know the ABI doesn't work with anything but 2.96 though. How is this different from FreeBSD? (other than they branch much before the .0 release and we don't). FreeBSD has been been branched for 18 months before the 5.0 release; what are you talking about?!? There's not much more much than that, in the entire history of GCC. I thought the comparison was pretty clear myself... FreeBSD current is branched from the same CVS then worked on... the STABLE folks don't usually start whining about all the stuff that's going to be broken for them maybe not until DP2 anyway. :) -- Terry 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: gcc 3.1 / streambuf.h broken with using namespace std;
[EMAIL PROTECTED] wrote: [ ... ] I guess the fear is that, if they are willing to destroy binary compatability between point releases, with another point release in the wings, it would be risky to pick the point release one behind to standardise upon. There will hopefully always be one behind its called progress. They haven't implemented export yet so they don't have a 100% compliant C++ compiler yet either... no reason to stop. Realize that this was a very old discussion which was only recent revived because of David O'Brien's mailer. 8-). The context of this discussion was one of people demanding that David do work to migrate FreeBSD 5.0 to GCC 3.x (2 = x = 3), and the fact that 3.3 will not be officially released until after the scheduled FreeBSD 5.0 release date. It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. RedHat actually created a release that never occurred [2.96] in the gcc release chain... and if you use it, its actually a pretty nice compiler I know the ABI doesn't work with anything but 2.96 though. This is the point I was making in the post previous, to which David's was a reply. The general consensus was that this was a pretty stupid thing for RedHat to do, without the permission of the GCC maintainers. What that means for a FreeBSD 5.0 is a potential incompatability for a point release (something which has never happened in the history of FreeBSD) at some time in the future, when the compiler changes yet again, or a lock-in to an older version of the GCC compiler (something which *has* happened). Both possibilities have their drawbacks. How is this different from FreeBSD? (other than they branch much before the .0 release and we don't). FreeBSD has been been branched for 18 months before the 5.0 release; what are you talking about?!? There's not much more much than that, in the entire history of GCC. I thought the comparison was pretty clear myself... FreeBSD current is branched from the same CVS then worked on... the STABLE folks don't usually start whining about all the stuff that's going to be broken for them maybe not until DP2 anyway. :) It more about what happens overall, when, for example, all the C++ Gnome code has to be recompiled, or the software stops working between point releases, because the GCC folks have broken binary compatability between compiler point releases (again). In any case, the decision of what compiler to import is, as it always has been, up to the guy who doe the work, and so far, that has been David. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 release schedule?
David O'Brien wrote: On Wed, Aug 28, 2002 at 09:28:20AM -0400, Bosko Milekic wrote: I think we're on our way to stabilizing -CURRENT enough for a DP2 soon. I would sit and wait it out just a tad longer. :-) A 5.0 DP2 branch was created just yesterday. So how ever good yesterday's -current was will affect DP2. I rather expected the release engineers to at least querry the lists to ask what the known issues are before picking which code to base DP2 on. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message I will wait for a while for things to be cleaned up, but what tags would I use for CVSUP to get that branch? Thanks, Rob. -- - The Numeric Python EM Project www.pythonemproject.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
hw.pci.enable_io_modes default value.
Hello, I had freeze at boot problem with my laptop and -CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=42262 I found the solution: setting hw.pci.enable_io_modes to 0. So I have a question: that sysctl has to be =1 by default? I mean if I have that issue with it and my laptop, maybe I'll not be the only one with that problem. Well I'm sure there is a good reason for that default setting. Perhaps we could write somewhere that setting may lead to hangs with some hardware :) Marc PS: btw kern/42262 can be closed :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 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/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Sep 1 09:38:49 PDT 2002 -- Kernel build for GENERIC completed on Sun Sep 1 10:21:56 PDT 2002 -- Kernel build for LINT started on Sun Sep 1 10:21:57 PDT 2002 -- === LINT /local0/scratch/des/src/sys/i386/conf/LINT: unknown option AHC_DEBUG_SEQUENCER *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Sun, Sep 01, 2002 at 07:41:24AM -0500, [EMAIL PROTECTED] wrote: I thought it was the general consensus that the 3.1 version of the compiler was broken, and generated bad code, and that the 3.2 compiler had a lot of these problems corrected, but destroyed binary compatability with 3.1. Yes but if you go through and read gcc.gnu.org you will see that 3.2 can be configured on linux to use the multi-vendor ABI standard. The multi-vendor ABI standard (agreed upon by all that care about IA-64), was supposed to be properly implemented in 3.1.x. Due to a bug in the implementation 3.1.x wasn't compliant to the new multi-vendor ABI standard. THAT IS THE ONLY REASON 3.2 CAME INTO EXISTENCE. FreeBSD, SuSE, RedHat, Mandrake all have new OS releases coming out this Fall and did not want to go thru an ABI change between 3.1.1 and what was then 3.2 (and is now 3.3). I led the push, strongly supported by some SuSE folks to create a 3.2 which was exactly 3.1.1 + multi-vendor ABI standard compliance fixes. Along the way to 3.2.0 a few other bugs got fixed that would have been in 3.1.2 had the 3.2 we have today not been created. The multi-vendor ABI standard fixes could not go into 3.1.1 or 3.1.2 because the GCC developers have a rule that ABI changes cannot happen in mid-branch. We have the same with our RELENG_X branches. It is *that* simple. Rather than bitch that 3.1.1 sucks; we should thanking the GCC Steering Committee that after much thought they were willing to take the vendors' needs into account. I am not sure FreeBSD would have done the same. Actually they have been trying to make this work all along and is probably why they break ABI compatibility. 3.1 has issues with template classes that use functions containing static variables [at least a pre-release of it did on Darwin/OS X]. Apple highly modifies the GCC sources. So any bugs/problems/issues you find in their compiler you cannot blame on the GCC developers w/o researching the bug/problem/issue. 3.2 necessary for some people [though I hope every time the fix something that their test-cases increases by one that would be smart anyway]. The test suite does. We should be so lucky to have such a test suite. 3.2 is the more confident ABI and while there are no guarantees that 3.3 will work with 3.2... there seems to be better feelings about it. Correct. Not only better feelings but fully intended. But as we saw with 3.1.0, bugs happen. It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. 3.3.0 will be released before FreeBSD 5.1. It is my advice to FreeBSD'ville that we go with a GCC 3.3 snapshot for FBSD 5.0 and a GCC 3.3.0 release for FBSD 5.1. That way we can get the new features of 3.3 into our 5.x branch. AND get bug fixes by importing 3.3.1 and 3.3.2 into later FBSD 5.x releases. RedHat actually created a release that never occurred [2.96] in the gcc release chain... and if you use it, its actually a pretty nice compiler I know the ABI doesn't work with anything but 2.96 though. The ABI was in flux during those times -- the 2.96 ABI is compatabile with nothing else. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
It is *that* simple. yep. Rather than bitch that 3.1.1 sucks; we should thanking the GCC Steering Committee that after much thought they were willing to take the vendors' needs into account. I am not sure FreeBSD would have done the same. I never said it sucked... I think the ABI standardization process is *very* important as it will be an enabling technology... these things don't come without some growing pains. Actually they have been trying to make this work all along and is probably why they break ABI compatibility. 3.1 has issues with template classes that use functions containing static variables [at least a pre-release of it did on Darwin/OS X]. Apple highly modifies the GCC sources. So any bugs/problems/issues you find in their compiler you cannot blame on the GCC developers w/o researching the bug/problem/issue. Wasn't aware to what degree GCC is modified by Apple... I knew they did some things... 3.2 necessary for some people [though I hope every time the fix something that their test-cases increases by one that would be smart anyway]. The test suite does. We should be so lucky to have such a test suite. Indeed! :) 3.2 is the more confident ABI and while there are no guarantees that 3.3 will work with 3.2... there seems to be better feelings about it. Correct. Not only better feelings but fully intended. But as we saw with 3.1.0, bugs happen. Yes... I think you and I are generally on the same page :). It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. 3.3.0 will be released before FreeBSD 5.1. It is my advice to FreeBSD'ville that we go with a GCC 3.3 snapshot for FBSD 5.0 and a GCC 3.3.0 release for FBSD 5.1. That way we can get the new features of 3.3 into our 5.x branch. AND get bug fixes by importing 3.3.1 and 3.3.2 into later FBSD 5.x releases. Yes! yes! YES! :) 100% agree! IMO DP-2 should have gcc-3.3 snap perhaps even FreeBSD 5.0 release [assuming that 5.0 is released on November 20, 2002... I have doubts but I'd rather it be done properly than done quickly... Its one reason I like FreeBSD and the community.] Seems like things are going exactly as they should... going to 3.3 should greatly decrease developer pain overall. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.3 [Was streambuf.h broken ... ]
* David O'Brien [EMAIL PROTECTED] [2002-09-01 14:31]: [snip] It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. 3.3.0 will be released before FreeBSD 5.1. It is my advice to FreeBSD'ville that we go with a GCC 3.3 snapshot for FBSD 5.0 and a GCC 3.3.0 release for FBSD 5.1. That way we can get the new features of 3.3 into our 5.x branch. AND get bug fixes by importing 3.3.1 and 3.3.2 into later FBSD 5.x releases. From the GCC Development Plan web page http://www.gnu.org/software/gcc/develop.html#future and the FreeBSD 5.0 Release Process web page http://www.freebsd.org/releases/5.0R/schedule.html here is a side by side summary of both published plans: GCC 3.3 FreeBSD 5.0 ---++- | GCC 3.3 in Stage 3| FreeBSD 5.0 in DP-2 | (bug fixes only) | || Oct 1 || -current Feature Freeze || Oct 15 | GCC Stage 3 Ends | | (begin release branch) | || Oct 20 || -current Code Freeze || || || Nov 20 || 5.0 Announced || || || Dec 15 | GCC 3.3 Released | || Best Regards, jpb === To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Sun, 1 Sep 2002, David O'Brien wrote: 3.3.0 will be released before FreeBSD 5.1. It is my advice to FreeBSD'ville that we go with a GCC 3.3 snapshot for FBSD 5.0 and a GCC 3.3.0 release for FBSD 5.1. That way we can get the new features of 3.3 into our 5.x branch. AND get bug fixes by importing 3.3.1 and 3.3.2 into later FBSD 5.x releases. 5.0 will be a beta and will not be ready for production use right? If so, it seems perfectly acceptable to use a 3.3 snapshot and risk breaking binary compatibility between 5.0 and 5.1. If it happens, you mention the breakage in UPDATING and people who are using 5.0 should be expected to be paying attention. This way we get to where we want to be, which is 5.2 or 5.3 being a stable operating system with a stable and well-supported compiler. That seems to be the right long-term goal to shoot for. It sounds like gcc-3.1 or gcc-3.2 will be archaic and buggy by the time that 5.2 and 5.3 come out. I'm not sure exactly how FreeBSD would be pulling a redhat by putting in a development snapshot if the 5.0 release is clearly labelled for non-production use only... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: GCC 3.2 in progress
I will import GCC 3.2 snapshot from the top of FSF gcc-3_2-branch in about ten minutes. This task should not take long to complete, but since this is the first time I am doing it, there is good possibility of unexpected delays, so please be patient. Please respond immediately if you feel that I need to hold the import for some reason. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page faults from bento cluster (Re: Problems reading vmcores)
On Sat, Aug 31, 2002 at 11:30:32PM -0700, Don Lewis wrote: I've seen other reports of similar crashes on the list. What version of imgact_elf.c is this? $FreeBSD: src/sys/kern/imgact_elf.c,v 1.111 2002/06/02 20:05:54 schweikh Exp $ Kris msg42383/pgp0.pgp Description: PGP signature
bind 9.x import before 5.0-RELEASE
Hi, Do we have any plans to import bind 9.x into the base system before the 5.0 release date. AFAIK it should break some tools that rely on the resolver library. Is that correct? I could not find any previous thread about this on both current and hackers mailing list archives. Thanks in advance, -- Giovanni P. Tirloni [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: ffs_clusteralloc: map mismatch
Core available on request.
Kris
panic: ffs_clusteralloc: map mismatch
panic messages:
---
panic: ffs_clusteralloc: map mismatch
Uptime: 23m31s
Dumping 510 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory.
in /usr/src/sys/kern/kern_shutdown.c
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc03337a1 in ffs_clusteralloc (ip=0xc45c0b00, cg=0, bpref=206, len=5)
at /usr/src/sys/ufs/ffs/ffs_alloc.c:1528
#4 0xc033291a in ffs_hashalloc (ip=0xc45c0b00, cg=0, pref=0, size=5,
allocator=0xc0b0 ffs_clusteralloc)
at /usr/src/sys/ufs/ffs/ffs_alloc.c:1156
#5 0xc033147e in ffs_reallocblks_ufs1 (ap=0x0)
at /usr/src/sys/ufs/ffs/ffs_alloc.c:490
#6 0xc0331091 in ffs_reallocblks (ap=0x0) at /usr/src/sys/ufs/ffs/ffs_alloc.c:396
#7 0xc028804c in cluster_write (bp=0xce5a9dc4, filesize=491520, seqcount=1)
at vnode_if.h:1194
#8 0xc034bc0c in ffs_write (ap=0xda0d1be0) at /usr/src/sys/ufs/ffs/ffs_vnops.c:811
#9 0xc029b6c2 in vn_write (fp=0xc500c000, uio=0xda0d1c7c, active_cred=0xc5075f00,
flags=0, td=0xc58d7780) at vnode_if.h:408
#10 0xc0262c55 in dofilewrite (td=0xc58d7780, fp=0xc500c000, fd=0, buf=0x817,
nbyte=0, offset=0, flags=0) at file.h:213
#11 0xc0262a99 in write (td=0xc58d7780, uap=0xda0d1d10)
at /usr/src/sys/kern/sys_generic.c:331
#12 0xc03a8a31 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134658176, tf_esi = 134658176,
tf_ebp = -1077938728, tf_isp = -636674700, tf_ebx = 12288, tf_edx = 5256, tf_ecx =
134658176, tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 134554123, tf_cs = 31,
tf_eflags = 646, tf_esp = -1077938756, tf_ss = 47}) at
/usr/src/sys/i386/i386/trap.c:1050
#13 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
msg42385/pgp0.pgp
Description: PGP signature
Re: HEADS UP: GCC 3.2 in progress
So, what is it about gcc 3.2 that's so important, considering that we wanted to do a real 5.0 release within 2 months? On Sun, 1 Sep 2002, Alexander Kabaev wrote: I will import GCC 3.2 snapshot from the top of FSF gcc-3_2-branch in about ten minutes. This task should not take long to complete, but since this is the first time I am doing it, there is good possibility of unexpected delays, so please be patient. Please respond immediately if you feel that I need to hold the import for some reason. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, 1 Sep 2002 14:34:12 -0700 (PDT) Matthew Jacob [EMAIL PROTECTED] wrote: So, what is it about gcc 3.2 that's so important, considering that we wanted to do a real 5.0 release within 2 months? Some well known problem present in our current GCC snapshot appear to be fixed in 3.2. GCC 3.2 is using vendor-independent C++ ABI. Assuming they got it right this time, this will allow us to upgrade to 3.3 more painlessly later. People who were asking for an upgrade got what they deserved :) -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, Sep 01, 2002 at 02:34:12PM -0700, Matthew Jacob wrote: So, what is it about gcc 3.2 that's so important, considering that we wanted to do a real 5.0 release within 2 months? This is really 3.1.1 -- so it is a minor point release. 3.2 fixes a bug that changes the API so it couldn't be fixed in 3.1.1. Otherwise they are the same compilers. That said, we don't want to be stuck with a stale compiler for all of 5.x. I highly recomend we use 3.3 in our 5.0-R. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Well, actually, I *wasn't* asking for an upgrade. From recent experience it is my estimation that a gcc upgrade sets 5.0 development back a month (that is, the last GCC upgrade kept *me* from working productively for around a month due to various this thats and the others). If that's what people want, that's fine. I could also be totally wrong, and this won't break things. I'm just a bit startled that this appears out of nowhere (I sure don't recall it being discussed) and just happens, with 10 minutes warning. This is, IMO, why FreeBSD is not going to be very successful. You cannot just make major toolchain changes w/o at least *some* belief that this is going to be done well. Did you do a dryrun with the import before checking things in? I don't mean to be hypercritical here, but I feel that it's fair, considering people are starting to really whine about how late 5.0 actually *is* at this point, to begin to ask not even the *hard* questions, but medium firm questions about gee, is this trip *really* necessary? -matt On Sun, 1 Sep 2002, Alexander Kabaev wrote: On Sun, 1 Sep 2002 14:34:12 -0700 (PDT) Matthew Jacob [EMAIL PROTECTED] wrote: So, what is it about gcc 3.2 that's so important, considering that we wanted to do a real 5.0 release within 2 months? Some well known problem present in our current GCC snapshot appear to be fixed in 3.2. GCC 3.2 is using vendor-independent C++ ABI. Assuming they got it right this time, this will allow us to upgrade to 3.3 more painlessly later. People who were asking for an upgrade got what they deserved :) -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, 1 Sep 2002, David O'Brien wrote: On Sun, Sep 01, 2002 at 02:34:12PM -0700, Matthew Jacob wrote: So, what is it about gcc 3.2 that's so important, considering that we wanted to do a real 5.0 release within 2 months? This is really 3.1.1 -- so it is a minor point release. 3.2 fixes a bug that changes the API so it couldn't be fixed in 3.1.1. Otherwise they are the same compilers. That said, we don't want to be stuck with a stale compiler for all of 5.x. I highly recomend we use 3.3 in our 5.0-R. All that's good, but is this on the roadmap of RE core so that adequate destabilization time is accounted for? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, Sep 01, 2002 at 02:50:50PM -0700, Matthew Jacob wrote: I'm just a bit startled that this appears out of nowhere (I sure don't recall it being discussed) and just happens, with 10 minutes warning. This update has been *DEMANDED* in both -current and -ports for months now. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, 1 Sep 2002 14:50:50 -0700 (PDT) Matthew Jacob [EMAIL PROTECTED] wrote: From recent experience it is my estimation that a gcc upgrade sets 5.0 development back a month (that is, the last GCC upgrade kept *me* from working productively for around a month due to various this thats and the others). If that's what people want, that's fine. I could also be totally wrong, and this won't break things. I'm just a bit startled that this appears out of nowhere (I sure don't recall it being discussed) and just happens, with 10 minutes warning. Matt, the change was discussed several times on developers@, so this import is hardly 'out of nowhere'. This is, IMO, why FreeBSD is not going to be very successful. You cannot just make major toolchain changes w/o at least *some* belief that this is going to be done well. Did you do a dryrun with the import before checking things in? About five buildworlds on i386 and two on Alpha. Does that count as dry runs? -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Hi, totally wrong, and this won't break things. I'm just a bit startled that this appears out of nowhere (I sure don't recall it being discussed) and just happens, with 10 minutes warning. The 2.95.3 - 3.1 prerelease upgrade was a big step. 3.1 prerelease - 3.2 is a little step which fixes bugs, make kde working (gif support) again, fixes X11 and mozilla ports. I don't mean to be hypercritical here, but I feel that it's fair, considering people are starting to really whine about how late 5.0 actually *is* at this point, to begin to ask not even the *hard* questions, but medium firm questions about gee, is this trip *really* necessary? I think yes. Gcc 3.1 prerelease had some nasty bugs. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: GCC 3.2.1-pre imported
GCC 3.2.1-pre is now in the tree. Please let me know if you see any problems recompiling your world/kernel. Remember to recompile your C++ ports. GCC 3.2 is not binary compatible with 3.1. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, Sep 01, 2002 at 02:56:26PM -0700, David O'Brien wrote: This update has been *DEMANDED* in both -current and -ports for months now. Yes, GCC 3.1 prerelease bites, big time, k thx. Better to fix it now than later, when people will actually expect it to work. I also dislike the apparent general policy of using prereleases for our compiler in FreeBSD. regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, 1 Sep 2002, Alexander Kabaev wrote: On Sun, 1 Sep 2002 14:50:50 -0700 (PDT) Matthew Jacob [EMAIL PROTECTED] wrote: From recent experience it is my estimation that a gcc upgrade sets 5.0 development back a month (that is, the last GCC upgrade kept *me* from working productively for around a month due to various this thats and the others). If that's what people want, that's fine. I could also be totally wrong, and this won't break things. I'm just a bit startled that this appears out of nowhere (I sure don't recall it being discussed) and just happens, with 10 minutes warning. Matt, the change was discussed several times on developers@, so this import is hardly 'out of nowhere'. I sure didn't see anything on the recent 5.0 schedule about this. Like I said- this is not meant to be hypercritical. Let's assume that I'm not paying that close attention, like a *lot* of developers to the flood of mail. There might have been a note about new compiler import on the recent 5.X schedule changes that surely would catch the eye. This is, IMO, why FreeBSD is not going to be very successful. You cannot just make major toolchain changes w/o at least *some* belief that this is going to be done well. Did you do a dryrun with the import before checking things in? About five buildworlds on i386 and two on Alpha. Does that count as dry runs? Surely they do. Did somebody in ia64 sparc ppc get a headsup? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
I should note that I'm raising more of a flag than normal. This would have been a firing offense at several companies I've worked at. It's not unreasonable to take a lesson from *why* these things are firing offenses and start to raise queries. I've done so. Duty is done. Go back to sleep. On Mon, 2 Sep 2002, Martin Blapp wrote: Hi, totally wrong, and this won't break things. I'm just a bit startled that this appears out of nowhere (I sure don't recall it being discussed) and just happens, with 10 minutes warning. The 2.95.3 - 3.1 prerelease upgrade was a big step. 3.1 prerelease - 3.2 is a little step which fixes bugs, make kde working (gif support) again, fixes X11 and mozilla ports. I don't mean to be hypercritical here, but I feel that it's fair, considering people are starting to really whine about how late 5.0 actually *is* at this point, to begin to ask not even the *hard* questions, but medium firm questions about gee, is this trip *really* necessary? I think yes. Gcc 3.1 prerelease had some nasty bugs. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
oh, btw..
I personally always get a bit more concerned about compiler upgrades. I can and do protect myself from errant /usr/src/sys changes, but everthing else is cvsup based for me, so buildworlds really do need to work well for me. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, Sep 01, 2002 at 03:00:34PM -0700, Will Andrews wrote: On Sun, Sep 01, 2002 at 02:56:26PM -0700, David O'Brien wrote: This update has been *DEMANDED* in both -current and -ports for months now. Yes, GCC 3.1 prerelease bites, big time, k thx. Better to fix it now than later, when people will actually expect it to work. I also dislike the apparent general policy of using prereleases for our compiler in FreeBSD. This is the same as using RELENG_4_6 (ie, 4.6-SECURE) in something. We get bug fixes (that must work on *all* supported GCC arches). The risk is _well_ mitigated. Why is everyone second guessing Kan on this import??? It will be a wonder if we get another import done by him. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Matthew Jacob wrote: This would have been a firing offense at several companies I've worked at. It's not unreasonable to take a lesson from *why* these things are firing offenses and start to raise queries. I've done so. Duty is done. Go back to sleep. Would you rather that we ship with a known broken prerelease compiler? Would you rather that we changed from 3.1-prerelease to 3.1.1-release? gcc-3.2 *is* 'gcc-3.1.1 + ABI bugfix'. They renamed the 3.1 branch to 3.2. All future 3.1.x releases will be called 3.2.x. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
These arguments are all quite familiar- I'm not really moved one way or the other. The point here is that major changes need to be very visible on a product's schedule. You can argue that it isn't a major change- but I'd assert that any toolchain change *is* a major change. I'm *not* arguing against the change- I don't know nearly enough to have an opinion. I *am* commenting on how major changes coming in with little notice often add substantial delays. Furthermore, lack of putting such changes up in such a fashion that a folks in distributed development environment can then adequately plan/protect themselves so *their* stuff is protected is also an issue. Look- if Alexander hadn't said anything, I *probably* wouldn't have noticed. However, he felt that this was important enough to tease people with a 10 minutes until the bombs start falling mail message. It's not unreasonable to raise this as an issue. Or if you think it *is* unreasonable, we can go offline so I can discuss it. -matt On Sun, 1 Sep 2002, Peter Wemm wrote: Matthew Jacob wrote: This would have been a firing offense at several companies I've worked at. It's not unreasonable to take a lesson from *why* these things are firing offenses and start to raise queries. I've done so. Duty is done. Go back to sleep. Would you rather that we ship with a known broken prerelease compiler? Would you rather that we changed from 3.1-prerelease to 3.1.1-release? gcc-3.2 *is* 'gcc-3.1.1 + ABI bugfix'. They renamed the 3.1 branch to 3.2. All future 3.1.x releases will be called 3.2.x. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Matthew Jacob wrote: The point here is that major changes need to be very visible on a product's schedule. You can argue that it isn't a major change- but I'd assert that any toolchain change *is* a major change. re@ have been practically begging for it. I'm *not* arguing against the change- I don't know nearly enough to have an opinion. I *am* commenting on how major changes coming in with little notice often add substantial delays. Furthermore, lack of putting such changes up in such a fashion that a folks in distributed development environment can then adequately plan/protect themselves so *their* stuff is protected is also an issue. Look- if Alexander hadn't said anything, I *probably* wouldn't have noticed. However, he felt that this was important enough to tease people with a 10 minutes until the bombs start falling mail message. It's not unreasonable to raise this as an issue. Umm. Are you reading your -developers mail? === begin quote === Subject: Re: A plea for a 5.0-RELEASE .. From: Alexander Kabaev [EMAIL PROTECTED] Date: Sat, 31 Aug 2002 23:26:09 -0400 (20:26 PDT) To: [EMAIL PROTECTED] On Sat, 31 Aug 2002 20:19:11 -0400 (EDT) Robert Watson [EMAIL PROTECTED] wrote: If we can manage it, we also need a compiler upgrade for the base system. Right now we can't build usable gif support in QT with the base system g++, we have to install a port. I am testing a buildworld with GCC 3.2 after Heimdal upgrade. If nothing goes wrong, I plan to import GCC 3.2 tomorrow. My home machine is running kernel/buildworld compiled with 3.2 already. === end quote === And then there was quite a bit of followup about it. It has already been established that everybody wanted it, and that it has been tested on i386 and alpha, and the sparc64 folks want it very badly too. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, Sep 01, 2002 at 03:23:58PM -0700, David O'Brien wrote: This is the same as using RELENG_4_6 (ie, 4.6-SECURE) in something. We get bug fixes (that must work on *all* supported GCC arches). The risk is _well_ mitigated. Why is everyone second guessing Kan on this import??? It will be a wonder if we get another import done by him. Oh, I think GCC 3.2.1 prerelease knocks the socks off 3.1 prerelease. But any time someone is using a FreeBSD -RELEASE, gcc -v should say release in it. That's just MHO. Part of the reason I say this is because the gcc31 port uses the release version and is not subject to the same bugs that the *prerelease* 3.1 compiler that was in -CURRENT was. regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2.1-pre imported
Great news. Hopefully this means we'll actually be able to ship 5.0 with a working KDE, since the 3.1 gcc we were running with had compiler optimization problems with the gif code. And, as previously discussed, this was a big checkbox item for getting 5.0 in decent shape for the release. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Sun, 1 Sep 2002, Alexander Kabaev wrote: GCC 3.2.1-pre is now in the tree. Please let me know if you see any problems recompiling your world/kernel. Remember to recompile your C++ ports. GCC 3.2 is not binary compatible with 3.1. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Mon, 2 Sep 2002, Martin Blapp wrote: Hi, totally wrong, and this won't break things. I'm just a bit startled that this appears out of nowhere (I sure don't recall it being discussed) and just happens, with 10 minutes warning. The 2.95.3 - 3.1 prerelease upgrade was a big step. 3.1 prerelease - 3.2 is a little step which fixes bugs, make kde working (gif support) again, fixes X11 and mozilla ports. Actually, if 3.2 doesn't use thunks, it's likely to break Mozilla again. This is really not that big of a deal. I'll just need to alter a patch, and update the Mozilla people. Joe I don't mean to be hypercritical here, but I feel that it's fair, considering people are starting to really whine about how late 5.0 actually *is* at this point, to begin to ask not even the *hard* questions, but medium firm questions about gee, is this trip *really* necessary? I think yes. Gcc 3.1 prerelease had some nasty bugs. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Umm. Are you reading your -developers mail? Yes, as best as I can. But I didn't see a GCC 3.2 import on anyone's bullet list. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, 1 Sep 2002 18:52:04 -0400 (EDT) Joe Marcus Clarke [EMAIL PROTECTED] wrote: Actually, if 3.2 doesn't use thunks, it's likely to break Mozilla again. This is really not that big of a deal. I'll just need to alter a patch, and update the Mozilla people. Joe Why would that change? I do not remember me switching thunks off. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, 1 Sep 2002, Alexander Kabaev wrote: On Sun, 1 Sep 2002 18:52:04 -0400 (EDT) Joe Marcus Clarke [EMAIL PROTECTED] wrote: Actually, if 3.2 doesn't use thunks, it's likely to break Mozilla again. This is really not that big of a deal. I'll just need to alter a patch, and update the Mozilla people. Joe Why would that change? I do not remember me switching thunks off. I have no idea if it changed or not. This was just an observation. I'll be testing Mozilla with gcc-3.2.1, and I will fix things as necessary. But thanks for the info. Joe -- Alexander Kabaev PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, Sep 01, 2002 at 03:51:52PM -0700, Matthew Jacob wrote: Umm. Are you reading your -developers mail? Yes, as best as I can. But I didn't see a GCC 3.2 import on anyone's bullet list. To quote Robert Watson: My list basically consists of: General - GEOM as default storage management on all platforms, related dependencies - Switch in sysinstall to easily turn on ufs2 - Final resolution of any perl removal related problems - rcNG as the default boot mechanism - New gcc? Matt, please stop trolling. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Yes, as best as I can. But I didn't see a GCC 3.2 import on anyone's bullet list. To quote Robert Watson: My list basically consists of: General - GEOM as default storage management on all platforms, related dependencies - Switch in sysinstall to easily turn on ufs2 - Final resolution of any perl removal related problems - rcNG as the default boot mechanism - New gcc? Small bullet item. Matt, please stop trolling. That is an offensive assumption. It wasn't trolling- nor was it intended as such. Argh. Why do I bother? Screw it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Sun, Sep 01, 2002 at 12:37:14PM -0700, Lamont Granquist wrote: It sounds like gcc-3.1 or gcc-3.2 will be archaic and buggy by the time that 5.2 and 5.3 come out. How would gcc-3.2 get more buggy over time than it is today?? archaic does apply however. Why the fsck can't people come up to speed on an issue before spewing FUD? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2.1-pre imported
On Sun, Sep 01, 2002 at 05:58:46PM -0400, Alexander Kabaev wrote: GCC 3.2.1-pre is now in the tree. Please let me know if you see any problems recompiling your world/kernel. I have completed a world and kernel, just upgrading all my ports with portupgrade -a -f now, we'll see how that goes. Remember to recompile your C++ ports. GCC 3.2 is not binary compatible with 3.1. If this works out would it be a good idea to get this new gcc version on the port build clusters for -current so we can get to work on making sure all the ports work with the new compiler? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Totally off-topic for this thread, sorry. On Sun, Sep 01, 2002 at 04:58:54PM -0600, Scott Long wrote: To quote Robert Watson: My list basically consists of: General - GEOM as default storage management on all platforms, related dependencies Note: I have tried bringing to -current's attention several times that GEOM and md(4) do not play well together. The following fstab entry continues to fail: /dev/md0 /tmp md rw,nosuid,nodev,-s=32m,-p=1777 0 0 Fyi, -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2.1-pre imported
On Sun, Sep 01, 2002 at 06:33:05PM -0500, David W. Chapman Jr. wrote: Remember to recompile your C++ ports. GCC 3.2 is not binary compatible with 3.1. If this works out would it be a good idea to get this new gcc version on the port build clusters for -current so we can get to work on making sure all the ports work with the new compiler? I'll be doing a new bento run ASAP. Kris msg42414/pgp0.pgp Description: PGP signature
Re: HEADS UP: GCC 3.2.1-pre imported
On Sun, Sep 01, 2002 at 04:46:18PM -0700, Kris Kennaway wrote: On Sun, Sep 01, 2002 at 06:33:05PM -0500, David W. Chapman Jr. wrote: Remember to recompile your C++ ports. GCC 3.2 is not binary compatible with 3.1. If this works out would it be a good idea to get this new gcc version on the port build clusters for -current so we can get to work on making sure all the ports work with the new compiler? I'll be doing a new bento run ASAP. I will look at the logs when its done and see where I can help out. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Matthew Jacob wrote: Yes, as best as I can. But I didn't see a GCC 3.2 import on anyone's bullet list. To quote Robert Watson: My list basically consists of: General - GEOM as default storage management on all platforms, related dependencies - Switch in sysinstall to easily turn on ufs2 - Final resolution of any perl removal related problems - rcNG as the default boot mechanism - New gcc? Small bullet item. Alexander is new at working within our operation so we should give him some room to get fully up to speed. I'm glad that somebody other than me is dealing with this. :-) We really did need this to be done before 5.0-R as the gcc prerelease was a bit of a showstopper when it cannot compile a whole bunch of 'must have' packages. (eg: KDE etc) Lets say that developer awareness of the pending import should have been dealt with better and chalk it up as a learning experience. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Matthew Jacob wrote: Yes, as best as I can. But I didn't see a GCC 3.2 import on anyone's bullet list. To quote Robert Watson: My list basically consists of: General - GEOM as default storage management on all platforms, related dependencies - Switch in sysinstall to easily turn on ufs2 - Final resolution of any perl removal related problems - rcNG as the default boot mechanism - New gcc? Small bullet item. Alexander is new at working within our operation so we should give him some room to get fully up to speed. I'm glad that somebody other than me is dealing with this. :-) We really did need this to be done before 5.0-R as the gcc prerelease was a bit of a showstopper when it cannot compile a whole bunch of 'must have' packages. (eg: KDE etc) Lets say that developer awareness of the pending import should have been dealt with better and chalk it up as a learning experience. Of course. And being accused of 'trolling' is also a learning experience. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Of course. And being accused of 'trolling' is also a learning experience. I would have to agree with your sarcasm, seems like there is a big troll hunt and everyone is being accused. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Hey lets find a way to keep this goddamned thread going.. huh can we... yeah... please... I love hitting delete!!! Keep it up and we'll be as cool as [EMAIL PROTECTED] ... /sarcasm On Sunday, September 1, 2002, at 07:12 PM, Matthew Jacob wrote: Matthew Jacob wrote: Yes, as best as I can. But I didn't see a GCC 3.2 import on anyone's bullet list. To quote Robert Watson: My list basically consists of: General - GEOM as default storage management on all platforms, related dependencies - Switch in sysinstall to easily turn on ufs2 - Final resolution of any perl removal related problems - rcNG as the default boot mechanism - New gcc? Small bullet item. Alexander is new at working within our operation so we should give him some room to get fully up to speed. I'm glad that somebody other than me is dealing with this. :-) We really did need this to be done before 5.0-R as the gcc prerelease was a bit of a showstopper when it cannot compile a whole bunch of 'must have' packages. (eg: KDE etc) Lets say that developer awareness of the pending import should have been dealt with better and chalk it up as a learning experience. Of course. And being accused of 'trolling' is also a learning experience. 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: HEADS UP: GCC 3.2 in progress
On Sunday, September 1, 2002, at 07:14 PM, David W. Chapman Jr. wrote: Of course. And being accused of 'trolling' is also a learning experience. I would have to agree with your sarcasm, seems like there is a big troll hunt and everyone is being accused. I wouldn't call it trolling but I would call it stretching the bounds of being on topic. The accusation was unfair however the amount of exchange on the topic [and off] may have gotten out of hand. This tends to irritate people. Dave -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org 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: HEADS UP: GCC 3.2 in progress
On Sun, Sep 01, 2002 at 05:12:43PM -0700, Matthew Jacob wrote: [...] Of course. And being accused of 'trolling' is also a learning experience. Ok, I apologize for calling you a 'troll'. I certainly didn't mean it in the context of what's going on in other mailing lists, and it probably wasn't appropriate in any context. Please note, hovever, that many of the concerns that you've brought up in this thread have been *heavily* discussed in the public mailing list over the past month. Just two weeks ago there was a heated discussion over whether to import gcc 3.2, or leapfrog it and wait for 3.3. There have been many more discussions like it. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Getting developer previews via cvsup?
I wanted to download via cvsup a snapshot of -current which I had a decent chance of compiling (I need to look at some atacontrol RAID stuff). So I tried to find a -current which had a recent tag, the comment was made that DP2 just got a tag, but even a DP1 tag would do. What should that tag be? Even a date tag would be useful (-current was in pretty good shape as of MM/DD/. Give it a try.), but I can't seem to find *anything* even after Googling for about an hour. Thanks, -a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Getting developer previews via cvsup?
On 2002-09-01 18:43 +, Andrew P. Lentvorski wrote: I wanted to download via cvsup a snapshot of -current which I had a decent chance of compiling (I need to look at some atacontrol RAID stuff). So I tried to find a -current which had a recent tag, the comment was made that DP2 just got a tag, but even a DP1 tag would do. What should that tag be? Even a date tag would be useful (-current was in pretty good shape as of MM/DD/. Give it a try.), but I can't seem to find *anything* even after Googling for about an hour. Thanks, -a IIRC, current was in good shape between August 12-15, 17, 18, 22-24. I'm probably a day or two off on a few but it's a decent guess. A cvsup from about an hour and a half ago is performing fine so far, with the new gcc imported. *Very* smooth transition, FWIW :) -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Getting developer previews via cvsup?
On Sun, Sep 01, 2002 at 06:43:51PM -0700, Andrew P. Lentvorski wrote: I wanted to download via cvsup a snapshot of -current which I had a decent chance of compiling (I need to look at some atacontrol RAID stuff). So I tried to find a -current which had a recent tag, the comment was made that DP2 just got a tag, but even a DP1 tag would do. What should that tag be? Even a date tag would be useful (-current was in pretty good shape as of MM/DD/. Give it a try.), but I can't seem to find *anything* even after Googling for about an hour. There aren't tags for DP1 and DP2 because they are being created in a seperate perforce repository to avoid the overhead of branching for previews. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg42424/pgp0.pgp Description: PGP signature
Re: Getting developer previews via cvsup?
On Sun, Sep 01, 2002 at 06:43:51PM -0700, Andrew P. Lentvorski wrote: I wanted to download via cvsup a snapshot of -current which I had a decent chance of compiling (I need to look at some atacontrol RAID stuff). So I tried to find a -current which had a recent tag, the comment was made that DP2 just got a tag, but even a DP1 tag would do. See several at ftp://snapshots.jp.freebsd.org/pub/FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sun, 1 Sep 2002, Sean Chittenden wrote: totally wrong, and this won't break things. I'm just a bit startled that this appears out of nowhere (I sure don't recall it being discussed) and just happens, with 10 minutes warning. The 2.95.3 - 3.1 prerelease upgrade was a big step. 3.1 prerelease - 3.2 is a little step which fixes bugs, make kde working (gif support) again, fixes X11 and mozilla ports. Actually, if 3.2 doesn't use thunks, it's likely to break Mozilla again. This is really not that big of a deal. I'll just need to alter a patch, and update the Mozilla people. My understanding from watching the patches move through mozilla is that the next release of mozilla _will_ work correctly with -CURRENT because it is aware of us not using thunks. The thunks patch for -CURRENT was verified in the mozilla src tree a week or two back. -sc Correct. However, if the compiler changes in -CURRENT not to use thunks, then I need to adjust the local patch, and update the Mozilla bug. However, it sounds like this isn't the case. Joe -- Sean Chittenden PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problem in cross-build of modules
This showed up a few days ago; a tool-dependency problem in a cross-build. I build current under stable since this (acpi-only) system won't yet boot current (mostly appears to be the problem with TI pcic/cardbus chip interrupt routing) The build of aicasm in the kernel mkdep works right; that in the module build doesn't. I presume a minor makefile problem... The first thing (no target to make) is just a nit but annoying. make: no target to make. /current/usr/src/Makefile.inc1, line 140: warning: make -f /dev/null -m /current/usr/src/share/mk CPUTYPE=i386 -V CPUTYPE returned non-zero status -- Kernel build for PORT2 started on Sun Sep 1 22:36:09 EDT 2002 -- === PORT2 mkdir -p /usr/obj/current/usr/src/sys cd /current/usr/src/sys/i386/conf; PATH=/usr/obj/current/usr/src/i386/usr/sbin:/usr/obj/current/usr/src/i386/usr/bin:/usr/obj/current/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/current/usr/src/sys/PORT2 /current/usr/src/sys/i386/conf/PORT2 Kernel build directory is /usr/obj/current/usr/src/sys/PORT2 Don't forget to do a ``make depend'' . . cd /usr/obj/current/usr/src/sys/PORT2; MAKESRCPATH=/current/usr/src/sys/dev/aic7xxx/aicasm make -DNO_CPU_CFLAGS -f /current/usr/src/sys/dev/aic7xxx/aicasm/Makefile Warning: Object directory not changed from original /d/obj-c/current/usr/src/sys/PORT2 cc -O -pipe -nostdinc -I/usr/include -I. -I/current/usr/src/sys/dev/aic7xxx/aicasm -c /current/usr/src/sys/dev/aic7xxx/aicasm/aicasm.c cc -O -pipe -nostdinc -I/usr/include -I. -I/current/usr/src/sys/dev/aic7xxx/aicasm -c /current/usr/src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c yacc -b aicasm_gram -d -o aicasm_gram.c /current/usr/src/sys/dev/aic7xxx/aicasm/aicasm_gram.y cc -O -pipe -nostdinc -I/usr/include -I. -I/current/usr/src/sys/dev/aic7xxx/aicasm -c aicasm_gram.c yacc -b aicasm_macro_gram -p mm -d -o aicasm_macro_gram.c /current/usr/src/sys/dev/aic7xxx/aicasm/aicasm_macro_gram.y cc -O -pipe -nostdinc -I/usr/include -I. -I/current/usr/src/sys/dev/aic7xxx/aicasm -c aicasm_macro_gram.c lex -t /current/usr/src/sys/dev/aic7xxx/aicasm/aicasm_scan.l aicasm_scan.c cc -O -pipe -nostdinc -I/usr/include -I. -I/current/usr/src/sys/dev/aic7xxx/aicasm -c aicasm_scan.c lex -t -Pmm /current/usr/src/sys/dev/aic7xxx/aicasm/aicasm_macro_scan.l aicasm_macro_scan.c cc -O -pipe -nostdinc -I/usr/include -I. -I/current/usr/src/sys/dev/aic7xxx/aicasm -c aicasm_macro_scan.c cc -O -pipe -nostdinc -I/usr/include -I. -I/current/usr/src/sys/dev/aic7xxx/aicasm -o aicasm aicasm.o aicasm_symbol.o aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll cd /usr/obj/current/usr/src/sys/PORT2; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=i386 OBJFORMAT_PATH=/usr/obj/current/usr/src/i386/usr/libexec GROFF_BIN_PATH=/usr/obj/current/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/current/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/current/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/current/usr/src/i386 INSTALL=sh /current/usr/src/tools/install.sh PATH=/usr/obj/current/usr/src/i386/usr/sbin:/usr/obj/current/usr/src/i386/usr/bin:/usr/obj/current/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin OBJFORMAT_PATH=/usr/obj/current/usr/src/i386/usr/libexec:/usr/libexec make KERNEL=kernel depend rm -f .olddep if [ -f .depend ]; then mv .depend .olddep; fi make _kernel-depend ... ... === aic7xxx === aic7xxx/aicasm make -f /current/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/Makefile MAKESRCPATH=/current/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm depend === aic7xxx/ahc @ - /current/usr/src/sys machine - /current/usr/src/sys/i386/include ( cd /current/usr/src/sys/modules/aic7xxx/ahc/../aicasm; make aicasm; ) make -f /current/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/Makefile MAKESRCPATH=/current/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm Warning: Object directory not changed from original /d/obj-c/current/usr/src/sys/PORT2/modules/current/usr/src/sys/modules/aic7xxx/aicasm cc -O -pipe -nostdinc -I/usr/include -I. -I/current/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -g -c /current/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm.c cc -O -pipe -nostdinc -I/usr/include -I. -I/current/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -g -c /current/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c yacc -b aicasm_gram -d -o aicasm_gram.c /current/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_gram.y cc -O -pipe -nostdinc -I/usr/include -I.
Re: Problem in cross-build of modules
On Sun, Sep 01, 2002 at 07:51:19PM -0700, Pete Carah wrote: This showed up a few days ago; a tool-dependency problem in a cross-build. I build current under stable since this (acpi-only) system won't yet boot current (mostly appears to be the problem with TI pcic/cardbus chip interrupt routing) The build of aicasm in the kernel mkdep works right; that in the module build doesn't. I presume a minor makefile problem... The first thing (no target to make) is just a nit but annoying. [...] /usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found I'm aware of this. I still haven't figured out the cause though, and my -stable machine is horribly slow. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
totally wrong, and this won't break things. I'm just a bit startled that this appears out of nowhere (I sure don't recall it being discussed) and just happens, with 10 minutes warning. The 2.95.3 - 3.1 prerelease upgrade was a big step. 3.1 prerelease - 3.2 is a little step which fixes bugs, make kde working (gif support) again, fixes X11 and mozilla ports. Actually, if 3.2 doesn't use thunks, it's likely to break Mozilla again. This is really not that big of a deal. I'll just need to alter a patch, and update the Mozilla people. My understanding from watching the patches move through mozilla is that the next release of mozilla _will_ work correctly with -CURRENT because it is aware of us not using thunks. The thunks patch for -CURRENT was verified in the mozilla src tree a week or two back. -sc -- Sean Chittenden msg42429/pgp0.pgp Description: PGP signature
aout support broken in gcc3
aout support is still required for a few things (mainly for compiling
some boot blocks), but is broken in gcc3 for at least compile-time
assignments to long longs and shifts of long longs by a non-constant
amount:
%%%
$ cat z.c
long long x = 0;
int y;
foo()
{
x = x y;
}
$ cc -O -S -aout z.c
$ cat z.s
.file z.c
.globl _x
.data
.p2align 3
.type _x,@object
.size _x,8
_x:
.quad 0
.text
.p2align 2,0x90
.globl _foo
.type _foo,@function
_foo:
pushl %ebp
movl%esp, %ebp
movb_y, %cl
movl_x, %eax
movl_x+4, %edx
shldl %eax, %edx
sall%cl, %eax
testl $32, %ecx
je L2
movl%eax, %edx
movl$0, %eax
L2:
movl%eax, _x
movl%edx, _x+4
leave
ret
Lfe1:
.size _foo,Lfe1-_foo
.comm_y,4
.ident GCC: (GNU) 3.1 [FreeBSD] 20020509 (prerelease)
%%%
The above assembler output has two syntax errors:
- .quad 0. .quad is not supported by the old aout assembler.
- shldl %eax, %edx. The old aout assembler only accepts the correct
syntax of shldl %cl,%eax,%edx. Note that gcc doesn't elide the
similarly implicit %cl register for the sall instruction.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
David O'Brien wrote: It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. 3.3.0 will be released before FreeBSD 5.1. It is my advice to FreeBSD'ville that we go with a GCC 3.3 snapshot for FBSD 5.0 and a GCC 3.3.0 release for FBSD 5.1. That way we can get the new features of 3.3 into our 5.x branch. AND get bug fixes by importing 3.3.1 and 3.3.2 into later FBSD 5.x releases. This would be my preference, but it would be stupid for me to try to volunteer someone else to do the work. IMO, FreeBSD 5.0 will not be able to gain market acceptance until the 5.1 release, in any case. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
Lamont Granquist wrote: 5.0 will be a beta and will not be ready for production use right? No. But no one will use it anyway, because no one trusts a .0 version of anything. I'm not sure exactly how FreeBSD would be pulling a redhat by putting in a development snapshot if the 5.0 release is clearly labelled for non-production use only... It won't be labelled that way. That's what the -DP versions and the -RC versions are for. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Thank you. Let's move on. On Sun, 1 Sep 2002, Scott Long wrote: On Sun, Sep 01, 2002 at 05:12:43PM -0700, Matthew Jacob wrote: [...] Of course. And being accused of 'trolling' is also a learning experience. Ok, I apologize for calling you a 'troll'. I certainly didn't mean it in the context of what's going on in other mailing lists, and it probably wasn't appropriate in any context. Please note, hovever, that many of the concerns that you've brought up in this thread have been *heavily* discussed in the public mailing list over the past month. Just two weeks ago there was a heated discussion over whether to import gcc 3.2, or leapfrog it and wait for 3.3. There have been many more discussions like it. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
