Re: HEADS UP: installworld gotchas
< said: > That is (1) against Handbook documented policy, (2) too hackish (we > aren't Linux). And who came up with that policy in the first place? -GAWollman 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, David O'Brien wrote: > On Mon, Feb 12, 2001 at 11:47:04AM -0500, Garrett Wollman wrote: > > However, this may turn out to be so painful that we need to bump it > > again. > > That is (1) against Handbook documented policy, (2) too hackish (we > aren't Linux). It's not bumping it that is hackish. 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, Feb 12, 2001 at 11:47:04AM -0500, Garrett Wollman wrote: > However, this may turn out to be so painful that we need to bump it > again. That is (1) against Handbook documented policy, (2) too hackish (we aren't Linux). 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: >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. For -stable this would be true. We've already done the bump in -current. -current users are expected to be able to work themselves over this huddle. Alternately, we should add symbol versioning to our shared libs like Solaris does. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
At 11:47 AM 2/12/2001 -0500, Garrett Wollman wrote: >< said: > >> 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? > >However, this may turn out to be so painful that we need to bump it >again. > >-GAWollman > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message I just did a make build world on current and was looking forward to rebuilding all the ports :) Should I wait until the version bump then try again. I realize that if I do a install world now I'll have to rebuild almost everything X,apache.bind,etc,etc. I just don't want to do it twice in two days. I guess I'll wait. I already experienced some of the ramifications from just installing a current libc.so.5. Fortunately i kept a backup copy of the old one :) Thanks Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
< said: > 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? However, this may turn out to be so painful that we need to bump it again. -GAWollman 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.
Wouldn't this change/break code like the following?
main()
{
FILE **fp;
fp = &stdin;
my_func(fp);
}
That is, previously &stdin would work... in this new situation,
you would get &__stdin which is not the same... is it?
- Dave Rivers -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: installworld gotchas
Doug Barton wrote: > > Peter Wemm wrote: > > > Argh... We are in far worse shape than I thought... > > > 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. > > I managed to get through an install by doing 'make -k install ; make > installworld' in /usr/src. So far, the only thing that's been negatively > affected is my old x-chat binary. I compiled and installed a new one and it > works just fine. Well, I spoke a little too soon. xauth is also dead. It isn't allowing connections back to the X server, and it dumps core when I try running it to list .Xauthority contents, etc. Doug -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? 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: > Argh... We are in far worse shape than I thought... > 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. I managed to get through an install by doing 'make -k install ; make installworld' in /usr/src. So far, the only thing that's been negatively affected is my old x-chat binary. I compiled and installed a new one and it works just fine. FWIW, Doug -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? 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
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
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
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
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
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
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
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
: : 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
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
:> 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
> 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
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
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
