Date: Thu, 15 Feb 2001 02:03:53 -0700 From: Warner Losh <imp@harmony.village.org> To: arch@freebsd.org Subject: The whole libc thing. Message-ID: <200102150903.f1F93rW62243@harmony.village.org>
next in thread | raw e-mail | index | archive | help
OK. Pere's bumping of libc won't work. We'd have to bump all shared
libraries that use stdio, which is too many. Even in the ports
system.
The issue, for those following along at home.
libc.so.5 defined std{in,out,err} in terms of absolte offsets into
the __sF array. This is bad if we ever want to change the size of
__sF.
libc.so.5.20010213 introduced __std{in,out,err} to deal with this.
These would be referenced rather than the __sF array.
Now here's where the problem comes in.
If I rebuild the world, certain libraries, like libcam.so.2, change
from referencing __sF to referencing __stderr and the like. This is
fine for new binaries, but introduces a problem for old binaries.
Consider cdrecord built before the change, say on 4.2R. It will
reference libc.so.4 (which has the __sF symbols, but not the __stderr
ones) and libcam.so.2. After the above buildworld, running cdrecord
will break with __stderr undefined. why? Well, that's involved.
cdrecord runs and ld.so brings in libcam.so.2 and libc.so.4. Since
libcam.so.2 references __stderr and libc.so.4 doesn't have it, we get
the error.
The only solution is to bump the major number of libcam.so.3 so that
old applications continue to work.
However, that's the rub. *ALL* libraries that reference
std{in,out,err} would need their major numbers bumped.
So what solutions do we have?
Green's solution of stealing a pointer and using that to "grow" FILE.
This would allow old binaris to keep working at the cost of binary
compatibility. There's a few extra indirections in this case, you'll
likely not be able to measure that performance loss. But it will work
with the case above and most of the others we threw at it.
Mike Smith has another solution that I'll let him explain because I
don't understand it. It might work, but it might not.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102150903.f1F93rW62243>