Re: GCC3.1 internal compiler error when compilingXFree86-4-libraries
you replace #pragma weak foo = bar with either #pragma weak foo = bar /* this is easier */ or if __GNUC__ = 3 int foo() __attribute__ ((weak, alias (bar))); #endif /* __GNUC__ */ . I tried the quotation mark fix, and all it does is change the error message to UIThrStubs.c:102: warning: malformed #pragma weak, ignored UIThrStubs.c:103: warning: malformed #pragma weak, ignored UIThrStubs.c:104: warning: malformed #pragma weak, ignored UIThrStubs.c:105: warning: malformed #pragma weak, ignored UIThrStubs.c:106: warning: malformed #pragma weak, ignored UIThrStubs.c:107: warning: malformed #pragma weak, ignored UIThrStubs.c:108: warning: malformed #pragma weak, ignored UIThrStubs.c:109: warning: malformed #pragma weak, ignored UIThrStubs.c:110: warning: malformed #pragma weak, ignored UIThrStubs.c:111: warning: malformed #pragma weak, ignored UIThrStubs.c:113: warning: malformed #pragma weak, ignored UIThrStubs.c:114: warning: malformed #pragma weak, ignored UIThrStubs.c:115: warning: malformed #pragma weak, ignored UIThrStubs.c:131: warning: `_Xthr_self_stub_' defined but not used UIThrStubs.c:139: warning: `_Xthr_zero_stub_' defined but not used which doesn't really seem to be a solution. -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 2L, UST School of Law Minneapolis, Minnesota There are things that are so serious that you can only joke about them. -- Werner Heisenberg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
current.freebsd.org
I have been trying for several days now to access current.freebsd.org so I can get the latest -CURRENT snapshot instead of my usual DP1 - cvsup - buildworld, but I am unable to get in.. Is this not a public server? saturn# ftp current.freebsd.org Connected to usw2.freebsd.org. 220 usw2.freebsd.org FTP server (Version 6.00LS) ready. Name (current.freebsd.org:sturdee): ftp 331 Guest login ok, send your email address as password. Password: 550 Can't set guest privileges. ftp: Login failed. ftp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
Hi, Michael D. Harnois [EMAIL PROTECTED] wrote: if __GNUC__ = 3 int foo() __attribute__ ((weak, alias (bar))); #endif /* __GNUC__ */ . I tried the quotation mark fix, and all it does is change the error message to UIThrStubs.c:102: warning: malformed #pragma weak, ignored [snip] UIThrStubs.c:139: warning: `_Xthr_zero_stub_' defined but not used which doesn't really seem to be a solution. Please try the following patch. -- Motoyuki Konno [EMAIL PROTECTED] (Home) [EMAIL PROTECTED] (FreeBSD Project) http://www.freebsd.org/~motoyuki/ (WWW) --- lib/XThrStub/UIThrStubs.c.old Mon Nov 19 06:13:26 2001 +++ lib/XThrStub/UIThrStubs.c Tue Jun 4 11:39:19 2002 @@ -99,6 +99,21 @@ #else #include pthread.h typedef pthread_t xthread_t; +#if __GNUC__ = 3 +xthread_t pthread_self()__attribute__ ((weak, alias (_Xthr_self_stub_))); +int pthread_mutex_init()__attribute__ ((weak, alias (_Xthr_zero_stub_))); +int pthread_mutex_destroy() __attribute__ ((weak, alias (_Xthr_zero_stub_))); +int pthread_mutex_lock()__attribute__ ((weak, alias (_Xthr_zero_stub_))); +int pthread_mutex_unlock() __attribute__ ((weak, alias (_Xthr_zero_stub_))); +int pthread_cond_init() __attribute__ ((weak, alias (_Xthr_zero_stub_))); +int pthread_cond_destroy() __attribute__ ((weak, alias (_Xthr_zero_stub_))); +int pthread_cond_wait() __attribute__ ((weak, alias (_Xthr_zero_stub_))); +int pthread_cond_signal() __attribute__ ((weak, alias (_Xthr_zero_stub_))); +int pthread_cond_broadcast() __attribute__ ((weak, alias (_Xthr_zero_stub_))); +int pthread_key_create()__attribute__ ((weak, alias (_Xthr_zero_stub_))); +void *pthread_getspecific() __attribute__ ((weak, alias (_Xthr_zero_stub_))); +int pthread_setspecific() __attribute__ ((weak, alias (_Xthr_zero_stub_))); +#else /* __GNUC__ */ #pragma weak pthread_self = _Xthr_self_stub_ #pragma weak pthread_mutex_init = _Xthr_zero_stub_ #pragma weak pthread_mutex_destroy = _Xthr_zero_stub_ @@ -113,6 +128,7 @@ #pragma weak pthread_key_create = _Xthr_zero_stub_ #pragma weak pthread_getspecific = _Xthr_zero_stub_ #pragma weak pthread_setspecific = _Xthr_zero_stub_ +#endif /* __GNUC__ */ #if defined(_DECTHREADS_) || defined(linux) #pragma weak pthread_equal = _Xthr_equal_stub_ /* See Xthreads.h! */ int
Re: current.freebsd.org
On Tue, Jun 04, 2002 at 08:39:41AM -0400, Mike wrote: Hi, I have been trying for several days now to access current.freebsd.org so I can get the latest -CURRENT snapshot instead of my usual DP1 - cvsup - buildworld, but I am unable to get in.. Is this not a public server? There seems to be some problems with that server, you can use snapshots.jp.freebsd.org in the meantime. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg39152/pgp0.pgp Description: PGP signature
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
On Tue, Jun 04, 2002 at 07:08:32AM -0500, Michael D. Harnois wrote: #pragma weak foo = bar with either #pragma weak foo = bar /* this is easier */ snip/ I tried the quotation mark fix, and all it does is change the error message to UIThrStubs.c:102: warning: malformed #pragma weak, ignored snip/ which doesn't really seem to be a solution. are you sure that you're with the right gcc? mine compiles this fine. but regardless which one I use (__attribute__ or the quotation), later on the process i get the internal compiler error in Mesa. not that I think the two are related, though. -tacho -- [a lie is my shield] | [http://daemonz.org/ || [EMAIL PROTECTED]] 0x44fc3339 || [02b5 798b 4bd1 97fb f8db 72e4 dca4 be03 44fc 3339] msg39153/pgp0.pgp Description: PGP signature
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
On Tue, 4 Jun 2002, Stanislav Grozev wrote: On Tue, Jun 04, 2002 at 07:08:32AM -0500, Michael D. Harnois wrote: #pragma weak foo = bar with either #pragma weak foo = bar /* this is easier */ snip/ I tried the quotation mark fix, and all it does is change the error message to UIThrStubs.c:102: warning: malformed #pragma weak, ignored snip/ which doesn't really seem to be a solution. are you sure that you're with the right gcc? mine compiles this fine. but regardless which one I use (__attribute__ or the quotation), later on the process i get the internal compiler error in Mesa. not that I think the two are related, though. I tried here too, latest GCC in 5.0-CURRENT from this weekend, and get the same 'ignored' stuff, after which it does continue onto the Mesa where it does fail ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
The -current state of mozilla affairs
The kind of compile errors for mozilla have been changing as the C++ problems get fixed. Today's error is one I haven't seen before--a core dump. Does this suggest a non-c++ problem that needs fixing? Sorry about the line-wrap: I put extra CR's where the linebreaks are. gmake[1]: Leaving directory `/usr/ports/www/mozilla/work/mozilla' /usr/bin/sed -e s;@PREFIX@;/usr/X11R6;g /usr/ports/www/mozilla/files/mozilla.sh /usr/ports/www/mozilla/work/mozilla/mozilla (cd /usr/ports/www/mozilla/work/mozilla/dist/bin; /usr/bin/env LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regxpcom; echo skin,install,select,classic/1.0 chrome/installed- chrome.txt; echo locale,install,select,en-US chrome/installed-chrome.txt; /usr/bin/env LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regchrome) [1] Segmentation fault (core dumped) *** Error code 139 Stop in /usr/ports/www/mozilla. ** Command failed: make To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make buildkernel problem
I've been running into this problem for the past few days where make
buildkernel fails. I've cvs'd multiple times hoping it would get cleared
up...any ideas?
-Troy
=== xe
@ - /usr/src/sys
machine - /usr/src/sys/i386/include
awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h
awk -f @/tools/makeobjops.awk @/dev/pccard/card_if.m -h
awk -f @/tools/makeobjops.awk @/kern/device_if.m -h
rm -f .depend
CC='/usr/bin/cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I.
-I@ -I@/dev -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/mod
ules/xe/../../dev/xe/if_xe.c /usr/src/sys/modules/xe/../../dev/xe/if_xe_pccard.c
cd /usr/obj/usr/src/sys/SINDROME; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386
MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec GROFF_BIN_PATH=
/usr/obj/usr/src/i386/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386
INSTALL=sh /usr/src/tools/install.sh
PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
OBJFORMAT_PATH=/usr/obj/usr/src/i386/-mpreferred-stack-boundary=2 -ffreestanding
-Werror /usr/src/sys/i386/i386/locore.s
{standard input}: Assembler messages:
{standard input}:1684: Warning: rest of line ignored; first ignored character
is `t'
{standard input}:1686: Error: unknown pseudo-op: `.'
{standard input}:1801: Error: missing ')'
{standard input}:1801: Error: missing ')'
{standard input}:1801: Error: junk `tmpstk)- 0xc000)' after expression
*** Error code 1
Stop in /usr/obj/usr/src/sys/SINDROME.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sh and job control
Can anyone else reproduce this problem? There seems to be a problem with job control in the shell or the kernel's notion of a 'foreground' process. I'm inclined to blame my modifications to the job control code, but I can reproduce the problem with a checkout from May 10, before I changed it. %cvs -z9 co -D10 May sh [snip] %cd sh %vi Makefile [use /usr/src/bin/test instead of a relative path] %make [snip] %obj/sh $ groff -Tascii -mdoc sh.1 | less Stopped (tty output) Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
tar breaks world [June 04]
=== gnu/usr.bin/tar .depend, line 458: Inconsistent operator for tar make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/gnu/usr.bin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tar breaks world [June 04]
Date: Tue, 04 Jun 2002 00:12:28 -0700 From: walt [EMAIL PROTECTED] === gnu/usr.bin/tar .depend, line 458: Inconsistent operator for tar make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/gnu/usr.bin. Well, I've finished the make buildworld for today's -CURRENT, and am in the make kernel phase, so whatever bit you doesn't seem to ahve got to me. Here's my environment: freebeast(5.0-C)[1] uname -a tail /var/log/cvsup-history.log grep -v '^#' /etc/make.conf FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #13: Mon Jun 3 07:20:40 PDT 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386 Jun 1 00:00:00 freebeast newsyslog[395]: logfile turned over CVSup begin from cvsup14.freebsd.org at Sat Jun 1 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Sat Jun 1 03:55:02 PDT 2002 CVSup begin from cvsup14.freebsd.org at Sun Jun 2 03:47:03 PDT 2002 CVSup ended from cvsup14.freebsd.org at Sun Jun 2 03:53:46 PDT 2002 CVSup begin from cvsup14.freebsd.org at Mon Jun 3 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Mon Jun 3 03:53:59 PDT 2002 CVSup begin from cvsup14.freebsd.org at Tue Jun 4 03:47:03 PDT 2002 CVSup ended from cvsup14.freebsd.org at Tue Jun 4 03:53:52 PDT 2002 CFLAGS= -O -pipe COPTFLAGS= -O -pipe COMPAT22= yes COMPAT3X= yes COMPAT4X= yes PRINTERDEVICE= ps FORCE_PKG_REGISTER= YES WITH_PNG_MMX=YES SENDMAIL_MC=/etc/mail/client.mc freebeast(5.0-C)[2] Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] Trying to support or use Microsoft products makes about as much sense as painting a house with watercolors. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tar breaks world [June 04]
=== gnu/usr.bin/tar .depend, line 458: Inconsistent operator for tar make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/gnu/usr.bin. Well, I've finished the make buildworld for today's -CURRENT, and am in the make kernel phase, so whatever bit you doesn't seem to ahve got to me. Hmm, the .depend should've given me the clue. I deleted /usr/obj/usr/src/gnu/usr.bin/tar/* and all is well. I thought make buildworld takes care of stuff like that :-/ Now that I think of it I'll just delete /usr/obj and start over, just in case. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: State of the ports collection
What's going to happen to all these ports that still depend on file locations in the 4.5 release(s)? The reason I ask is that I see that now we're going to have to make two kinds of ports - one for 4.x and one for 5.x, or are header files and stuff like that stored as global variables... or something. Kris Kennaway talked a bit about moving specific headers (and possibly more) to different locations: :: * (27 ports) The machine/soundcard.h header was moved, breaking :: * (35 ports) Something caused sys_nerr to change prototypes. It looks like this might be because the definition of __const from sys/ctypes.h has changed, but I can't see why. See for example I don't know, it was just something that concerned me. I'd hate to see version-specific ports, and I'm hoping it doesn't come down to that. - dt - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: State of the ports collection
In the last episode (Jun 04), Dan Trainor said: What's going to happen to all these ports that still depend on file locations in the 4.5 release(s)? The reason I ask is that I see that now we're going to have to make two kinds of ports - one for 4.x and one for 5.x, or are header files and stuff like that stored as global variables... or something. Kris Kennaway talked a bit about moving specific headers (and possibly more) to different locations: :: * (27 ports) The machine/soundcard.h header was moved, breaking The move from machine/soundcard.h to sys/soundcard.h was done in 1999 as part of the move from 3.* to 4.0. All 4.* systems have sys/soundcard.h, and that's where ports should be looking. :: * (35 ports) Something caused sys_nerr to change prototypes. It looks like this might be because the definition of __const from sys/ctypes.h has changed, but I can't see why. See for example This is an error that gcc 2.95 never caught that gcc 3 does. Ports should not use sys_nerr at all, and should use strerror(). -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: State of the ports collection
Kris Kennaway [EMAIL PROTECTED] wrote: It seems like ports committers are not able to keep up with the rate at which ports are being broken by -current changes: Since I originally stated that I would work on fixing ports on alpha and I have clearly failed to do so, I would like to point out that I have a hard time simply keeping up with the rate of disruptive changes and breakage in the -CURRENT base system. Also, either there aren't enough HEAD UPs or I keep missing them. (E.g., do we have a working C++ compiler again?) I suspect that by far most port maintainers only run -STABLE and are simply unaware of the the changes happening in -CURRENT. -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updating GNU Tar in the base system
On Tue, 4 Jun 2002 13:36:17 +1000, Tim J. Robbins [EMAIL PROTECTED] said: Having two tar's, two cpio's, two awk's, gzip and zlib in the base system is bloat. It may be bloat, but it's tolerable bloat that our users are well-accustomed to. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[HEADS-UP] GNU Tar was updated
Folks, I've updated GNU Tar in the base system to the most recent version. I've tested it locally and it appears to OK, but if you have any unusual problems with it please let me know. Thanks! -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: State of the ports collection
On Tue, 4 Jun 2002, Dan Trainor wrote: What's going to happen to all these ports that still depend on file locations in the 4.5 release(s)? The reason I ask is that I see that now we're going to have to make two kinds of ports - one for 4.x and one for 5.x, or are header files and stuff like that stored as global variables... or something. Kris Kennaway talked a bit about moving specific headers (and possibly more) to different locations: :: * (27 ports) The machine/soundcard.h header was moved, breaking :: * (35 ports) Something caused sys_nerr to change prototypes. It looks like this might be because the definition of __const from sys/ctypes.h has changed, but I can't see why. See for example I don't know, it was just something that concerned me. I'd hate to see version-specific ports, and I'm hoping it doesn't come down to that. - dt - [EMAIL PROTECTED] The soundcard.h problem is solved very easily in ports that do something like this: #ifdef __FreeBSD__ #include machine/soundcard.h #else #include sys/soundcard.h #endif just change the #ifdef __FreeBSD__ to #if __FreeBSD__ = 4 All that happened was that a symlink that was present before from sys/soundcard.h to machine/soundcard.h (that had been there for close to 2 years) was removed. prior to that it was at machine/soundcard.h? I'm not sure. -Trish -- Trish Lynch [EMAIL PROTECTED] FreeBSD The Power to Serve Ecartis Core Team [EMAIL PROTECTED] http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: memset() broken in gcc-3.1 on i386's
On Tue, Jun 04, 2002 at 03:02:21AM +, [EMAIL PROTECTED] wrote:
Actually, it broke fsck_ffs.
Workaround to avoid the known broken case:
The brokenness in ix86_expand_clrstr is quite visible when you
compare the function with ix86_expand_movstr.
Fixed in rev 1.368.2.10. * i386.c (expand_movstr, expand_clrstr): Fix
inline-all-stringops sequence.
But their fix is a little different from yours:
Index: i386.c
===
RCS file: /cvs/gcc/egcs/gcc/config/i386/i386.c,v
retrieving revision 1.368.2.9
retrieving revision 1.368.2.10
diff -u -r1.368.2.9 -r1.368.2.10
--- i386.c 23 Apr 2002 08:11:22 - 1.368.2.9
+++ i386.c 22 May 2002 12:23:53 - 1.368.2.10
@@ -7959,6 +7959,10 @@
GET_CODE (ix86_compare_op1) == CONST_INT
mode != HImode
(unsigned int) INTVAL (ix86_compare_op1) != 0x
+ /* The operand still must be representable as sign extended value. */
+ (!TARGET_64BIT
+ || GET_MODE (ix86_compare_op0) != DImode
+ || (unsigned int) INTVAL (ix86_compare_op1) != 0x7fff)
GET_CODE (operands[2]) == CONST_INT
GET_CODE (operands[3]) == CONST_INT)
{
@@ -9130,6 +9134,9 @@
{
rtx countreg2;
rtx label = NULL;
+ int desired_alignment = (TARGET_PENTIUMPRO
+ (count == 0 || count = (unsigned int) 260)
+ ? 8 : UNITS_PER_WORD);
/* In case we don't know anything about the alignment, default to
library version, since it is usually equally fast and result in
@@ -9159,10 +9166,7 @@
This is quite costy. Maybe we can revisit this decision later or
add some customizability to this code. */
- if (count == 0
- align (TARGET_PENTIUMPRO (count == 0
- || count = (unsigned int) 260)
- ? 8 : UNITS_PER_WORD))
+ if (count == 0 align desired_alignment)
{
label = gen_label_rtx ();
emit_cmp_and_jump_insns (countreg, GEN_INT (UNITS_PER_WORD - 1),
@@ -9184,10 +9188,7 @@
emit_label (label);
LABEL_NUSES (label) = 1;
}
- if (align = 4
- ((TARGET_PENTIUMPRO (count == 0
-|| count = (unsigned int) 260))
- || TARGET_64BIT))
+ if (align = 4 desired_alignment 4)
{
rtx label = ix86_expand_aligntest (destreg, 4);
emit_insn (gen_strmovsi (destreg, srcreg));
@@ -9196,6 +9197,12 @@
LABEL_NUSES (label) = 1;
}
+ if (label desired_alignment 4 !TARGET_64BIT)
+ {
+ emit_label (label);
+ LABEL_NUSES (label) = 1;
+ label = NULL_RTX;
+ }
if (!TARGET_SINGLE_STRINGOP)
emit_insn (gen_cld ());
if (TARGET_64BIT)
@@ -9341,6 +9348,10 @@
{
rtx countreg2;
rtx label = NULL;
+ /* Compute desired alignment of the string operation. */
+ int desired_alignment = (TARGET_PENTIUMPRO
+ (count == 0 || count = (unsigned int) 260)
+ ? 8 : UNITS_PER_WORD);
/* In case we don't know anything about the alignment, default to
library version, since it is usually equally fast and result in
@@ -9355,13 +9366,10 @@
countreg = copy_to_mode_reg (counter_mode, count_exp);
zeroreg = copy_to_mode_reg (Pmode, const0_rtx);
- if (count == 0
- align (TARGET_PENTIUMPRO (count == 0
- || count = (unsigned int) 260)
- ? 8 : UNITS_PER_WORD))
+ if (count == 0 align desired_alignment)
{
label = gen_label_rtx ();
- emit_cmp_and_jump_insns (countreg, GEN_INT (UNITS_PER_WORD - 1),
+ emit_cmp_and_jump_insns (countreg, GEN_INT (desired_alignment - 1),
LEU, 0, counter_mode, 1, label);
}
if (align = 1)
@@ -9382,8 +9390,7 @@
emit_label (label);
LABEL_NUSES (label) = 1;
}
- if (align = 4 TARGET_PENTIUMPRO (count == 0
- || count = (unsigned int) 260))
+ if (align = 4 desired_alignment 4)
{
rtx label = ix86_expand_aligntest (destreg, 4);
emit_insn (gen_strsetsi (destreg, (TARGET_64BIT
@@ -9394,6 +9401,13 @@
LABEL_NUSES (label) = 1;
}
+ if (label desired_alignment 4 !TARGET_64BIT)
+ {
+ emit_label (label);
+ LABEL_NUSES (label) = 1;
+ label = NULL_RTX;
+ }
+
if (!TARGET_SINGLE_STRINGOP)
emit_insn (gen_cld ());
if (TARGET_64BIT)
@@ -9409,18 +9423,18 @@
emit_insn (gen_rep_stossi (destreg, countreg2, zeroreg,
destreg, countreg2));
}
-
if (label)
{
Re: Updating GNU Tar in the base system
On Mon, Jun 03, 2002 at 10:56:58PM +0300, Maxim Sobolev wrote: However, before proceeding I would like to get an advice with regard to the most appropriate procedure for doing the upgrade. The problem is that old version of tar was just cvs add'ed, not imported, so that it is unclear how to to do it. Main questions: Thank you for giving only _1_ day for feedback. (yes, this is said with extreme sarcasm) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
negative time FreeBSD 5.0
Hi, Recently I updated my FreeBSD box to 5.0 I face problems connected with you new time counter code.Could you please tell me how to fix this problem, in old version was able to hack kern_clock.c (NTIMERCOUNTER). calcru: negative time of -661363 usec for pid 157 (ps) calcru: negative time of -681221 usec for pid 159 (ls) calcru: negative time of -673242 usec for pid 166 (jot) Every time when I start a command I got a message like above. Thank you in advance Antoan Miroslavov (CCNP) __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
Hello, For what it's worth, I set out and successfully compiled the latest from the XFree86 CVS with the latest gcc31 snapshot (May 27th). I needed to do the following: - I had to apply the fix that has been mentioned several times on this list to libXThrStub. - I had to fix a typo in one header file under xc/programs/Xserver/PEX5/ddpex/mi/include/miStruct.h in a prperocessor statement - I applied the patch-ioctl from ports/x11/XFree86-4-libraries (alternatively, you could disable the drm part), also I applied the patch-startx from the same place because I wanted consistent behaviour of startx from what I was used to. There was (after these) a bunch of problems that I worked around with hacks: - There was one file, xc/lib/X11/lcUTF8.c which the gcc from ports did not like. It produced an internal compiler error like this: LD_LIBRARY_PATH=../../exports/lib /usr/local/bin/gcc31 -c -ansi -pedantic -Dasm= __asm -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-d eclarations -Wredundant-decls -Wnested-externs -Wundef -pthread -I../.. -I../. ./exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_RE ENTRANT -D_THREAD_SAFE -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DMALLOC_0_RETUR NS_NULL -DHAS_SNPRINTF -DLIBX11 -O -pipe -march=pentiumpro lcUTF8.c -o unshared/lcUTF8.o lcUTF8.c: In function `charset_wctocs': lcUTF8.c:582: unrecognizable insn: (insn 251 70 252 (set (reg:CC 17 flags) (compare:CC (mem:QI (reg/v/f:SI 63) [0 S1 A8]) (const_int 128 [0x80]))) -1 (nil) (expr_list:REG_DEAD (reg/v/f:SI 63) (nil))) lcUTF8.c:582: Internal compiler error in extract_insn, at recog.c:2132 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. *** Error code 1 (continuing) (Sorry for cutpaste) However, when I compiled this only one file with the base system gcc, it worked and linked. - In xc/programs/glxinfo/Makefile, I had to manually define the path to the libstdc++.a in /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1.1/ because otherwise it was not found. (I suspect this is because it uses the gcc31 frontend, not g++31.) After this, I now have a new X that appears to work at first sight. I somehow managed to mess it up though because now it seems to ignore the Xwrapper port although I have it installed and so only works if I make the X server suid root. But it is probably me... Also, stability remains to be seen, since the original reason for upgrading was that 4.2.0 was regularly freezing with my Virge GX2 card, and supposedly some fixes were prepared for this problem... we'll see. This is just an FYI for all having problems with X building now. Note: I did not try the base system compiler for building yet, apart from that quick hack indicated above. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The -current state of mozilla affairs
On Mon, Jun 03, 2002 at 11:04:58PM -0700, walt wrote: The kind of compile errors for mozilla have been changing as the C++ problems get fixed. Today's error is one I haven't seen before--a core dump. Does this suggest a non-c++ problem that needs fixing? Sorry about the line-wrap: I put extra CR's where the linebreaks are. I'm seeing this on one of my 4.x i386 boxes and on the (4.x) alpha ports cluster. When I try and compile mozilla with -ggdb to get a traceback I get an internal compiler error :-( Kris msg39171/pgp0.pgp Description: PGP signature
Re: tar breaks world [June 04]
On Tue, Jun 04, 2002 at 12:12:28AM -0700, walt wrote: === gnu/usr.bin/tar .depend, line 458: Inconsistent operator for tar make: fatal errors encountered -- cannot continue *** Error code 1 The problem is you have an existing /usr/obj/gnu/usr.bin/tar/.depend file. In that file is a dependancy list for tar. BUT tar is now a directory. There was no reason for sobomax to get so fancy with this -- and this is one case in point of the things that can go wrong. I have a fix for this; but I am waiting to hear back from sobomax before I commit it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updating GNU Tar in the base system
On Tue, Jun 04, 2002 at 01:36:17PM +1000, Tim J. Robbins wrote: I am in favour of doing this. Same with cpio. I'd prefer to see GNU tar and cpio in ports (if they are not already there). We have had GNU tar just too long to move it to ports. Nothing else has the same options or support. Having two tar's, two cpio's, two awk's, gzip and zlib in the base system is bloat. We don't have two tars. The awk I'll fix right now. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: State of the ports collection
On Mon, Jun 03, 2002 at 01:42:24PM -0700, Kris Kennaway wrote: * (lots of ports) The new C++ compiler deprecated a lot of headers by moving them to a different directory: this breaks a heck of a lot of ports). IMO we should be searching this directory by default. example port please. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
I can not compile the kernel
Hello, see this:
--
root@juanillo:/usr/src/sys/i386/compile/JUANILLO $ make
cc -c -x assembler-with-cpp -DLOCORE -O -pipe -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I.
-I../../.. -I../../../dev -I../../../contrib/dev/acpica
-I../../../contrib/ipfilter -I../../../../include -D_KERNEL
-ffreestanding -include opt_global.h -fno-common
-mpreferred-stack-boundary=2 -Werror ../../../i386/i386/locore.s
{standard input}: Assembler messages:
{standard input}:1689: Warning: rest of line ignored; first ignored
character is `t'
{standard input}:1691: Error: unknown pseudo-op: `.'
{standard input}:1806: Error: missing ')'
{standard input}:1806: Error: missing ')'
{standard input}:1806: Error: junk `tmpstk)- 0xc000)' after expression
*** Error code 1
Stop in /usr/src/sys/i386/compile/JUANILLO.
---
This happens after doing make depend without problems
(well, I had a problem related to bsd.init.mk not found, but I fixed
that)
So, immediatly after doing make I receive this error.
Can someone help me ? I've updated my 4.3 realease to 5.0 using
a 5.0 Develeper Preview 1 CD and I wanted to compile my own
kernel to add and stf interface and get my soundcard work.
The problem is that I dont have the CD any more. Is it possible
to make a cvsup to DP-1 ?
Thank you very much.
*
Juan F. Rodriguez Hervella
Universidad Carlos III de Madrid
*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: State of the ports collection
On Tue, Jun 04, 2002 at 02:29:17PM -0700, David O'Brien wrote: On Mon, Jun 03, 2002 at 01:42:24PM -0700, Kris Kennaway wrote: * (lots of ports) The new C++ compiler deprecated a lot of headers by moving them to a different directory: this breaks a heck of a lot of ports). IMO we should be searching this directory by default. example port please. Pretty much any C++ port. Picking a broken port at random is a good way to find one :) For example: http://bento.freebsd.org/errorlogs/5-full/leoarg-2.2.3.log Kris msg39176/pgp0.pgp Description: PGP signature
ps(1) -o peculiarity in CURRENT
Aphex% ps -ouser= ?? jmallett jmallett jmallett And then on STABLE: ps -ouser= flata flata flata flata flata And with a header provided: ps -ouser=WHO WHO flata flata flata flata flata However on CURRENT: Aphex% ps -ouser=WHO ?? jmallett jmallett jmallett -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve I've coined new words, like, misunderstanding and Hispanically. -- George W. Bush, Radio-Television Correspondents Association dinner, Washington, D.C., March 29, 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: State of the ports collection
It's a bit of a beast to compile, but the jdk13 port uses new.h in a couple of C++ files (I could be more specific, but I don't have the source extracted right now). Since that's now in the backward directory, I fixed the compile errors by including new instead. Everything else in that port compiled fine. -Patrick David O'Brien wrote: On Mon, Jun 03, 2002 at 01:42:24PM -0700, Kris Kennaway wrote: * (lots of ports) The new C++ compiler deprecated a lot of headers by moving them to a different directory: this breaks a heck of a lot of ports). IMO we should be searching this directory by default. example port please. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED] | 2624 Howe Hall Room 2624 PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mergemaster broken?
It correctly identifies files to be updated, asks me what I want to do, as usual, and when I hit 'i' for install it proceeds without error messages but then it tells me at the end that all the files I told it to install remain for me to merge by hand. In fact, none of the files get installed even though I said to install them. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Legal Services for pennies a day..Free Info., 1157
Form Results: realname: loveridgeFritz Gerald email: [EMAIL PROTECTED] body: Legal Services for Less than a Penny Per Day You can have a Top Law Firm in your area produce a Will for you, absolutely FREE, with your membership. http://61.129.81.99/tbone2/legal.html?marketing_id=kl Unlimited Legal Consultations Unlimited Phone Conversations Traffic Ticket Defense Contract Document Review Letters and Calls Made on Your Behalf IRS Audit Protection Trial Defense Business Family Protection Much More... Why pay $200 or more an hour when you can get the same first rate service for less than $1 per day? Get your FREE INFORMATION by clicking on the link below. Get you Free Information now!! http://61.129.81.99/tbone2/legal.html?marketing_id=kl -- If you feel that you have received this offer in error, or if you wish to unsubscribe, please mailto:[EMAIL PROTECTED] 0030 = Referring URL: To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ps(1) -o peculiarity in CURRENT
On Tue, Jun 04, 2002 at 03:13:21PM -0700, J. Mallett wrote: Aphex% ps -ouser= ?? jmallett jmallett jmallett I remember to see something like that when a kernel dependent command, such as ps, is out of sync w/ the running kernel. did you upgrade your kernel recently w/o syncing your world ? also, are your world sources in sync w/ the kernel sources ? did you reboot since your last kernel/world installation ? Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ps(1) -o peculiarity in CURRENT
* From Cyrille Lefevre [EMAIL PROTECTED] On Tue, Jun 04, 2002 at 03:13:21PM -0700, J. Mallett wrote: Aphex% ps -ouser= ?? jmallett jmallett jmallett I remember to see something like that when a kernel dependent command, such as ps, is out of sync w/ the running kernel. did you upgrade your kernel recently w/o syncing your world ? also, are your world sources in sync w/ the kernel sources ? did you reboot since your last kernel/world installation ? nevermind, I fixed my own problem, seems to have been a side-effect of the malloc-me-harder weight loss plan. -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve I've coined new words, like, misunderstanding and Hispanically. -- George W. Bush, Radio-Television Correspondents Association dinner, Washington, D.C., March 29, 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Typo in uma_core.c causing panics after uma_zdestroy()
The logic for testing UMA_ZFLAG_INTERNAL in zone_dtor() is reversed. I was able to reliably reproduce crashes with: mdconfig -a -t malloc -s 10m mdconfig -d -u 0 mdconfig -a -t malloc -s 10m mdconfig -d -u 0 Ian Index: uma_core.c === RCS file: /FreeBSD/FreeBSD-CVS/src/sys/vm/uma_core.c,v retrieving revision 1.26 diff -u -r1.26 uma_core.c --- uma_core.c 3 Jun 2002 22:59:19 - 1.26 +++ uma_core.c 5 Jun 2002 01:17:27 - @@ -1132,7 +1132,7 @@ printf(Zone %s was not empty. Lost %d pages of memory.\n, zone-uz_name, zone-uz_pages); - if ((zone-uz_flags UMA_ZFLAG_INTERNAL) != 0) + if ((zone-uz_flags UMA_ZFLAG_INTERNAL) == 0) for (cpu = 0; cpu maxcpu; cpu++) CPU_LOCK_FINI(zone, cpu); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Please help: why bufwait() will cause the thread status change to SSLEEP?
Dear John and everyone, I do not know the thread group means what in FreeBSD5.0.Could you give me some information?Now, I mask the code about thread group operations.When I want to get the RAIDFrame information(exist in the disk block).I can call raidread_component_label(), as the following:int raidread_component_label(dev, b_vp, clabel)udev_t dev;struct vnode *b_vp;RF_ComponentLabel_t *clabel;{struct buf *bp;int error;/* XXX should probably ensure that we don't try to do this if someone has changed rf_protected_sectors. */ if (b_vp == NULL) {/* For whatever reason, this component is not valid. Don't try to read a component label from it. */return(EINVAL);} /* get a block of the appropriate size... */bp = geteblk((int)RF_COMPONENT_INFO_SIZE);bp-b_dev = udev2dev(dev, 0); /* get our ducks in a row for the read */bp-b_blkno = RF_COMPONENT_INFO_OFFSET / DEV_BSIZE;bp-b_bcount = RF_COMPONENT_INFO_SIZE;/*oyk add here to support FreeBSD5.0*/bp-b_flags |= BIO_READ;bp-b_resid = RF_COMPONENT_INFO_SIZE / DEV_BSIZE;DEV_STRATEGY(bp, 0);error = bufwait(bp); bp-b_flags |= B_INVAL | B_AGE; bp-b_ioflags = ~BIO_ERROR; if (!error) {memcpy(clabel, bp-b_data, sizeof(RF_ComponentLabel_t)); }brelse(bp); return(error);} Now, when I excute the 'error = bufwait(bp);', the system will be crash. the error informationis also thread status SSLEEP.I do know what will cause the thread status change to SSLEEP.The function in FreeBSD4.x as following:int raidread_component_label(dev, b_vp, clabel)udev_t dev;struct vnode *b_vp;RF_ComponentLabel_t *clabel;{struct buf *bp;int error;/* XXX should probably ensure that we don't try to do this if someone has changed rf_protected_sectors. */ if (b_vp == NULL) {/* For whatever reason, this component is not valid. Don't try to read a component label from it. */return(EINVAL);} /* get a block of the appropriate size... */bp = geteblk((int)RF_COMPONENT_INFO_SIZE);bp-b_dev = udev2dev(dev, 0); /* get our ducks in a row for the read */bp-b_blkno = RF_COMPONENT_INFO_OFFSET / DEV_BSIZE;bp-b_bcount = RF_COMPONENT_INFO_SIZE;bp-b_flags |= B_READ;bp-b_resid = RF_COMPONENT_INFO_SIZE / DEV_BSIZE; BUF_STRATEGY(bp, 0); error = biowait(bp); if (!error) {memcpy(clabel, bp-b_data, sizeof(RF_ComponentLabel_t)); }brelse(bp); return(error);}I transfer it to FreeBSD5.0 according vinum example.Best RegardsOuyang Kai´ÓÍøÕ¾µÃµ½¸ü¶àÐÅÏ¢¡£MSN Explorer Ãâ·ÑÏÂÔØ£ºhttp://explorer.msn.com/lccn
I do not know the thread group means what in FreeBSD5.0.
Could you give me some information?
Now, I mask the code about thread group operations.
When I want to get the RAIDFrame information(exist in the disk block).
I can call raidread_component_label(), as the following:
int raidread_component_label(dev, b_vp, clabel)
udev_t dev;
struct vnode *b_vp;
RF_ComponentLabel_t *clabel;
{
struct buf *bp;
int error;
/* XXX should probably ensure that we don't try to do this if
someone has changed rf_protected_sectors. */
if (b_vp == NULL) {
/* For whatever reason, this component is not valid.
Don't try to read a component label from it. */
return(EINVAL);
}
/* get a block of the appropriate size... */
bp = geteblk((int)RF_COMPONENT_INFO_SIZE);
bp-b_dev = udev2dev(dev, 0);
/* get our ducks in a row for the read */
bp-b_blkno = RF_COMPONENT_INFO_OFFSET / DEV_BSIZE;
bp-b_bcount = RF_COMPONENT_INFO_SIZE;
/*oyk add here to support FreeBSD5.0*/
bp-b_flags |= BIO_READ;
bp-b_resid = RF_COMPONENT_INFO_SIZE / DEV_BSIZE;
DEV_STRATEGY(bp, 0);
error = bufwait(bp);
bp-b_flags |= B_INVAL | B_AGE;
bp-b_ioflags = ~BIO_ERROR;
if (!error) {
memcpy(clabel, bp-b_data,
sizeof(RF_ComponentLabel_t));
}
brelse(bp);
return(error);
}
Now, when I excute the 'error = bufwait(bp);', the system will be crash. the error
information
is also thread status SSLEEP.
I do know what will cause the thread status change to SSLEEP.
The function in FreeBSD4.x as following:
int raidread_component_label(dev, b_vp, clabel)
udev_t dev;
struct vnode *b_vp;
RF_ComponentLabel_t *clabel;
{
struct buf *bp;
int error;
/* XXX should probably ensure that we don't try to do this if
someone has changed rf_protected_sectors. */
if (b_vp == NULL) {
/* For whatever reason, this component is not valid.
Don't try to read a component label from it. */
return(EINVAL);
}
/* get a block of the appropriate size... */
bp = geteblk((int)RF_COMPONENT_INFO_SIZE);
bp-b_dev = udev2dev(dev, 0);
/* get our ducks in a row for the read */
bp-b_blkno = RF_COMPONENT_INFO_OFFSET / DEV_BSIZE;
Re: mergemaster broken?
...it tells me at the end that all the files I told it to install remain for me to merge by hand. Read the messages more closely and you should see one about perl not being installed. mergemaster tries to use perl, but can't use it even if it is installed since it is not in $PATH. /usr/bin/perl prints a misleading message when perl is installed but not in $PATH. Aha! After doing 'use.perl port' it works again, thanks. Looks like this is going to be necessary after each buildworld, then. :-/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mergemaster broken?
On Tue, Jun 04, 2002 at 07:52:19PM -0700, walt wrote: ...it tells me at the end that all the files I told it to install remain for me to merge by hand. Read the messages more closely and you should see one about perl not being installed. mergemaster tries to use perl, but can't use it even if it is installed since it is not in $PATH. /usr/bin/perl prints a misleading message when perl is installed but not in $PATH. Aha! After doing 'use.perl port' it works again, thanks. Looks like this is going to be necessary after each buildworld, then. :-/ I thought that's what NO_PERL is for. Kris msg39186/pgp0.pgp Description: PGP signature
Re: mergemaster broken?
On Tue, 4 Jun 2002, walt wrote: It correctly identifies files to be updated, asks me what I want to do, as usual, and when I hit 'i' for install it proceeds without error messages but then it tells me at the end that all the files I told it to install remain for me to merge by hand. Read the messages more closely and you should see one about perl not being installed. mergemaster tries to use perl, but can't use it even if it is installed since it is not in $PATH. /usr/bin/perl prints a misleading message when perl is installed but not in $PATH. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
