[llvm-dev] Targeting old glibc

[Alexandre Bique via llvm-dev]

Hi,

So I managed to install llvm 11 on the server and got more information
thank to your help:

Projects/Podolski/CMakeFiles/Podolski.dir/__/__/AudioModulesFrame/AM_WavLoader.cpp.o:
reference to exp
Projects/Podolski/CMakeFiles/Podolski.dir/__/__/libs/tinyexpr/tinyexpr.c.o:
reference to exp
Projects/Podolski/CMakeFiles/Podolski.dir/__/__/AudioModulesFrame/AM_PitchTrack.cpp.o:
reference to exp
/usr/lib/libm.so.6: shared definition of exp at GLIBC_2.2.5
/usr/lib/libm.so.6: shared definition of exp
/usr/lib/libm.so.6: shared definition of exp at GLIBC_2.29
/usr/lib/libmvec.so.1: reference to exp at GLIBC_2.29

So the dependency is being pulled by libmvec.

Which is strange because the target is not using libmvec:

[jenkins at archear build-clang.64]$ ldd VstPlugins/libPodolski.so
linux-vdso.so.1 (0x00007ffccff47000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f2761062000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f2761040000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f276103a000)
libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007f2761031000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f2760eeb000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f2760d22000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f2761e3e000)
[jenkins at archear build-clang.64]$

I even recompiled with -fveclib=none but it did not change anything.
And I believe that -fveclib=mvec will start working with LLVM-12.

I have no idea what pulls libmvec in.

Regards,
Alexandre Bique

On Wed, Oct 28, 2020 at 6:23 PM Alexandre Bique
<bique.alexandre at gmail.com> wrote:
>
> On Wed, Oct 28, 2020 at 6:07 PM Fangrui Song <maskray at google.com> wrote:
> >
> > On 2020-10-28, Alexandre Bique via llvm-dev wrote:
> > >Hi,
> > >
> > >I wonder what is the right way to target an old glibc?
> > >
> > >I have a machine which is up to date (glibc 2.32 and clang+lld 10.0.1).
> > >
> > >So far I've been able to target older glibc by having a C file containing:
> > >
> > >__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");
> >
> > This works. This approach is used by https://github.com/wheybags/glibc_version_header
>
> Thank you, that is something useful!
>
> > >But after updating clang and re-creating the cmake build directory it
> > >does not work anymore and I have dependencies toward glibc 2.29:
> > >
> > >nm -D /home/abique/.u-he/Zebra2/Zebra2.64.so  | grep GLIBC.*29
> > >                 U exp@@GLIBC_2.29
> > >                 U exp2@@GLIBC_2.29
> > >                 U log@@GLIBC_2.29
> > >                 U pow@@GLIBC_2.29
> >
> > I reported a display problem. top-of-trunk binutils will display
> > undefined versioned symbols as @ instead of @@.
>
> Thank you, I wondered why there were two @.
>
> > >At first I thought that it was due to LTO, but even after disabling
> > >LTO the problem still occurs.
> > >
> > >How to solve it?
> > >Is there a better approach to this problem?
> > >
> > >Maybe lld never supported it, and now it is using lld to link instead
> > >of the GNU linker?
> >
> > LLD has good support for version symbols (you need a commit after https://reviews.llvm.org/D80059 (in 11.0.0, but not in 10.x)).
>
> I'm using Archlinux, and llvm 11 is in staging, I'll see if I can install it.
>
> > There is insufficient information to form a solution.
> > You may add -Wl,-y,exp,-y,exp at GLIBC_2.29,-y,exp at GLIBC_2.2.5 to figure
> > out why exp at GLIBC_2.29 instead of exp at GLIBC_2.2.5 is picked.
>
> Thank you very much. I'll try first with llvm 11 and if it does not
> work, I'll come back with more information.
>
> Regards,
> Alexandre