How to avoid STT_GNU_IFUNC symbols in your binary?

Question

I need to deploy to a Red Hat 4.1.2 box (which has gcc 4.1.2). I use GCC 4.6.1 on Ubuntu 11.10 for development. Unfortunately some of the binaries that my build process creates are not usable on the RedHat machine. The reason seems to be an ABI change, which according to another Stackoverflow question resulted from the introduction of STT_GNU_IFUNC symbols. Is there a way to prevent exporting any such symbols so that my binary can use the old ABI? I used nm to look for any symbols of "i" type on my binary but found none.

I ask this because some of my other binaries as well as some 3rd party libs I build (tbb, boost) are not using the new ABI and so run fine on the RedHat machine.

Hope that is clear. Thanks in advance.

Anachronistic

Answer 1

In general, UNIX systems support backward binary compatibility (a binary built on an old machine continues to run on a newer one), but not the reverse. You can't expect a binary built on a new system to run on an older one. STT_GNU_IFUNC is only the first of many problems you'll encounter.

If you need to build a binary on a newer machine that will run on an older one, see this document.

There used to be "apgcc: A GCC wrapper to make portable binaries" that made this easy (it's referenced from above), but it appears to be gone ;-(

The easiest option is to build on an old machine (I used to build on RedHat 6.2, and the resulting binary ran everywhere). You don't have to actually run RH-6.2 on a physical machine, just bring it up in a VM.

The other relatively easy option is to build in a chroot, again using tools and libraries from an old distribution (e.g. RH-6.2).

Vigilance

Thanks, that is what I feared. The trouble is that my build environment is taking advantage of relatively new features of python and gcc. I'll have to tone that down. – Anachronistic

You usually can build a new Python and GCC on an old machine, and then user them. The version of GCC doesn't matter that much for portability of the resulting library; only the version of glibc does. – Vigilance

@EmployedRussian you marked my question as a duplicate (#54533315) to this question which it isn't. Please remove the [duplicate] mark or consider an appropriate answer. – Eudo

I am questioning the rationale of using a chroot. For all practical purposes the linking to the newest symbols (if we cut .symver out of the discussion) happens at link-time (i.e. when the executable gets linked). This means you could just as well give the linker an older libc.so and point it there -rpath-link. While this causes issues whenever you are using newer symbols than available, I think we can agree that the whole point of this exercise is to limit yourself to older symbols and dynamically link to an equally old version of those available. – Ululant

Answer 2

Cross-compiling to an older linux can be very difficult, and this is only one of many problems you will encounter.

That said, the ABI compatibility problem can be solved by adding -Wl,-fno-jump-tables.

Mcallister

Could you please elaborate what exactly this solves? Do you mean that this erases the effect GNU_IFUNC has on an ELF? – Ululant

Answer 3

As APGCC does not seem available anymore (except perhaps here and here). These glibc headers seem to currently be the most convenient way to generate portable Linux binaries from a C code by including one of the older header files.

Maupassant

Have you verified that this works with static libraries? That is: static libraries typically only contain the bare function name they want to reference. But say I have a static library referencing memcpy and in my own code (.c files, .S ...) I take care to tell the assembler of my desire to use [email protected] (on amd64), will the object files from the static lib also reference [email protected] or will they reference the newest memcpy (i.e. [email protected])? – Ululant