telnet build fails without openssl...
buildworld fails at telnet if you build with NOCRYPT and NO_OPENSSL -- telnet stuff is looking for NO_CRYPTO to disable this, which isn't documented anywhere... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libm problem
On Sat, 22 Mar 2003 23:41:14 -0800
David Schultz [EMAIL PROTECTED] wrote:
Thus spake Anti [EMAIL PROTECTED]:
On Sat, 22 Mar 2003 10:28:46 -0800
Steve Kargl [EMAIL PROTECTED] wrote:
Pentium 4 is definitely broken on 5.x. Perhaps, we should remove
the footshooting.
--- bsd.cpu.mk.orig Sat Mar 22 10:23:42 2003
+++ bsd.cpu.mk Sat Mar 22 10:27:11 2003
@@ -62,7 +62,9 @@
. elif ${CPUTYPE} == k5
_CPUCFLAGS = -march=pentium
. elif ${CPUTYPE} == p4
-_CPUCFLAGS = -march=pentium4
+# XXX gcc 3.2.2 appears to generate bad code on FreeBSD 5.x
+#_CPUCFLAGS = -march=pentium4
+_CPUCFLAGS = -march=pentiumpro
. elif ${CPUTYPE} == p3
_CPUCFLAGS = -march=pentium3
. elif ${CPUTYPE} == p2
pentium3 would be better than pentiumpro on a p4 i think...
You would think so, but in my (limited) testing on a P3, this does
not appear to be the case with gcc3 in -CURRENT. Optimizing for a
Ppro worked the best, IIRC.
yes but -current uses the closest cpu setting to the cputype you
choose, and in the case of pentium4 producing broken code the
obvious fallback would be pentium3... if the goal is optimal code
then use no higher than pentiumpro for any cputype as in -stable,
but that's more a policy decision than something to be changed in
a patch like this imo...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libm problem
On Sat, 22 Mar 2003 10:28:46 -0800
Steve Kargl [EMAIL PROTECTED] wrote:
Pentium 4 is definitely broken on 5.x. Perhaps, we should remove
the footshooting.
--- bsd.cpu.mk.orig Sat Mar 22 10:23:42 2003
+++ bsd.cpu.mk Sat Mar 22 10:27:11 2003
@@ -62,7 +62,9 @@
. elif ${CPUTYPE} == k5
_CPUCFLAGS = -march=pentium
. elif ${CPUTYPE} == p4
-_CPUCFLAGS = -march=pentium4
+# XXX gcc 3.2.2 appears to generate bad code on FreeBSD 5.x
+#_CPUCFLAGS = -march=pentium4
+_CPUCFLAGS = -march=pentiumpro
. elif ${CPUTYPE} == p3
_CPUCFLAGS = -march=pentium3
. elif ${CPUTYPE} == p2
pentium3 would be better than pentiumpro on a p4 i think...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: -O2 breaks GCC 3.2.1-compiled code (seems OS specific)
On 11 Mar 2003 03:52:18 +0200 Dan Naumov [EMAIL PROTECTED] wrote: Hello list. Since my issues are related to 5.0, I though I'd rather ask here. I've noticed an interesting problem: I am using FreeBSD 5.0-p4 and GCC 3.2.1 and if I use CPUTYPE=athlon-tbird and CFLAGS= -O2 -mmmx -m3dnow -fomit-frame-pointer -pipe, ezm3 refuses to compile AT ALL and even though AbiWord 1.0.4 does compile, it will always coredump on exit, preventing saving of any changes done to the Preferences. However, going down from -O2 to -O solved both problems. This makes me wonder what exactly is wrong, since I've used exactly the same CPUTYPE and CFLAGS under Gentoo Linux with GCC 3.2.1 for a long time and everything compiled absolutely fine. This leads me to believe that there are not only arch-specific, but also OS-specific GCC issues. Can anyone else confirm this ? need to add -fno-schedule-insns2 to your CFLAGS to get ezm3 to compile with -O2... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -O2 considered harmful
On Wed, 26 Feb 2003 13:06:54 +0100 Jens Rehsack [EMAIL PROTECTED] wrote: Dag-Erling Smorgrav wrote: It seems that with -O2 on ia32 (-march=k6-2 in my case), gcc will in some cases generate short jumps to targets too far away for the offset to fit in a single byte. A surefire way to reproduce this is to build Mesa (or XFree86-4-libraries, which includes parts of Mesa). Has anybody else run into this? I build world and ports on desktop machines usually using -O2 and never got any problems, except with lang/ezm3. If you tell me, where you've find the problems, I'll tell my gcc to keep the temporaries and check them after a make build. you need to add -fno-schedule-insns2 to your CFLAGS to compile ezm3 with -O2... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MSDOS fs install problem
On Sun, 19 Jan 2003 01:25:12 -0200 Giovanni P. Tirloni [EMAIL PROTECTED] wrote: Hi, I was trying to install FreeBSD -CURRENT snapshot from 2003-01-16 (current.freebsd.org snapshots) and got this error Error mounting /dev/ad0s1 on /dist: Operation not \ supported by device (19) while trying to mount the slice that had FreeBSD/ on it. It happened with other snapshots too. Is it still possible to install from a MSDOS partition by default ? sysinstall in -current could never find my msdos partition to install from... `Anti` To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
getting rid of devfs...
how are you supposed to get rid of devfs? building a kernel without it won't boot since there are no devices... shouldn't there be a ./MAKEDEV all or something underneath the devfs mount so you can boot without it? or am i missing something? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
and if you must? dual boot 4.7 here so was able to create the devices easy enough from there and all is well, but i'd like to do it on some other boxes where this isn't an option... On Sat, 09 Nov 2002 00:14:08 +0100 Poul-Henning Kamp [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Anti writes: how are you supposed to get rid of devfs? You're not. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
