On Wed, 18 May 2005 15:13:41 +0200, Jakub Jelinek wrote: > Compiler built in presence of dl_iterate_phdr creates binaries and shared > libraries, that rely on its presence in target glibc, as support code > for older glibc's is intentionally left out in that case.
Why is that? Is the support code for older glibcs really that large? > BTW, all glibc versions are really only backwards compatible, not forward > compatible, new symbols are added through symbol versioning all the time. Yes I know, I don't think this versioning system works very well to be honest - it has a lot of problems (I think this was discussed on fedora-devel-list some time ago). It's possible to work around this using problem using auto-generated headers with .symver directives in though. > You can always install into a chroot an older distribution and > compile/link programs in there if you want one library or binary to work > with multiple OS releases. Well, maintaining a separate build box (which is what this chroot thing is equivalent to) is very painful: - Old system == old libs that maybe your users no longer have, for instance your binary may end up depending on an old libncurses.so.4 file when 99% of your users actually have libncurses.so.5, so you have to manually upgrade bits of the system which breaks package management and you end up with a frankenstein box where you aren't sure what's on it. For any complex app with lots of dependencies you need good testing to ensure this sort of "accidental dependency" doesn't become a problem. - No security updates for old systems - Old system means old compilers and headers that maybe can't compile your new code The biggest problem really is that this sort of thing is a lot of effort for your average evenings-and-weekends open source hacker who wants to distribute Linux binaries to his end users. Setting up and maintaining a dedicated build box or chroot is an awful lot of work for these people, even if it's do-able by commercial developers. It's also something Windows and Mac developers don't have to do, and therefore don't expect (and they don't understand what they did wrong when the problems inevitably appear). I'd really love to see a proper debate on the merits of this backwards-compatible-only policy. It seems many of the things that cause binaries built on new systems to not work on older ones are just the toolchain automatically enabling optimisations and new features. That's fine for people who compile everything themselves or use only RPMs built for their exact distro version, but it's a problem for developers who would rather have easy binary portability than these optimisations and features. Even just a -frun-on-older switch would be great news for people like me who distribute Linux binaries. thanks -mike
