On Wed, 26 Jul 2006, 10:03:15 +0200, Per Jessen wrote:
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".
The name is passed by gcc; try linking a small program with the "-v" flag given to gcc. You'll see gcc defines what the name of the dynamic linker is: ... -dynamic-linker /lib/ld-linux.so.2 ... IIRC, this is hardcoded into the gcc executable, but can be overridden using a spec file.
How do I specify that I only need glibc 2.3.2 even if the binary was built against 2.4?
This is not possible out of the box; using some version scripts might help, but it's not worth the hassle, and it's very error-prone.
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?
Absolutely! The build environment carries a chroot'ed directory containing _just_ those libraries (and executables such as gcc, binutils) you want to build with/for.
/Per Jessen, Zürich
HTH, cheers. l8er manfred