On Mon, 12 Feb 2001, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Daniel
>Eischen writes:
> : On Mon, 12 Feb 2001, Warner Losh wrote:
> : > To be blunt, the FILE * changes go too far, even for -current.
> :
> : Other than having to installworld twice, I've had zero problems.
> : But I don't recompile my applications often, and am probably
> : still running things that depend on libc.so.4.
>
> I have lots of binaries that depend on libc.so.5 (I just checked) and
> none that depend on libc.so.4 or libc.so.3 (since those were removed
> from my system a while ago). I suspect many of them will break.
>
> : > Changes of this magnitude require a bump of the major number, even
> : > though we've already done that in -current. It breaks nearly
> : > everything, including the upgrade path. Alternatively, the locking
> : > changes need to be backed out.
> :
> : Too bad ELF libraries don't have minor version numbers. It's
> : a shame to waste a library version number.
>
> Don't think of it as a waste.
>
> : > Alternatively, the upgrade path must be fixed. We've managed to avoid
> : > extra special instructions in the vast majority of cases, and I don't
> : > want to start introducing them now. It is the road to madness. We
> : > tried that once before and the support load was too high.
> :
> : I don't have the time or resources to fix the upgrade path. If
> : someone else wants to, it would certainly be appreciated.
>
> Then wouldn't the "partially applied patch" rule apply? eg, back it
> out until the issues can be resolved. Breaking the upgrade path isn't
> acceptible.
If you bump the library versions, doesn't that fix the upgrade
path?
I can think of a gross hack that gets around the problem for
now. Allocate the FILE with enough storage for the lock, but
don't declare it in FILE. __sF[3] would still be the same
size and we could have __sF_locks[3] internally, and use these
if fp is stdin, stdout, or stderr, else the lock is at the end
of the struct.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
