building a binary on one system for running one another
All, I'm building apps on a system with glibc 2.4 - how do I build a binary targetted for a system with glibc 2.3.2? (for instance). /Per Jessen, Zürich
Hi there, On Mon, 24 Jul 2006, 12:39:35 +0200, Per Jessen wrote:
All,
I'm building apps on a system with glibc 2.4 - how do I build a binary targetted for a system with glibc 2.3.2? (for instance).
I use build.rpm for this. Make sure, the package is installed and then look at the included manual page; further information around similar build issues/requirements can be found at http://www.novell.com/coolsolutions/feature/11793.html http://en.opensuse.org/SUSE_Build_Tutorial
/Per Jessen, Zürich
HTH, cheers. l8er manfred
Manfred Hollstein wrote:
http://www.novell.com/coolsolutions/feature/11793.html http://en.opensuse.org/SUSE_Build_Tutorial
Interesting links, thanks.
HTH, cheers.
Hi Manfred, what I am after is more like gcc and/or linker flags - these are my own applications, my own code - doesn't belong to any package. Another similar question- on my development system, I currently have libmysqlclient 0.15 installed - but the target system is still on 0.14. Preferably I would build my app such that it is linked against libmysqlclient.so without any version indication, but it seems to default to using the full name: ldd: linux-gate.so.1 => (0xffffe000) libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 (0xb7dae000) libpcre.so.0 => /usr/lib/libpcre.so.0 (0xb7d82000) libclamav.so.1 => /usr/lib/libclamav.so.1 (0xb7d37000) libz.so.1 => /lib/libz.so.1 (0xb7d25000) libc.so.6 => /lib/libc.so.6 (0xb7c04000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7bd1000) libnsl.so.1 => /lib/libnsl.so.1 (0xb7bbc000) libm.so.6 => /lib/libm.so.6 (0xb7b97000) libbz2.so.1 => /lib/libbz2.so.1 (0xb7b86000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7b72000) /lib/ld-linux.so.2 (0xb7f04000) /Per Jessen, Zürich
Hi Per, On Mon, 24 Jul 2006, 13:23:15 +0200, Per Jessen wrote:
Manfred Hollstein wrote:
http://www.novell.com/coolsolutions/feature/11793.html http://en.opensuse.org/SUSE_Build_Tutorial
Interesting links, thanks.
HTH, cheers.
Hi Manfred,
what I am after is more like gcc and/or linker flags - these are my own applications, my own code - doesn't belong to any package.
OK. For such scenarios I built my own cross compilers and libraries in the past which made me independant from the actual target system; from a consistency and reproduceability point of view, this is probably the right way. This is how I structured the stuff /opt/gnu/packages/ gcc-2.95.3/{bin,lib,...} gcc-3.3.2/{bin,lib,...} glibc-2.0.5/{...} glibc-2.2.4/{...} ... For gcc it then comes down to adding suitable -I/opt/gnu/packages/glibc-2.2.4/include ... parameters to your CFLAGS; provided you only want to create statically linked executables, the situation is similar: adding -L/opt/gnu/packages/glibc-2.2.4/lib -llib would suffice. 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... Finding shared libraries at runtime can be achieved by (a) setting LD_LIBRARY_PATH to contain the corresponding directories, or (b) setting LD_RUN_PATH at compile time. Many people don't like (b), because you define at build time where libraries have to be located on the actual target system at runtime; I don't have a problem with that because I _can_ control that aspect. 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.
Another similar question- on my development system, I currently have libmysqlclient 0.15 installed - but the target system is still on 0.14. Preferably I would build my app such that it is linked against libmysqlclient.so without any version indication, but it seems to default to using the full name:
I doubt that this is possible unless you build libmysqlclient.so to not include any version number in its soname; but then it's impossible to have more than one version of a shared library installed and usable... HTH, cheers. l8er manfred
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
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
participants (2)
-
Manfred Hollstein -
Per Jessen