On Wed, Apr 09, 2003 at 09:56:59AM -0500, Shawn wrote: > On Tue, 2003-04-08 at 21:03, Havoc Pennington wrote: > > 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. ;-) > > I tend to stray towards the ANSI standard consistently so I don't do > things like that, however the libraries I use aren't always as nice :( > Well, that's sort of a social/organizational problem; if the libs are actively maintained they need fixing, if they aren't actively maintained you are in trouble in any case... There's a reason the stuff that's not in the official ABI isn't in the official ABI - it's known that it will break and that future progress depends on it breaking. So if people use that stuff anyway, well, the only thing the glibc maintainers could really do to keep the apps working would be to stop making progress, for example keep slow/broken threads forever. To me, the glibc maintainers fill their end of the deal by giving fair warning about what not to use. > ./ags: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./ags) > ./ags: /lib/libc.so.6: version `GCC_3.0' not found (required by ./ags) > > For example the above came from one of my users, I'm guessing the above > means I need to somehow link against the compat-libstdc++ and use gcc296 > to compile the binaries instead of gcc3.2.2 included with RedHat 9. Ah, note that this problem is *not* related to backward compatibility; this is what's sometimes called "forward compatibility." The issue here is that if you build on < 9 and then run on 9, that would work, but if you build on 9 then run on < 9 it would not. This happens when new ABI is added, because the app gets linked to new ABI when it's available. This happens to at least some apps on pretty much every glibc upgrade I'm pretty sure. One solution is to build in a build root that contains your oldest target version. (A simple approach that I believe works is to install the old version to a separate partition, mount it, chroot into it, and build there. There may be some complexities in doing that but it's basically how we build packages at Red Hat.) The really obvious solution if you have an extra machine of course is to just install and boot the old version and build on that system. > > 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. > > But what about users of other distributions, such as Mandrake, Debian, > etc. honestly I'd love to say I don't care about them because I much > prefer RedHat, but that wouldn't make me very popular ;) Do they have > equivalent versions of compatability libraries for their > distributions? I think most distributions do provide compat libs, yes. > How does one go about specifying the compatability libstdc++ instead of > the normal one when using gcc296 or is that somehow automatic? You can't build against the compat libs, they are runtime-only, because to build against them you'd need headers. GTK+ is an example of a library that provides parallel compile environments - http://ometer.com/parallel.html - but that doesn't really work for libc. It's probably the right thing to do for most other libraries. > Should I static link against just libstdc++ and the obscure > libraries I use and dynamically link libc, libdl, libm, libpthread, > etc.? Yes, I think that would work well. Havoc
