On Tue, Apr 08, 2003 at 09:51:32AM -0500, Shawn wrote: > > That doesn't count as an ABI change - pretty sure statically linking > > to libc means you could break at any time, even due to an errata. > > Ditto for using symbols that start with "__" > > > > If the libc ABI were considered officially changed it would have gone > > to libc.so.7 and there would be libc.so.6 in a compat package. > > > > That's my understanding anyway. > > I can see your view of it, but I'll just have to agree to disagree > :) Well, all I'm saying is that it's known and advertised by the maintainers of glibc that if you statically link or use symbols starting with __ that your stuff will break - so if you don't want to stuff to break, you might want to avoid doing those things. ;-) Incidentally, if your app is LSB-compliant it will automatically follow these rules. > The biggest problem I have with using RedHat8.x/9 is the C++ ABI > change. That's a whole different thing. The officially supported bits of the C++ ABI have changed various times, the officially supported bits of the glibc ABI have not since the libc5->libc6 transition. When the libstdc++ ABI has changed, compat versions of libstdc++ have been shipped, and the soname incremented on the default version. > How does a commercial or non-commercial (in my case) developer properly > release binaries for other platforms and avoid all of these currently > very ugly issues? The last thing users really want to deal with is > library dependencies, C++ ABI changes, glibc ABI changes, etc. For glibc, not knowing specifically what breakage you are seeing, the way you need to deal with the change is to only use what you're supposed to. Don't statically link to glibc, and don't use internal symbols starting with __. If you're using the well-specified official ABI of glibc, and your app still breaks, then that's considered a bug. If you're heavily relying on old thread behavior, at least for now you can also set LD_ASSUME_KERNEL=2.2.5 as a workaround. For C++, the matter is more complicated; the gcc project has not wanted to commit to a stable ABI until they had a test suite validating that the ABI was conformant to standard ABI specs. What I've heard is that they have that now and once we upgrade to latest gcc the ABI will not change again. Re: library dependencies, if you follow the LSB rules this will also be a non-issue. Though the LSB doesn't cover C++ yet due to the historical lack of ABI commitment from the gcc project, that problem should be solved pretty quickly now that there is commitment. So for now users do need to install a compat-libstdc++ in order to run C++ binaries from 7.3 on 8 or 9. However if they install compat-libstdc++ then all 7.3 C++ binaries should run fine. Again that issue should vanish both due to future C++ ABI stability, and the expansion of LSB to cover C++. (Assuming app developers create LSB-compliant packages.) The point about LSB if it isn't clear is that your app package depends simply on "LSB" which in turn implies that the system has a specific set of ABIs available. Havoc
