1

I'm using a relatively modern compiler which links against newer versions of certain libraries, as you may already know that happens.

Because of this, I need to link against certain older functions in GLIBC, one of them being fcntl. Currently, the application and its dependencies are being linked against fcntl@GLIBC_2.28, I require them all to be linked against fcntl@GLIBC_2.4.

Of course in my own source files, I can add __asm__(".symver fcntl,fcntl@GLIBC_2.4");, but is there a way to overwrite these functions with an older version altogether? If I were able to overwrite each function call via my CMakeLists.txt or something similar, I wouldn't need to add source code to external libraries, such as git repositories.

Is there a way to achieve this?

Tl;Dr: I'm looking for a way to globally overwrite each call to fcntl with fcntl@GLIBC_2.4.

SimonC
  • 1,547
  • 1
  • 19
  • 43
  • You could build the version of glibc you want to use yourself and dynamicly link against that version. [like described here](https://stackoverflow.com/questions/2856438) – t.niese Jul 09 '20 at 14:01
  • 1
    Picking functions from multiple different versions of glibc might be ill advised. If you want to specify the version for the entire library then https://stackoverflow.com/questions/2856438/how-can-i-link-to-a-specific-glibc-version might serve. For an individual function you could simply take the source from the library version in question and compile and link it as part of the project, the symbol will override any found in the library. – Clifford Jul 09 '20 at 14:23

1 Answers1

1

Of course in my own source files, I can add __asm__(".symver fcntl,fcntl@GLIBC_2.4");

Playing with ABI like this can cause all sorts of runtime issues, from runtime crashes, to memory leaks, to stack overflows.

There is a reason the symbol version was changed. You are using newer headers with older runtime, and your program is squarely in undefined behavior land.

The proper ways to do that is to use correct build environment. More info here.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Luckily I develop software for specific hardware and software, so the risk is minimal and always checked. Nonetheless, thank you for the advice :) – SimonC Jul 11 '20 at 17:48
  • @SimonC Even with specific hw and sw, I am not sure why the risk is minimal using headers and runtime that don't match. "Always checked"? I am not sure what you mean by this, but even a product that has undergone a lot of testing can fail in the field in specific situations that never occurred in the lab. I suggest not dismissing this advice so quickly. – Basya Jul 12 '20 at 10:30