From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland McGrath To: hjl@lucon.org (H.J. Lu) Cc: ian@cygnus.com (Ian Lance Taylor), gas2@cygnus.com, libc-hacker@cygnus.com Subject: Re: Has anyone looked at ELF 4.1? Date: Tue, 11 Aug 1998 00:51:00 -0000 Message-id: <199808110750.DAA24175@baalperazim.frob.com> References: X-SW-Source: 1998/msg00201.html > The purpose of EI_OSABI and EI_ABIVERSION is to tag the OS and ABI. It appears so, but the spec should be a whole lot clearer than it is. > I think we should register ELFOSABI_LINUX and define it as 1. It may > make many things easier for us. Right now, after I upgrade from > glibc 2.0 to 2.1, groff (man) no longer works since the C++ ABI in > glibc is changed. That may be a good idea, but the issue you cite is not an argument for it. We already have the mechanisms of DT_SONAME and the GNU symbol versioning extensions, so we can fix this problem correctly before deploying glibc 2.1. If an existing library that was not in error under glibc 2.0 breaks because of installing glibc 2.1, then it is a bug in glibc 2.1 and we must be damn sure that we stamp all those out before making the release. If the standard C++ libraries used libc internals in glibc 2.0, or only they are affected by the obscure problem, then it is ok if we require people to install new C++ libraries in tandem with glibc 2.1. We just need to be very clear about the installation procedure, and must make very sure that all old C++ libraries and programs continue to work with new libraries. We can change the sonames if need be, that is better than breaking old binaries.