Re: Is Sawfish running on -current?
I have the following error while compiling Sawfish on recent -current. Is it my half updated fault or the -current issue? gmake[1]: Entering directory `/home/SRC/FreeBSD/FreeBSD-current/ports/x11-wm/sawfish/work/sawfish-0.36/lisp' SAWFISHLISPDIR=. SAWFISHEXECDIR=../src/.libexec SAWFISHDOCFILE=../DOC /usr/local/libexec/rep/i386--freebsd5.0/libtool --mode=execute -dlopen ../src/gradient.la ../src/sawfish --batch --no-rc compiler -f compile-batch sawfish/wm.jl Segmentation fault - core dumped gmake[1]: *** [sawfish/wm.jlc] Error 139 gmake[1]: Leaving directory `/home/SRC/FreeBSD/FreeBSD-current/ports/x11-wm/sawfish/work/sawfish-0.36/lisp' gmake: *** [all] Error 2 Strange. It works here without any problems. Do you have the last versions of librep and rep-gtk installed? If no, update and try again. Otherwise try to get backtrace from the core file and send it to me. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
From: Bruce Evans [EMAIL PROTECTED] Date: Sun, 11 Feb 2001 07:35:51 +1100 (EST) On Sat, 10 Feb 2001, Justin T. Gibbs wrote: Are there any reason device drivers do not check if thier devices are writable or not when they are opened ? I think returning an error value, like `od', is the easiest way to avoid this problem. It is not necessarily sufficient since the media may be changed after open on certain types of devices that don't have a media lock. Some devices will only tell you that they are write protected on the first write, etc. For the devices where we can tell, we should make the check in open, but not rely on that catching all cases where a driver will return EACCESS. Also, writing to a write protected sector is a special case of an i/o error, so it will be handled by non-broken general i/o error handling. Also^2, write protection might be for individual sectors and might change while the device is open, just like most i/o errors. We actually have this for most disks -- FreeBSD has write protection of label sectors in software, and it can be turned on and off while the device is open. Though both of them cannot be handled, I think it's worth checking if the entire device is write-protected or not at open(). Especially when the implementation is not so difficult. Why you have to try writing to a write-protected medium ? // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is Sawfish running on -current?
Thank you for quick reply. I found that my librep was old one - Sept one living in /usr/local/libexec/rep., and the latest one (v 1.23 2001/01/07) goes under /usr/X11R6/libexec/rep/i386--freebsd5.0/. So, I deleted /usr/local/libexec/rep hoping that new one living under X11R6 be used. Sigh! rep-gtk (v 1.23 2000/12/05) could not be compiled because it looked at /usr/local/libexec/rep/i386-freebsd5.0/rules.mk. I understand that it may be because of librep and rep-gtk, but I cannnot solve this /usr/X11R6/libexec/ vs. /usr/local/libexec/ by myself considering other programs, and stucked. I hope you can suggest some solution of this issue. (I'll be out a week and can not respond to for a while, please accept it.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
printing
My computer reboots when trying to print. I'm not shure from which update it doesn't work. Am I doing something wrog or? Rasa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: printing
On Sun, Feb 11, 2001 at 03:24:06PM +0100, Rasa Karapandza wrote: My computer reboots when trying to print. I'm not shure from which update it doesn't work. Am I doing something wrog or? If you're running -current, then this problem has been widely reported in the list already. Go back to -stable if you need a fully working machine at this point in time and can't deal with the development breakage. Kris PGP signature
OpenSSL ASM patch
Okay, I've finally come up with a patch that enables the OpenSSL asm code in a way which is generically controllable and extends to other code which may want to enable CPU-specific optimizations (e.g. libgmp). The patch is at http://www.freebsd.org/~kris/openssl-asm.patch It's based on a patch originally by Mike Silbersack [EMAIL PROTECTED], but the MACHINE_CPU stuff is mine and he shouldn't be blamed for it. Speedups are on the order of 3x-5x depending on the algorithm, for those which have asm cores available. Even the 386 should benefit from significant speed improvements, although I haven't tested this patch on a 386 or 486. It looks like the OpenSSL alpha asm code is broken (using the vendor build process doesn't build it either) - sorry, folks. The patch is fairly self-explanatory, and introduces a new variable called MACHINE_CPU which contains an unordered list of the CPU generations which we would like optimizations for, if present. Basically, this should be set to your CPU type plus all backwards-compatible revisions: e.g. MACHINE_CPU=i686 i585 i486 i386. I prefer doing it this way (MACHINE_CPU being a list) since it greatly simplifies the makefiles: For example, OpenSSL has Pentium ASM code for several algorithm cores in libcrypto. This code is what we want to compile on all "pentium class and above" CPUs (Pentium, PPro, Pentium II/III, AMD, ...), but there is also code for 686-class CPUs, and someday there may be AMD-optimized asm code, etc. If MACHINE_CPU is only a single word containing the exact CPU generation we intend to run on (e.g. "k6") then the makefile tests for whether to use the pentium code need to actually check for the name of all pentium-compatible CPUs and above, and if we miss one or the user uses a name we don't support then they won't get any optimization. Doing it as a list (i.e. MACHINE_CPU is a list of preferences or features we'd like) means that we can easily pick the best code to use based on what is available, and makes it more robust against mistakes. I'm not sure whether the way I've introduced MACHINE_CPU into sys.mk is the best way to do it, and whether make(1) also needs to be taught about it. I'd like to get this committed ASAP, please review. Kris PGP signature
locale changes break world
Can the people working on the locale stuff test their changes prior to check-in? /usr/src/lib/libc/../libc/locale/lmessages.c: In function `__messages_load_locale': /usr/src/lib/libc/../libc/locale/lmessages.c:61: syntax error before `struct' /usr/src/lib/libc/../libc/locale/lmessages.c:61: too few arguments to function `__part_load_locale' /usr/src/lib/libc/../libc/locale/lmessages.c:62: syntax error before `)' *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL ASM patch
Updated patch now available at the same location. Changes: * Document the MACHINE_CPU types which are currently used * Make NOPERL mutually exclusive with OpenSSL ASM and document it * Teach make(1) about MACHINE_CPU and provide sensible defaults for i386 and alpha. http://www.freebsd.org/~kris/openssl-asm.patch Kris PGP signature
Re: OpenSSL ASM patch
* Kris Kennaway [EMAIL PROTECTED] [010211 12:32] wrote: Updated patch now available at the same location. Changes: * Document the MACHINE_CPU types which are currently used * Make NOPERL mutually exclusive with OpenSSL ASM and document it * Teach make(1) about MACHINE_CPU and provide sensible defaults for i386 and alpha. http://www.freebsd.org/~kris/openssl-asm.patch Looks awesome, someone complained that Linux was able to maintain an order of magnitude more SSL connections than FreeBSD, since you say this gives us a 3-5x speed up, I'd really like to see it committed and ported to -stable ASAP. Is it possible to have multiple ASM cores and use the appropriate routines? Or must it all be choosen at compile time? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL ASM patch
On Sun, Feb 11, 2001 at 12:47:07PM -0800, Alfred Perlstein wrote: Looks awesome, someone complained that Linux was able to maintain an order of magnitude more SSL connections than FreeBSD, since you say this gives us a 3-5x speed up, I'd really like to see it committed and ported to -stable ASAP. Yep! Just want to give a few days for people to comment on the MACHINE_CPU thing. Is it possible to have multiple ASM cores and use the appropriate routines? Or must it all be choosen at compile time? It's done at compile-time. Kris PGP signature
Re: OpenSSL ASM patch
* Kris Kennaway [EMAIL PROTECTED] [010211 12:52] wrote: On Sun, Feb 11, 2001 at 12:47:07PM -0800, Alfred Perlstein wrote: Looks awesome, someone complained that Linux was able to maintain an order of magnitude more SSL connections than FreeBSD, since you say this gives us a 3-5x speed up, I'd really like to see it committed and ported to -stable ASAP. Yep! Just want to give a few days for people to comment on the MACHINE_CPU thing. Is it possible to have multiple ASM cores and use the appropriate routines? Or must it all be choosen at compile time? It's done at compile-time. bah, lame. :( How is the worst asm code vs the best C code again? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world failure...
What gives ??? cc -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/syv/src/lib/libc/include -D__DBINTERFACE _PRIVATE -DINET6 -I/usr/obj/syv/src/lib/libc -DPOSIX_MISTAKE -I/syv/src/lib/libc /../libc/locale -DBROKEN_DES -DYP -DHESIOD -I/usr/obj/syv/src/i386/usr/include - c /syv/src/lib/libc/../libc/locale/lmessages.c -o lmessages.o /syv/src/lib/libc/../libc/locale/lmessages.c: In function `__messages_load_local e': /syv/src/lib/libc/../libc/locale/lmessages.c:61: syntax error before `struct' /syv/src/lib/libc/../libc/locale/lmessages.c:61: too few arguments to function ` __part_load_locale' /syv/src/lib/libc/../libc/locale/lmessages.c:62: syntax error before `)' *** Error code 1 Stop in /syv/src/lib/libc. *** Error code 1 Stop in /syv/src/lib. *** Error code 1 Stop in /syv/src. *** Error code 1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world failure...
In 38689.981926085@critter, Poul-Henning Kamp wrote: cc -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/syv/src/lib/libc/include -D__DBINTERFACE _PRIVATE -DINET6 -I/usr/obj/syv/src/lib/libc -DPOSIX_MISTAKE -I/syv/src/lib/libc /../libc/locale -DBROKEN_DES -DYP -DHESIOD -I/usr/obj/syv/src/i386/usr/include - c /syv/src/lib/libc/../libc/locale/lmessages.c -o lmessages.o /syv/src/lib/libc/../libc/locale/lmessages.c: In function `__messages_load_local e': /syv/src/lib/libc/../libc/locale/lmessages.c:61: syntax error before `struct' /syv/src/lib/libc/../libc/locale/lmessages.c:61: too few arguments to function ` __part_load_locale' /syv/src/lib/libc/../libc/locale/lmessages.c:62: syntax error before `)' *** Error code 1 Stop in /syv/src/lib/libc. *** Error code 1 Stop in /syv/src/lib. *** Error code 1 Stop in /syv/src. *** Error code 1 It should work with '#include stddef.h'. ciao, -- Robert S. F. Drehmel [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL ASM patch
On Sun, Feb 11, 2001 at 01:02:43PM -0800, Alfred Perlstein wrote: * Kris Kennaway [EMAIL PROTECTED] [010211 12:52] wrote: On Sun, Feb 11, 2001 at 12:47:07PM -0800, Alfred Perlstein wrote: Looks awesome, someone complained that Linux was able to maintain an order of magnitude more SSL connections than FreeBSD, since you say this gives us a 3-5x speed up, I'd really like to see it committed and ported to -stable ASAP. Yep! Just want to give a few days for people to comment on the MACHINE_CPU thing. Is it possible to have multiple ASM cores and use the appropriate routines? Or must it all be choosen at compile time? It's done at compile-time. bah, lame. :( How is the worst asm code vs the best C code again? OpenSSL includes 386 and 586 asm for the following: bf, bn (number libraries), cast, des, md5, rc4, rc5, ripemd, sha1. and 686 asm for bf only (DES is broken) In fact there's not a lot of difference between (what are claimed to be) the i386 versions and the i586 versions (they're generated from the same source by a preprocessor, and in fact are identical for some/most files) - this probably means they are not very optimal. I was also wrong about the speed improvements (they're not quite so high, only around 2x) - perhaps my baseline benchmark was sharing the CPU with something else giving it a 2x slowdown. So I'm not sure where the 3-5x speed up comes from - either it's another rumour (you didn't hear it from Peter again, did you? :) or the cause is elsewhere. What we build now should be exactly in line with what openssl does itself. These measurements were done on my PPro 233, and no attempt at sample averaging was performed :-) Kris [C code] type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md2159.52k 437.09k 590.38k 647.48k 653.41k mdc2 405.46k 440.38k 439.93k 442.00k 442.93k md4 2415.06k12806.00k24615.33k32313.88k35873.96k md5 1888.65k 9092.61k16840.50k20897.62k22739.51k hmac(md5) 741.81k 4722.98k11755.58k18427.53k22120.47k sha1 1319.27k 3052.54k 6990.83k10423.14k11986.67k rmd160 846.12k 3629.76k 6249.11k 7644.14k 8178.40k rc4 13176.13k17308.64k18127.45k18709.00k18527.01k des cbc 2589.75k 2911.96k 2918.99k 2930.14k 2961.85k des ede3 719.78k 751.80k 758.33k 758.61k 761.84k idea cbc 0.00 0.00 0.00 0.00 0.00 rc2 cbc 1476.49k 1540.60k 1551.96k 1547.98k 1571.13k rc5-32/12 cbc 6533.14k 8820.63k 9144.01k 9159.59k 9189.25k blowfish cbc 3921.72k 4490.54k 4551.53k 4567.12k 4582.91k cast cbc 3725.39k 4496.47k 4425.20k 4432.26k 4461.36k signverifysign/s verify/s rsa 512 bits 0.0106s 0.0011s 94.5951.4 rsa 1024 bits 0.0620s 0.0034s 16.1296.7 rsa 2048 bits 0.3963s 0.0112s 2.5 89.4 rsa 4096 bits 2.6106s 0.0389s 0.4 25.7 signverifysign/s verify/s dsa 512 bits 0.0109s 0.0134s 91.5 74.6 dsa 1024 bits 0.0342s 0.0406s 29.3 24.6 [i386] type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 2525.24k13682.82k26954.24k34031.00k38153.23k hmac(md5) 952.04k 6381.75k17338.03k29527.15k37320.02k sha1 1621.91k 6960.45k11626.82k13810.67k14685.97k rmd1601238.63k 5838.79k10350.12k12930.47k13941.05k rc4 18170.79k24351.64k25941.40k26300.99k26613.25k des cbc 4743.99k 5342.60k 5377.98k 5406.58k 5379.56k des ede3 1809.64k 1903.68k 1908.81k 1921.80k 1928.79k rc5-32/12 cbc11934.06k15701.79k16004.71k16014.24k16569.98k blowfish cbc 5885.08k 6493.90k 6553.44k 6575.91k 6569.06k cast cbc 5889.94k 6558.54k 6578.21k 6627.23k 6571.16k signverifysign/s verify/s rsa 512 bits 0.0057s 0.0005s174.2 1822.0 rsa 1024 bits 0.0299s 0.0016s 33.4641.4 rsa 2048 bits 0.1757s 0.0052s 5.7193.5 rsa 4096 bits 1.1865s 0.0179s 0.8 55.8 signverifysign/s verify/s dsa 512 bits 0.0057s 0.0068s176.4146.8 dsa 1024 bits 0.0157s 0.0185s 63.8 54.1 dsa 2048 bits 0.0503s 0.0621s 19.9 16.1 [i586] type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 2588.19k13504.14k26623.31k35248.59k38189.04k hmac(md5) 946.51k 6358.38k17134.34k29501.74k37456.10k
Re: OpenSSL ASM patch
On Sun, Feb 11, 2001 at 12:28:02PM -0800, Kris Kennaway wrote: Updated patch now available at the same location. Changes: * Document the MACHINE_CPU types which are currently used Actually, it occurs to me that this will be useful for ports as well. Currently some of them have nonstandard knobs like WANT_3DNOW, which could be easily covered by sticking an appropriate 'k6' (or whatever) into your MACHINE_CPU variable. Kris PGP signature
HEADS UP: installworld gotchas
On Sun, 11 Feb 2001, Daniel Eischen wrote: deischen2001/02/11 14:06:46 PST Modified files: include stdio.h Log: libc MT-safety, part 2. Add a lock to FILE and define an additional flag. This commit caused some bootstrap problems. The installworld failed installing perl which seemed to need sed (from /usr/bin/sed), and libc got installed before sed. I used the following to install: # make buildworld # make installworld - fails in perl # cd /usr/src/usr.bin/sed # make install # cd /usr/src # make -DNOPERL installworld # make installworld I suppose that can be shortened to (at least): # make buildworld # make -DNOPERL installworld # make installworld or possibly: # make buildworld # cd /usr/src/usr.bin/sed # make install # cd /usr/src # make installworld -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world failure...
On Sun, Feb 11, 2001 at 10:56:18PM +0100, Robert Drehmel wrote: In 38689.981926085@critter, Poul-Henning Kamp wrote: [buildworld failure lib/libc/locale/lmessages.c] It should work with '#include stddef.h'. Yep, that seems to be enough to get past this point. I don't know if there are any other surprises, my buildworld is still running. /s/Udo -- There's more than one way to skin a cat: Way number 15 -- Krazy Glue and a toothbrush. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
On Sun, 11 Feb 2001, Daniel Eischen wrote:
On Sun, 11 Feb 2001, Daniel Eischen wrote:
deischen2001/02/11 14:06:46 PST
Modified files:
include stdio.h
Log:
libc MT-safety, part 2.
Add a lock to FILE and define an additional flag.
This commit caused some bootstrap problems. The installworld failed
installing perl which seemed to need sed (from /usr/bin/sed), and libc
got installed before sed. I used the following to install:
I think this is telling you that the new libc is incompatible with old
applications. Installworld uses sed from ${INSTALLTMP}/sed. It copies
sed from /usr/bin/sed at the start to (almost) ensure that only the old
version is used. If perl actually uses /usr/bin/sed, then that is
another bug in perl, but since perl is installed before sed, this makes
no difference because /usr/bin/sed is still the old version.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
On Mon, 12 Feb 2001, Bruce Evans wrote:
On Sun, 11 Feb 2001, Daniel Eischen wrote:
On Sun, 11 Feb 2001, Daniel Eischen wrote:
deischen2001/02/11 14:06:46 PST
Modified files:
include stdio.h
Log:
libc MT-safety, part 2.
Add a lock to FILE and define an additional flag.
This commit caused some bootstrap problems. The installworld failed
installing perl which seemed to need sed (from /usr/bin/sed), and libc
got installed before sed. I used the following to install:
I think this is telling you that the new libc is incompatible with old
applications. Installworld uses sed from ${INSTALLTMP}/sed. It copies
sed from /usr/bin/sed at the start to (almost) ensure that only the old
version is used. If perl actually uses /usr/bin/sed, then that is
another bug in perl, but since perl is installed before sed, this makes
no difference because /usr/bin/sed is still the old version.
The new libc is incompatible with some old applications, but I'm not
too sure why. The lock was added at the end of FILE...
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
jake2001/02/11 16:20:08 PST Modified files: sys/alpha/alpha trap.c sys/dev/acpica/Osd OsdSchedule.c sys/i386/i386genassym.c swtch.s trap.c sys/ia64/ia64trap.c sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c kern_resource.c kern_sig.c kern_subr.c kern_switch.c kern_synch.c sys/posix4 ksched.c sys/sys ktr.h param.h proc.h rtprio.h systm.h tty.h user.h sys/ufs/ffs ffs_snapshot.c sys/vm vm_glue.c vm_meter.c Added files: sys/sys priority.h runq.h Log: Implement a unified run queue and adjust priority levels accordingly. ... As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. As always, make world is your friend. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
The new libc is incompatible with some old applications, but I'm not too sure why. The lock was added at the end of FILE... The size of FILE changed, thus the old application and the new library no longer agree about the values for stdout and stderr: #define stdin (__sF[0]) #define stdout (__sF[1]) #define stderr (__sF[2]) - Tor Egge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
: The new libc is incompatible with some old applications, but I'm not : too sure why. The lock was added at the end of FILE... : :The size of FILE changed, thus the old application and the new library :no longer agree about the values for stdout and stderr: : : #define stdin (__sF[0]) : #define stdout (__sF[1]) : #define stderr (__sF[2]) : :- Tor Egge This is a major change to libc. The library maj must be bumped if you intend to change the sizeof(FILE), or every single third party application that uses stdio will break. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
On Sun, Feb 11, 2001 at 04:44:21PM -0800, Matt Dillon wrote: : The new libc is incompatible with some old applications, but I'm not : too sure why. The lock was added at the end of FILE... : :The size of FILE changed, thus the old application and the new library :no longer agree about the values for stdout and stderr: : : #define stdin (__sF[0]) : #define stdout (__sF[1]) : #define stderr (__sF[2]) : :- Tor Egge This is a major change to libc. The library maj must be bumped if you intend to change the sizeof(FILE), or every single third party application that uses stdio will break. The major number has already been bumped, I thought. If this is true then we've only broken compatibility with older versions of -current after the version number was bumped but before this change, right? Kris PGP signature
Re: HEADS UP: installworld gotchas
: : This is a major change to libc. The library maj must be bumped if you : intend to change the sizeof(FILE), or every single third party application : that uses stdio will break. : : -Matt Oh wait, is libc already bumped in current verses 4.2? If so then I guess we don't bump libc's maj. God help anyone using current though! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
Matt Dillon wrote:
:
: This is a major change to libc. The library maj must be bumped if you
: intend to change the sizeof(FILE), or every single third party applicatio
n
: that uses stdio will break.
:
: -Matt
Oh wait, is libc already bumped in current verses 4.2? If so then I gues
s
we don't bump libc's maj. God help anyone using current though!
-Matt
I cant help but wonder why on earth we didn't have it like this from the
start:
Index: include/stdio.h
===
RCS file: /home/ncvs/src/include/stdio.h,v
retrieving revision 1.26
diff -u -r1.26 stdio.h
--- include/stdio.h 2001/02/11 22:04:18 1.26
+++ include/stdio.h 2001/02/12 01:27:16
@@ -132,6 +132,9 @@
__BEGIN_DECLS
extern FILE __sF[];
+extern FILE *__stdin;
+extern FILE *__stdout;
+extern FILE *__stderr;
__END_DECLS
#define__SLBF 0x0001 /* line buffered */
@@ -194,9 +197,9 @@
#defineSEEK_END2 /* set file offset to EOF plus offset */
#endif
-#definestdin (__sF[0])
-#definestdout (__sF[1])
-#definestderr (__sF[2])
+#definestdin __stdin
+#definestdout __stdout
+#definestderr __stderr
/*
* Functions defined in ANSI C standard.
Index: lib/libc/stdio/findfp.c
===
RCS file: /home/ncvs/src/lib/libc/stdio/findfp.c,v
retrieving revision 1.10
diff -u -r1.10 findfp.c
--- lib/libc/stdio/findfp.c 2001/02/11 22:06:40 1.10
+++ lib/libc/stdio/findfp.c 2001/02/12 01:27:16
@@ -75,6 +75,10 @@
struct glue __sglue = { uglue, 3, __sF };
static struct glue *lastglue = uglue;
+FILE *__stdin = __sF[0];
+FILE *__stdout = __sF[1];
+FILE *__stderr = __sF[2];
+
static struct glue * moreglue __P((int));
static spinlock_t thread_lock = _SPINLOCK_INITIALIZER;
That compiles fine. The __stdin thing is in case somebody likes the idea
of #undef stdin or #ifdef stdin for some reason.
In fact, I can't imagine *any* reason not to do this. At least this would
insulate us from future nasties in FILE size changes, and would have
saved us in this case.
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: installworld gotchas
On Sun, 11 Feb 2001, Peter Wemm wrote: Matt Dillon wrote: : : This is a major change to libc. The library maj must be bumped if you : intend to change the sizeof(FILE), or every single third party applicatio n : that uses stdio will break. : : -Matt Oh wait, is libc already bumped in current verses 4.2? If so then I gues s we don't bump libc's maj. God help anyone using current though! -Matt I cant help but wonder why on earth we didn't have it like this from the start: [...] That compiles fine. The __stdin thing is in case somebody likes the idea of #undef stdin or #ifdef stdin for some reason. In fact, I can't imagine *any* reason not to do this. At least this would insulate us from future nasties in FILE size changes, and would have saved us in this case. I like it, commit it :-) -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
: :I cant help but wonder why on earth we didn't have it like this from the :start: : :Index: include/stdio.h :=== :... Yah. I say commit it. Might as well, it can't hurt any worse then changing the size of FILE. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
Daniel Eischen wrote: On Sun, 11 Feb 2001, Peter Wemm wrote: Matt Dillon wrote: : : This is a major change to libc. The library maj must be bumped if yo u : intend to change the sizeof(FILE), or every single third party applic atio n : that uses stdio will break. : : -Matt Oh wait, is libc already bumped in current verses 4.2? If so then I gues s we don't bump libc's maj. God help anyone using current though! -Matt I cant help but wonder why on earth we didn't have it like this from the start: [...] That compiles fine. The __stdin thing is in case somebody likes the idea of #undef stdin or #ifdef stdin for some reason. In fact, I can't imagine *any* reason not to do this. At least this would insulate us from future nasties in FILE size changes, and would have saved us in this case. I like it, commit it :-) Well, now that we've broken the ABI, now is as good a time as any... 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
Whither sftp(1)?
In his article at http://www.daemonnews.org/200102/armoring.html, Markus Delves describes the usage of the SSH ftp command to do secure file copies. I further notice that we install the sftpd server in both -stable and -current (though we don't include any prototype information on how to start it) so we're obviously half-way down the road, but what's the story with the client? Thanks. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Whither sftp(1)?
On Sun, Feb 11, 2001 at 07:07:40PM -0800, Jordan Hubbard wrote: In his article at http://www.daemonnews.org/200102/armoring.html, Markus Delves describes the usage of the SSH ftp command to do secure file copies. I further notice that we install the sftpd server in both -stable and -current (though we don't include any prototype information on how to start it) so we're obviously half-way down the road, but what's the story with the client? Thanks. I thought I told you about this today on IRC..but the answer is that OpenSSH 2.3.0 doesn't have an sftp client (it does interoperate with the ssh.com client, though). I discovered this afternoon that one exists in the devel version, so it will be imported with the next version, whenever that comes out. Kris PGP signature
Re: HEADS UP: installworld gotchas
On Sun, 11 Feb 2001, Daniel Eischen wrote: The new libc is incompatible with some old applications, but I'm not too sure why. The lock was added at the end of FILE... It's very incompatible. I happened to compile make(1) with the new stdio.h and the old libc.a (partly because unrelated changes broke compilation of libc). It did not work at all (it always found everything up to date). I would have thought that make(1) didn't know enough about the internals of FILE to even care about new fields in the middle, since things like getc() are no longer macros (it hopefully doesn't used the vestiges of these things which are now misplaced in stdio.h). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
On Sun, 11 Feb 2001, Peter Wemm wrote: I cant help but wonder why on earth we didn't have it like this from the start: Index: include/stdio.h === RCS file: /home/ncvs/src/include/stdio.h,v retrieving revision 1.26 diff -u -r1.26 stdio.h --- include/stdio.h 2001/02/11 22:04:18 1.26 +++ include/stdio.h 2001/02/12 01:27:16 @@ -132,6 +132,9 @@ __BEGIN_DECLS extern FILE __sF[]; +extern FILE *__stdin; +extern FILE *__stdout; +extern FILE *__stderr; __END_DECLS Once upon a time, people counted every instruction in getchar(), etc., and programmed it carefully to unnecessary indirections, not to mention function calls and locks. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
Bruce Evans wrote: On Sun, 11 Feb 2001, Peter Wemm wrote: I cant help but wonder why on earth we didn't have it like this from the start: Index: include/stdio.h === RCS file: /home/ncvs/src/include/stdio.h,v retrieving revision 1.26 diff -u -r1.26 stdio.h --- include/stdio.h 2001/02/11 22:04:18 1.26 +++ include/stdio.h 2001/02/12 01:27:16 @@ -132,6 +132,9 @@ __BEGIN_DECLS extern FILE __sF[]; +extern FILE *__stdin; +extern FILE *__stdout; +extern FILE *__stderr; __END_DECLS Once upon a time, people counted every instruction in getchar(), etc., and programmed it carefully to unnecessary indirections, not to mention function calls and locks. And, because it breaks global declarations like this: FILE *buffer = stdout; /* default buffer file is stdout */ I have fixed this to avoid the indirection, and am doing a buildworld to check it. It should be the same speed as before, but is still immune to the FILE size changes. 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: installworld gotchas
Peter Wemm wrote: Bruce Evans wrote: On Sun, 11 Feb 2001, Peter Wemm wrote: I cant help but wonder why on earth we didn't have it like this from the start: Index: include/stdio.h === RCS file: /home/ncvs/src/include/stdio.h,v retrieving revision 1.26 diff -u -r1.26 stdio.h --- include/stdio.h 2001/02/11 22:04:18 1.26 +++ include/stdio.h 2001/02/12 01:27:16 @@ -132,6 +132,9 @@ __BEGIN_DECLS extern FILE __sF[]; +extern FILE *__stdin; +extern FILE *__stdout; +extern FILE *__stderr; __END_DECLS Once upon a time, people counted every instruction in getchar(), etc., and programmed it carefully to unnecessary indirections, not to mention function calls and locks. And, because it breaks global declarations like this: FILE *buffer = stdout;/* default buffer file is stdout */ I have fixed this to avoid the indirection, and am doing a buildworld to check it. It should be the same speed as before, but is still immune to the FILE size changes. Argh... We are in far worse shape than I thought... === lib/libc install -Cv -c -o root -g wheel -m 444 libc.a /usr/lib install: libc.a - /usr/lib/libc.a install -Cv -c -s -o root -g wheel -m 444 -fschg libc.so.5 /usr/lib install: libc.so.5 - /usr/lib/libc.so.5 ln -sf libc.so.5 /usr/lib/libc.so install -Cv -c -o root -g wheel -m 444 libc_pic.a /usr/lib /usr/libexec/ld-elf.so.1: Undefined symbol "__sF" referenced from COPY relocation in install *** Error code 1 It seems that the "temporary" copies of the host tools like install etc are getting clobbered by the non-version-bump of libc. It is sheer luck that only the sed thing died before. It could have been a lot worse. 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
Is -CURRENT in bad shape?
Now I'm in the middle of make -j10 buildworld. Is -CURRENT in bad shape? I'm planning to blow away all /usr/local and /usr/X11R6 to build "a whole new world", again... ;) Should I wait for a couple of hours/days? Thanks... /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is -CURRENT in bad shape?
* John Indra [EMAIL PROTECTED] [010211 22:20] wrote: Now I'm in the middle of make -j10 buildworld. Is -CURRENT in bad shape? I'm planning to blow away all /usr/local and /usr/X11R6 to build "a whole new world", again... ;) Should I wait for a couple of hours/days? Current from Sat Feb 10 17:00:18 looks ok, there were just some patches to the scheduler but no one has complained yet. Let us know. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is -CURRENT in bad shape?
On Sun, Feb 11, 2001 at 10:39:56PM -0800, Alfred Perlstein wrote: Current from Sat Feb 10 17:00:18 looks ok, there were just some patches to the scheduler but no one has complained yet. Let us know. :) Thanks for the fast reply. I really need it. OK... buildworld seems to be running ok right now. I'll let you know if something goes wrong, of course... ;) BTW, today I saw post from John Baldwin to remove device random from the kernel config. Then, other post replied that this is a good thing, mpg123 playing went a lot better for him, well at least, that's what he said. If this is so, then why is there a device random line in GENERIC kernel? Do we really need device random? Thanks... -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
