On Tuesday, 14th August 2001, Daniel Eischen wrote:

>> > So do we allow FILE to be extended only after bumping the library
>> > version once (after 5.0-release)?  And thereafter all extensions to
>> > FILE do not need a version bump?
>> We've already bumped libc for 5.x.  Assuming this works ok, we shouldn't need
>> any further bumps for extending FILE.
>True.  I guess the real problem is the other libraries that reference
>stdin, stdout, stderr.  These need to be rebuilt with the new stdio.h
>and libc in order to avoid any impact from future FILE changes.

I might sound like the harbinger of doom, but you have to bump the major
number on every library that uses stdio to solve the "FILE has changed
size" problem.  It's the same sort of problem that changing errno caused.
That was "solved" by the switch to elf, which caused global recompilation.

People are hoping to do this by just waiting.  Eventually most libraries
will experience a major version bump.  Similarly, most useful programs will
be recompiled (either against bumped libraries, or recompiled old ones).
But some programs will not be recompiled, and will fail in mysterious ways.
I often use really old binaries, so odds are it will happen to me. :-)

To prevent old binaries from going bad, the libraries they link to must
use the old version of stdio.  Definite ideas of the offset in __sF of
stdout and stderr are embeded in both the old programs, and the old
libraries (and of course, the old version of stdio).  If you recompile
the libraries against the new stdio, you break the old binaries.  The
solution is to not do that.

In short, when FILE changes size (and hence __sF offsets change), then
every consumer(*) of stdio must be bumped.  The recent __stdinp (and friends)
addition prevents this problem happening again in the future, but does not
solve the current problem of old binaries and old libraries knowing the
internals of stdio.


(*) OK, technically only uses of "stdout" and "stderr" variables screw up
when FILE changes size.  Uses of macros (like getc variants that are
sometimes macros) will screw up if offsets change, but that's easier
to avoid.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to