* Derek Ch: >> Beyond glibc, few libraries pay careful attention to backwards >> compatibility, so it is generally recommended to recompile >> applications with the distribution toolchain and ship multiple builds, >> one for each distribution. > the problem here is the burden to maintain multiple development > environments, in most cases the production environment is more > conservative than development, which means lower library versions; if > users have to set up a lower version gcc/glibc from the older distro > same as the production environment, will be no incentive to set up the > newer distro as another dev env, newer gcc; pbuilder, sbuild, and mock are quite straightforward to set up (for the community-supported distros) and use, which means that maintaining multiple development environments isn't *that* difficult. Learning proper packging is more work (and required to use to the distribution build tools), but it's really worth it. This won't give you access to newer compilers for production builds. But Red Hat and SuSE provide newer compilers which you can install on top of an older operating system and which produce binaries for that operating system. For Debian, no backports of the system GCC currently exist. If you need just a solution for your specific applications, just recompiling gcc-5 from sid and putting it into your build environment might do the trick. > While today I'm looking at the LD Version Scripts, wonder is it possible to > make a special version script, to ask gcc link with a different version of the > symbols? That might work for memcpy, where the new version wasn't really needed. But in other cases, you'd have to use older header files to compile applications (and tools like pbuilder and mock provide such build environments). Just tweaking symbols will break things horribly. After all, new symbol versions are usually introduced to avoid such breakage (again, memcpy is an outlier here).
