linking to older glibc ABI

Hello, lazy web.

So, I have a program that’s linked against glibc 2.1.3 (I think). My system has glibc 2.3.3, but that’s OK because glibc (since glibc 2.1) also provides the older (partly incompatible) ABIs, so already-built software keeps running. Opinions differ about that, but that’s another vague discussion that you can have elsewhere.

But the program can uses a shared-library plugin that I provide. But if I build this shared library on this system then it will be linked against glibc 2.3.3, and it would surely be bad for a program that uses glibc 2.1.3 to use a library that uses glibc 2.3.3. So, how can I tell the linker to use the older glibc ABI instead of the latest ABI that glibc has to offer?

I am (stupidly, but it makes things simpler for now) ignoring the possibility of API changes which would require me to compile against the older glibc headers.

9 thoughts on “linking to older glibc ABI

  1. The stock glibc answer would be to build your plugin on a system with glibc 2.1.3 on it.

    However, is it really a huge problem if you link your plugin with 2.3.3, apart from the fact that you can only run it with glibc >= 2.3.3

  2. > However, is it really a huge problem

    Well, I was guessing that this might be the cause of a crash in this program (a new version of the program, which needs a new system with a new glibc), when using my plugin. But there are other possibilities.

  3. It shouldn’t matter what version the plugin is using — glibc 2.3.3 still provides the glibc 2.1.3 ABI, so your old program which uses the 2.1.3 ABI will be loading and using 2.3.3 anyway. The actual changes in ABI are mostly the introduction of new symbols, although sometimes already existing symbols are changed (but that doesn’t happen too often).

    Even so, if the existing ABI does change, it shouldn’t matter that the program and the plugin are using different ABI versions, unless you’re doing something really screwy (and you’ll have to ask Ulrich about those cases).

  4. Reply to Nicholas Miell:
    “It shouldn’t matter what version the plugin is using — glibc 2.3.3 still provides the glibc 2.1.3 ABI, so your old program which uses the 2.1.3 ABI will be loading and using 2.3.3 anyway.”

    This isn’t true. Glibc contains versioned symbols. For example, there’s a fnmatch@GLIBC_2.2 and fnmatch@GLIBC_2.3. But if you build an app on a glibc 2.3 system, it will use fnmatch@GLIBC_2.3. And gcc/glibc, in its infinite wisdom, doesn’t provide a way to force building against older symbols!
    And that’s where apbuild comes in.

  5. That’s not a problem. The entire point of versioned symbols is to let two ABI incompatible symbols with the same name end up in the same address space without everything breaking. In theory, the only downside to linking against glibc 2.3 is that your code will only run on glibc 2.3 or up machines in future – which isn’t a problem in this case.

    If mixing code built against glibc 2.1.3 and glibc 2.3 was an issue, Debian would be entirely fucked. We still have libraries that were last built in 2000 or so.

  6. I put some effort into looking in to this — you should be fine in almost every circumstance. The only thing likely to actually bite you in practice is if you’ve included pthread_cond_t somewhere in your library/application ABI and you’re mixing something built for LinuxThreads with something built for NPTL.

    If you realy want to see for yourself what changed, just grep the glibc source for the compat_symbol macro.

    (Note that mixing code built against different versions of libstdc++ is an entirely different matter and a source of never-ending problems. The fact that every new version of G++ requires a new version of libstdc++ should make you reconsider ever using G++ in an ELF environment.)

Comments are closed.