Re: libX11 is borked (or is it glibc ?)
> > Binary compatibility means you con run programs linked against older > > libraries. Guess what, X and the libX11 linked apps still work don't they? > > To me "binary compatible" means that, things act as they did before > ... when linked with the old library. Which includes being able to > "run" your old libraries linked against old libraries. Your definition is incorrect. > > > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep chown > > > 000913c8 T __chown@@GLIBC_2.1 > > > 000913c8 T chown@@GLIBC_2.1 > > > 00091454 T [EMAIL PROTECTED] > > > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep fopen > > > 0004b5c4 T _IO_file_fopen@@GLIBC_2.1 > > > 0004da48 T [EMAIL PROTECTED] > > > 000481e0 T _IO_fopen@@GLIBC_2.1 > > > 0004a9a0 T [EMAIL PROTECTED] > > > 000481e0 T fopen@@GLIBC_2.1 > > > 0004a9a0 T [EMAIL PROTECTED] > > > > > > So either something bad has happened with the glibc versioning > > > upstream or glibc was built badly. > > > > No, this is inherent in versioned symbols. The old symbol is now "weak", > > which means it is there for using by old programs, but cannot be used when > > linking. A weak symbol keeps compatibility, which allowing the new strong > > symbol to be used for newly compiled applications. > > This seems wrong, for instance ulimit() is a weak alias for > __ulimit. But maybe you mean something different ? And applications/libs using ulimit() reference __ulimit instead. But if a lib referenced the ulimit weak symbol instead (somehow), then it would have to be recompiled if you wanted to link against it (but it would still continue to work as before). > I was pretty sure that I'd compiled/linked programs against glibc-2.1.3 > and another library that used 2.0.7. Maybe I'm getting senile in my > old age or maybe it worked but doesn't guarantee it. Not everything has to be recompiled. Just libs that use obsolete symbols (ones that have changed to weak symbols for compatibility, but now have newer versions of that symbol). We had this same issue with the 2.0.7 -> 2.1.0 upgrade. It was actually a lot more extensive than this upgrade. > Ahh well learn something bad every day I guess. Heh, I'd rather have this than have to recompile all applications because versioned symbols did not exist to begin with. Atleast with this scheme, we have an upgrade path (that wasn't there for the libc5 -> libc6 changeover). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: libX11 is borked (or is it glibc ?)
Ben Collins <[EMAIL PROTECTED]> writes: > On Mon, Oct 16, 2000 at 01:10:03AM -0400, James Antill wrote: > > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > > > On Mon, Oct 16, 2000 at 01:59:11AM +0200, Johannes Zellner wrote: > > > > Hello, > > > > > > > > I cannot link any more against libX11.so: > > > > > > > > /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' > > > > > > > > this shows, even if I link a minimal c program. > > > > > > > > my versions: > > > > ii xlib6g 3.3.6-11 > > > > ii libc6 2.1.94-3 > > > > > > > > Any comments ? > > > > > > To compile against a library built under an old glibc, the library > > > needs to be recompiled to the new libc. > > > > If this is true then there isn't any binary compatibility. > > The whole point of the symbols looking like the above is so that > > there can be multiple versions of them. Eg. > > Binary compatibility means you con run programs linked against older > libraries. Guess what, X and the libX11 linked apps still work don't they? To me "binary compatible" means that, things act as they did before ... when linked with the old library. Which includes being able to "run" your old libraries linked against old libraries. > > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep chown > > 000913c8 T __chown@@GLIBC_2.1 > > 000913c8 T chown@@GLIBC_2.1 > > 00091454 T [EMAIL PROTECTED] > > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep fopen > > 0004b5c4 T _IO_file_fopen@@GLIBC_2.1 > > 0004da48 T [EMAIL PROTECTED] > > 000481e0 T _IO_fopen@@GLIBC_2.1 > > 0004a9a0 T [EMAIL PROTECTED] > > 000481e0 T fopen@@GLIBC_2.1 > > 0004a9a0 T [EMAIL PROTECTED] > > > > So either something bad has happened with the glibc versioning > > upstream or glibc was built badly. > > No, this is inherent in versioned symbols. The old symbol is now "weak", > which means it is there for using by old programs, but cannot be used when > linking. A weak symbol keeps compatibility, which allowing the new strong > symbol to be used for newly compiled applications. This seems wrong, for instance ulimit() is a weak alias for __ulimit. But maybe you mean something different ? I was pretty sure that I'd compiled/linked programs against glibc-2.1.3 and another library that used 2.0.7. Maybe I'm getting senile in my old age or maybe it worked but doesn't guarantee it. Ahh well learn something bad every day I guess. -- James Antill -- [EMAIL PROTECTED] "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy.
Re: libX11 is borked (or is it glibc ?)
On Mon, Oct 16, 2000 at 01:10:03AM -0400, James Antill wrote: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 16, 2000 at 01:59:11AM +0200, Johannes Zellner wrote: > > > Hello, > > > > > > I cannot link any more against libX11.so: > > > > > > /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' > > > > > > this shows, even if I link a minimal c program. > > > > > > my versions: > > > ii xlib6g 3.3.6-11 > > > ii libc6 2.1.94-3 > > > > > > Any comments ? > > > > To compile against a library built under an old glibc, the library > > needs to be recompiled to the new libc. > > If this is true then there isn't any binary compatibility. > The whole point of the symbols looking like the above is so that > there can be multiple versions of them. Eg. Binary compatibility means you con run programs linked against older libraries. Guess what, X and the libX11 linked apps still work don't they? > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep chown > 000913c8 T __chown@@GLIBC_2.1 > 000913c8 T chown@@GLIBC_2.1 > 00091454 T [EMAIL PROTECTED] > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep fopen > 0004b5c4 T _IO_file_fopen@@GLIBC_2.1 > 0004da48 T [EMAIL PROTECTED] > 000481e0 T _IO_fopen@@GLIBC_2.1 > 0004a9a0 T [EMAIL PROTECTED] > 000481e0 T fopen@@GLIBC_2.1 > 0004a9a0 T [EMAIL PROTECTED] > > So either something bad has happened with the glibc versioning > upstream or glibc was built badly. No, this is inherent in versioned symbols. The old symbol is now "weak", which means it is there for using by old programs, but cannot be used when linking. A weak symbol keeps compatibility, which allowing the new strong symbol to be used for newly compiled applications. > > I think there's already a > > forthcoming X 3.3.6 upgrade which will be rebuilt against woody glibc - > > right, Branden? > > If it's woody, then it's probably an upstream problem but X 3.3.6 > _should not_ be upgraded (well not to fix this anyway, obviously there > may be other reasons to upgrade). Yes it should, just to fix this. Versioned symbols and their solution for binary compatibility, ensured that everything will still run as it did before. It does not mean that things wont have to be rebuilt to allow linking. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: libX11 is borked (or is it glibc ?)
On Mon, Oct 16, 2000 at 01:10:03AM -0400, James Antill wrote: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 16, 2000 at 01:59:11AM +0200, Johannes Zellner wrote: > > > Hello, > > > > > > I cannot link any more against libX11.so: > > > > > > /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' > > > > > > this shows, even if I link a minimal c program. > > > > > > my versions: > > > ii xlib6g 3.3.6-11 > > > ii libc6 2.1.94-3 > > > > > > Any comments ? > > > > To compile against a library built under an old glibc, the library > > needs to be recompiled to the new libc. > > If this is true then there isn't any binary compatibility. > The whole point of the symbols looking like the above is so that > there can be multiple versions of them. Eg. > > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep chown > 000913c8 T __chown@@GLIBC_2.1 > 000913c8 T chown@@GLIBC_2.1 > 00091454 T [EMAIL PROTECTED] > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep fopen > 0004b5c4 T _IO_file_fopen@@GLIBC_2.1 > 0004da48 T [EMAIL PROTECTED] > 000481e0 T _IO_fopen@@GLIBC_2.1 > 0004a9a0 T [EMAIL PROTECTED] > 000481e0 T fopen@@GLIBC_2.1 > 0004a9a0 T [EMAIL PROTECTED] > > So either something bad has happened with the glibc versioning > upstream or glibc was built badly. No, you misunderstand symbol versioning. There is -runtime- compatiblity - the old [EMAIL PROTECTED] is still there. However, there is no compile-time compatibility - a library referencing that [EMAIL PROTECTED] can no longer be linked to. This is, I believe, deliberate. Libraries must be recompiled to be linked to. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
Re: libX11 is borked (or is it glibc ?)
On Mon, Oct 16, 2000 at 01:10:03AM -0400, James Antill wrote: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 16, 2000 at 01:59:11AM +0200, Johannes Zellner wrote: > > > Hello, > > > > > > I cannot link any more against libX11.so: > > > > > > /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' > > > > > > this shows, even if I link a minimal c program. > > > > > > my versions: > > > ii xlib6g 3.3.6-11 > > > ii libc6 2.1.94-3 > > > > > > Any comments ? > > > > To compile against a library built under an old glibc, the library > > needs to be recompiled to the new libc. > > If this is true then there isn't any binary compatibility. > The whole point of the symbols looking like the above is so that > there can be multiple versions of them. Eg. Binary compatibility means you con run programs linked against older libraries. Guess what, X and the libX11 linked apps still work don't they? > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep chown > 000913c8 T __chown@@GLIBC_2.1 > 000913c8 T chown@@GLIBC_2.1 > 00091454 T [EMAIL PROTECTED] > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep fopen > 0004b5c4 T _IO_file_fopen@@GLIBC_2.1 > 0004da48 T [EMAIL PROTECTED] > 000481e0 T _IO_fopen@@GLIBC_2.1 > 0004a9a0 T [EMAIL PROTECTED] > 000481e0 T fopen@@GLIBC_2.1 > 0004a9a0 T [EMAIL PROTECTED] > > So either something bad has happened with the glibc versioning > upstream or glibc was built badly. No, this is inherent in versioned symbols. The old symbol is now "weak", which means it is there for using by old programs, but cannot be used when linking. A weak symbol keeps compatibility, which allowing the new strong symbol to be used for newly compiled applications. > > I think there's already a > > forthcoming X 3.3.6 upgrade which will be rebuilt against woody glibc - > > right, Branden? > > If it's woody, then it's probably an upstream problem but X 3.3.6 > _should not_ be upgraded (well not to fix this anyway, obviously there > may be other reasons to upgrade). Yes it should, just to fix this. Versioned symbols and their solution for binary compatibility, ensured that everything will still run as it did before. It does not mean that things wont have to be rebuilt to allow linking. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libX11 is borked (or is it glibc ?)
On Mon, Oct 16, 2000 at 01:10:03AM -0400, James Antill wrote: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 16, 2000 at 01:59:11AM +0200, Johannes Zellner wrote: > > > Hello, > > > > > > I cannot link any more against libX11.so: > > > > > > /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' > > > > > > this shows, even if I link a minimal c program. > > > > > > my versions: > > > ii xlib6g 3.3.6-11 > > > ii libc6 2.1.94-3 > > > > > > Any comments ? > > > > To compile against a library built under an old glibc, the library > > needs to be recompiled to the new libc. > > If this is true then there isn't any binary compatibility. > The whole point of the symbols looking like the above is so that > there can be multiple versions of them. Eg. > > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep chown > 000913c8 T __chown@@GLIBC_2.1 > 000913c8 T chown@@GLIBC_2.1 > 00091454 T [EMAIL PROTECTED] > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep fopen > 0004b5c4 T _IO_file_fopen@@GLIBC_2.1 > 0004da48 T [EMAIL PROTECTED] > 000481e0 T _IO_fopen@@GLIBC_2.1 > 0004a9a0 T [EMAIL PROTECTED] > 000481e0 T fopen@@GLIBC_2.1 > 0004a9a0 T [EMAIL PROTECTED] > > So either something bad has happened with the glibc versioning > upstream or glibc was built badly. No, you misunderstand symbol versioning. There is -runtime- compatiblity - the old [EMAIL PROTECTED] is still there. However, there is no compile-time compatibility - a library referencing that [EMAIL PROTECTED] can no longer be linked to. This is, I believe, deliberate. Libraries must be recompiled to be linked to. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libX11 is borked (or is it glibc ?)
On Sun, Oct 15, 2000 at 09:02:42PM -0400, Daniel Jacobowitz wrote: > To compile against a library built under an old glibc, the library > needs to be recompiled to the new libc. I think there's already a > forthcoming X 3.3.6 upgrade which will be rebuilt against woody glibc - > right, Branden? Not exactly. When the 4.x packages are done, here's what will happen to 3.x, as can be previewed on samosa: 1) some 3.x servers will be built for alpha and i386 2) libc5-compatible X libraries will be built for i386 It is true however that the problem described will go away. -- G. Branden Robinson | Debian GNU/Linux| Never attribute to malice that which can [EMAIL PROTECTED] | be adequately explained by stupidity. http://www.debian.org/~branden/ | pgpCoygigScUY.pgp Description: PGP signature
Re: libX11 is borked (or is it glibc ?)
On Sun, Oct 15, 2000 at 09:02:42PM -0400, Daniel Jacobowitz wrote: > To compile against a library built under an old glibc, the library > needs to be recompiled to the new libc. I think there's already a > forthcoming X 3.3.6 upgrade which will be rebuilt against woody glibc - > right, Branden? Not exactly. When the 4.x packages are done, here's what will happen to 3.x, as can be previewed on samosa: 1) some 3.x servers will be built for alpha and i386 2) libc5-compatible X libraries will be built for i386 It is true however that the problem described will go away. -- G. Branden Robinson | Debian GNU/Linux| Never attribute to malice that which can [EMAIL PROTECTED] | be adequately explained by stupidity. http://www.debian.org/~branden/ | PGP signature
Re: libX11 is borked (or is it glibc ?)
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > On Mon, Oct 16, 2000 at 01:59:11AM +0200, Johannes Zellner wrote: > > Hello, > > > > I cannot link any more against libX11.so: > > > > /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' > > > > this shows, even if I link a minimal c program. > > > > my versions: > > ii xlib6g 3.3.6-11 > > ii libc6 2.1.94-3 > > > > Any comments ? > > To compile against a library built under an old glibc, the library > needs to be recompiled to the new libc. If this is true then there isn't any binary compatibility. The whole point of the symbols looking like the above is so that there can be multiple versions of them. Eg. % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep chown 000913c8 T __chown@@GLIBC_2.1 000913c8 T chown@@GLIBC_2.1 00091454 T [EMAIL PROTECTED] % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep fopen 0004b5c4 T _IO_file_fopen@@GLIBC_2.1 0004da48 T [EMAIL PROTECTED] 000481e0 T _IO_fopen@@GLIBC_2.1 0004a9a0 T [EMAIL PROTECTED] 000481e0 T fopen@@GLIBC_2.1 0004a9a0 T [EMAIL PROTECTED] So either something bad has happened with the glibc versioning upstream or glibc was built badly. > I think there's already a > forthcoming X 3.3.6 upgrade which will be rebuilt against woody glibc - > right, Branden? If it's woody, then it's probably an upstream problem but X 3.3.6 _should not_ be upgraded (well not to fix this anyway, obviously there may be other reasons to upgrade). -- James Antill -- [EMAIL PROTECTED] "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy.
Re: libX11 is borked (or is it glibc ?)
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > On Mon, Oct 16, 2000 at 01:59:11AM +0200, Johannes Zellner wrote: > > Hello, > > > > I cannot link any more against libX11.so: > > > > /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' > > > > this shows, even if I link a minimal c program. > > > > my versions: > > ii xlib6g 3.3.6-11 > > ii libc6 2.1.94-3 > > > > Any comments ? > > To compile against a library built under an old glibc, the library > needs to be recompiled to the new libc. If this is true then there isn't any binary compatibility. The whole point of the symbols looking like the above is so that there can be multiple versions of them. Eg. % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep chown 000913c8 T __chown@@GLIBC_2.1 000913c8 T chown@@GLIBC_2.1 00091454 T [EMAIL PROTECTED] % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep fopen 0004b5c4 T _IO_file_fopen@@GLIBC_2.1 0004da48 T [EMAIL PROTECTED] 000481e0 T _IO_fopen@@GLIBC_2.1 0004a9a0 T [EMAIL PROTECTED] 000481e0 T fopen@@GLIBC_2.1 0004a9a0 T [EMAIL PROTECTED] So either something bad has happened with the glibc versioning upstream or glibc was built badly. > I think there's already a > forthcoming X 3.3.6 upgrade which will be rebuilt against woody glibc - > right, Branden? If it's woody, then it's probably an upstream problem but X 3.3.6 _should not_ be upgraded (well not to fix this anyway, obviously there may be other reasons to upgrade). -- James Antill -- [EMAIL PROTECTED] "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libX11 is borked (or is it glibc ?)
> In <[EMAIL PROTECTED]> > Johannes Zellner <[EMAIL PROTECTED]> wrote: >> Hello, >> >> I cannot link any more against libX11.so: >> >> /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' >> >> this shows, even if I link a minimal c program. >> >> my versions: >> ii xlib6g 3.3.6-11 >> ii libc6 2.1.94-3 >> >> Any comments ? Perhaps you should upgrade binutils to latest unstable. -- ISHIKAWA Mutsumi <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Re: libX11 is borked (or is it glibc ?)
On Mon, Oct 16, 2000 at 01:59:11AM +0200, Johannes Zellner wrote: > Hello, > > I cannot link any more against libX11.so: > > /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' > > this shows, even if I link a minimal c program. > > my versions: > ii xlib6g 3.3.6-11 > ii libc6 2.1.94-3 > > Any comments ? To compile against a library built under an old glibc, the library needs to be recompiled to the new libc. I think there's already a forthcoming X 3.3.6 upgrade which will be rebuilt against woody glibc - right, Branden? Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
libX11 is borked (or is it glibc ?)
Hello, I cannot link any more against libX11.so: /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' this shows, even if I link a minimal c program. my versions: ii xlib6g 3.3.6-11 ii libc6 2.1.94-3 Any comments ? -- Johannes
