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

Szabolcs Nagy szabolcs.nagy@arm.com
Mon Nov 16 11:48:56 GMT 2020


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)


More information about the Libc-help mailing list