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

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

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