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

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

[Alexandre Bique]

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

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

[Szabolcs Nagy]

The 11/15/2020 12:07, Alexandre Bique via Libc-help wrote:
> 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.

works for me.

obviously you need to change the version numbers
to actual valid versions, which is target dependent
so i cannot advise unless you specify the target abi.
(some targets are introduced later than 2.2.5 or
have different symbol versions for other reasons)

you can check the available versins with nm or readelf

nm --with-symbol-versions -D /path/to/libm-version.so |grep exp@

> 
> 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.

i'm not sure what you gain by not using an
old runtime system to do the build: all
dependencies have to be built with the old
symbol versions otherwise you can end up with
a plugin that's incompatible with whatever
other library is loaded.

i.e. your hack is less reliable than using
an old system. (you can use a new compiler,
but the libraries have to be old).

> 
> 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

if there are no dependencies then i think
this should work.

> As a side note, I wonder if GLIBC-2.29 is not pulled by libmvec which
> is implicitely pulled now?

may be, but if the binary is linked against
libmvec then you already have a problem: old
systems won't have libmvec.

in any case trying to build against new libs
but pretend to be built against old ones won't
be reliable no matter what you do.

> 2. sysroot approach

i think you should be able to get an old system
and rebuild the compiler (assuming you want a
new compiler) e.g. in a mount namespace (container)
or chroot or vm. and then do your build there.

(the compiler has to be configured with the
right version of the runtime libraries otherwise
it can be broken)