Manfred Hollstein wrote:
Using shared libraries is not that much more difficult with the exception of /lib/ld-linux.so.2, which is hard-coded into the executable...
This is sort of where my problem begins - if I check the ldd output: /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) but ld-linux.so.2 is a link to "ld-2.3.2.so" (on my target system). On my development system, it is a link to "ld-2.4.so". How do I specify that I only need glibc 2.3.2 even if the binary was built against 2.4? My overall environment is roughly like this: development+unit-test -> integration-test -> production. "Development" is typically a modern, up-to-date workstation, right now running SUSE 10.1, maybe even 10.2AlphaX in not so long. "Test" is also fairly modern, e.g. today it's a 9.0 system I believe, whereas "production" is a SUSE 8.2 system. I'm obviously developing code targetted for production with the libraries available there.
To be clear here, _today_ I prefer to build (even my own very private software) everything as an RPM; hence I suggested build.rpm initially.
Does that help you overcome "problems" such as this with different library levels? /Per Jessen, Zürich