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_headerThank 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
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
On Mon, Nov 9, 2020 at 9:39 AM Alexandre Bique <bique.alexandre at gmail.com> wrote:> > 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.Recent libm.a and libm.so are actually linker scripts % cat /usr/lib/x86_64-linux-gnu/libm.a /* GNU ld script */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /usr/lib/x86_64-linux-gnu/libm-2.31.a /usr/lib/x86_64-linux-gnu/libmvec.a ) % cat /usr/lib/x86_64-linux-gnu/libm.so /* GNU ld script */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib/x86_64-linux-gnu/libm.so.6 AS_NEEDED ( /lib/x86_64-linux-gnu/libmvec.so.1 ) )> 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-- 宋方睿