Building using latest tools glibc but targeting older system (like ubuntu 14.xx)

[Alexandre Bique <bique.alexandre@gmail.com>]

Hi,

I have a build machine using Archlinux, which means that I enjoy the
latest tools. Yet I want to build VST plugins and then distribute them
with the maximum compatibility toward old systems. Those are the
plugins in question https://u-he.com/

This message follows up this thead on LLVM dev:
http://lists.llvm.org/pipermail/llvm-dev/2020-October/146122.html
I've the same issue with GCC and CLANG.

So far it worked well and I was using the .symver trick.

__asm__(".symver powf,powf at GLIBC_2.2.5");
__asm__(".symver expf,expf at GLIBC_2.2.5");
__asm__(".symver exp2f,exp2f at GLIBC_2.2.5");
__asm__(".symver log2f,log2f at GLIBC_2.2.5");
__asm__(".symver logf,logf at GLIBC_2.2.5");

__asm__(".symver log,log at GLIBC_2.2.5");
__asm__(".symver log2,log2 at GLIBC_2.2.5");
__asm__(".symver exp,exp at GLIBC_2.2.5");
__asm__(".symver exp2,exp2 at GLIBC_2.2.5");
__asm__(".symver pow,pow at GLIBC_2.2.5");


But recently it stopped working (after upgrading to glibc 2.32, I
don't remember which version I had before), and I've had some hard
dependencies toward GLIBC 2.29 that I can't explain.

I don't want to set up a build machine using Ubuntu 14.xx because I
would have to rebuild all the tools that I use (gcc, clang, jenkins,
...). I definitely want to use a modern and up to date system.

On OSX there is a compiler switch --target-platform=... and it is as
simple as that I believe. I would love to have such an option when
building on Linux.

I've tried a few approach:

1. Editing the elf dependencies

I actually don't need a special version of glibc / libm, I want to use
the latest exp symbol. I've added that to my build commands:
patchelf --clear-symbol-version exp Podolski.64.so

But at some point there are still left-over:

llvm-objdump -sx gives:

Version References:
  required from libpthread.so.0:
    0x09691a75 0x00 05 GLIBC_2.2.5
    0x09691972 0x00 09 GLIBC_2.3.2
    0x09691973 0x00 07 GLIBC_2.3.3
    0x06969192 0x00 12 GLIBC_2.12
  required from libdl.so.2:
    0x09691a75 0x00 21 GLIBC_2.2.5
  required from libuuid.so.1:
    0x09da27b0 0x00 19 UUID_1.0
  required from libm.so.6:
    0x09691a75 0x00 04 GLIBC_2.2.5
    0x06969187 0x00 06 GLIBC_2.27
    0x06969189 0x00 11 GLIBC_2.29
  required from libc.so.6:
    0x09691a75 0x00 03 GLIBC_2.2.5
    0x0d696913 0x00 14 GLIBC_2.3
    0x09691972 0x00 08 GLIBC_2.3.2
    0x09691974 0x00 17 GLIBC_2.3.4
    0x0d696914 0x00 16 GLIBC_2.4
    0x0d696917 0x00 13 GLIBC_2.7
    0x06969191 0x00 18 GLIBC_2.11
    0x06969194 0x00 15 GLIBC_2.14
    0x06969197 0x00 10 GLIBC_2.17
  required from ld-linux-x86-64.so.2:
    0x0d696913 0x00 20 GLIBC_2.3

There are no tools that I know which will let me remove the GLIBC_2.29
and GLIBC_2.27 dependencies from libm.
As a side note, I wonder if GLIBC-2.29 is not pulled by libmvec which
is implicitely pulled now?


2. sysroot approach

In order to build against a different sysroot, I've used debootstrap
to create a ubuntu 14.xx to link against but it did not work because
all the absolute paths and symlink are relative to the chroot and then
breaks.
I've tried to build against the oldest freedesktop SDK but it failed
for the very same issues.
I've tried to build an older glibc, but it does not compile because
-Werror meets some modern compiler improved warnings.
I would be very happy to have an option --syschroot, which would know
that the target path is a chroot, and would smartly deference absolute
symbolic and absolute path in linker scripts.


What do you suggest? How to solve my issue?

Many thanks for your help.

Regards,
Alexandre Bique