similar to: Targeting old glibc

Displaying 20 results from an estimated 1000 matches similar to: "Targeting old glibc"

2020 Oct 28
2
Targeting old glibc
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
2020 Nov 11
2
Targeting old glibc
On Tue, Nov 10, 2020 at 7:01 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > How to find what is pulling libmvec? > > If you build a -DCMAKE_BUILD_TYPE=Debug lld, you can set a breakpoint > on lld/ELF/MarkLive.cpp:114 (ss->getFile().isNeeded) and check which > symbol makes > libmvec.so needed. I'm afraid this is going to far for me :) > > On the other
2020 Nov 11
2
Targeting old glibc
It did partially fix the issue but there is still one problem: 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
2020 Nov 09
2
Targeting old glibc
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 >
2020 Nov 10
2
Targeting old glibc
Thank you very much for your help Fāng-ruì Sòng. I've tried various things like linking directly to libm-2.32 but it didn't work, it seems that libm-2.32 still pulls libmvec. I have the following linker flags: CLANG_LDFLAGS="-fuse-ld=lld -static-libstdc++ -static-libgcc -fvisibility=hidden -fdata-sections -ffunction-sections" CLANG_LDFLAGS="$CLANG_LDFLAGS
2020 Nov 09
0
Targeting old glibc
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
2020 Nov 11
0
Targeting old glibc
On 2020-11-11, Alexandre Bique wrote: >It did partially fix the issue but there is still one problem: > >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: >
2020 Nov 11
0
Targeting old glibc
This did the job: patchelf --clear-symbol-version log Podolski.64.so Alexandre Bique On Wed, Nov 11, 2020 at 2:19 PM Alexandre Bique <bique.alexandre at gmail.com> wrote: > > On Tue, Nov 10, 2020 at 7:01 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > > How to find what is pulling libmvec? > > > > If you build a -DCMAKE_BUILD_TYPE=Debug lld, you can
2020 Nov 10
0
Targeting old glibc
On Tue, Nov 10, 2020 at 12:27 AM Alexandre Bique <bique.alexandre at gmail.com> wrote: > > Thank you very much for your help Fāng-ruì Sòng. > > I've tried various things like linking directly to libm-2.32 but it > didn't work, it seems that libm-2.32 still pulls libmvec. > > I have the following linker flags: > > CLANG_LDFLAGS="-fuse-ld=lld
2020 Nov 09
2
Targeting old glibc
No. A shared object is needed if it is linked in (1)--no-as-needed mode or (2) after --gc-sections, a symbol referenced by a live input section is defined by the shared object. You'll need to check whether a symbol is defined by libmvec.so.1 On Mon, Nov 9, 2020 at 9:57 AM Alexandre Bique <bique.alexandre at gmail.com> wrote: > > On Mon, Nov 9, 2020 at 6:52 PM Fāng-ruì Sòng
2017 Jan 23
2
undefined symbols during linking LLDB 4.0 RC1
Hi Pavel, thank you for you response. objdump -T showed that there are no symbols defined in liblldb.so. After few compilations I found that problem is with linking with LLD (-DLLVM_ENABLE_LLD=ON) without the directive everything is ok. Hana ============= $ objdump -T lib64/liblldb.so lib64/liblldb.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: 0000000000000000 w D *UND*
2018 Feb 08
3
Issues with NVidia video driver and CentOS
On 08/02/18 15:10, Felipe Westfields wrote: > I copied the error message exactly as it was on the screen > As John said, you are mistaken: $ rpm -qp --requires nvidia-x11-drv-304xx-304.135-1.el6.elrepo.x86_64.rpm /bin/sh /bin/sh /bin/sh /bin/sh /bin/sh /sbin/ldconfig /usr/bin/python config(nvidia-x11-drv-304xx) = 304.135-1.el6.elrepo grubby grubby libGL.so.1()(64bit)
2008 May 07
1
[BioC] RCurl loading problem with 64 bit linux distribution
Martin, Well, thanks for jumping in! We need all the help we can get ;) I changed the execute bit as you suggested and recompiled, no luck, still the same error message. Below is the output you wanted me to look at, its a bit beyond me so I include both a brief grep summary and then the whole enchilada. I do note that my output is different from yours, but I'm not sure how to interpret. I
2008 May 07
1
[BioC] RCurl loading problem with 64 bit linux distribution
Martin, Well, thanks for jumping in! We need all the help we can get ;) I changed the execute bit as you suggested and recompiled, no luck, still the same error message. Below is the output you wanted me to look at, its a bit beyond me so I include both a brief grep summary and then the whole enchilada. I do note that my output is different from yours, but I'm not sure how to interpret. I
2017 Feb 22
2
[lld] elf linker creates undefined empty symbol
Rafael, here is a repro.tar to look at: https://reviews.llvm.org/F3100177 The attached foo.diff adds a print which shows the issue. ``` NAME: sleep SYMINDEX: 2 NAME: sched_yield SYMINDEX: 1 NAME: __libc_start_main SYMINDEX: 0 ``` `readelf --relocs` Shows that we create : ... 000000255110 002900000007 R_X86_64_JUMP_SLO 0000000000254410 __xstat at GLIBC_2.2.5 + 0 000000255118 001e00000007
2010 May 15
2
febootstrap failure
On Fri, May 14, 2010 at 11:02:36PM -0400, Aron Griffis wrote: > Hi again Rich, > > I'm trying to use febootstrap to install either rawhide or f13, > but my attempts are failing. > > $ sudo febootstrap fedora-13 /mnt/jubjub-f > ... > Running rpm_check_debug > ERROR with rpm_check_debug vs depsolve: > libc.so.6()(64bit) is needed by procmail-3.22-25.fc12.x86_64
2015 Jan 20
3
[LLVMdev] strlen in fast-isel
It seems that fast-isel for intel does not handle strlen. It's a general problem in fast-isel . ~/llvmw/build/Deb~/llvmw/build/Debug+Asserts/bin/clang -O0 -mllvm -fast-isel-verbose -mllvm -fast-isel strlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' printf("%i\n", len); ^
2019 Aug 07
2
C7 Kernel module compilation
Il 07/08/19 01:02, Phil Perry ha scritto: > On 06/08/2019 14:45, Alessandro Baggi wrote: >> Il 05/08/19 20:07, Akemi Yagi ha scritto: >>> On Mon, Aug 5, 2019 at 9:21 AM Alessandro Baggi >>> <alessandro.baggi at gmail.com> wrote: >>>> >>>> Il 05/08/19 18:07, Akemi Yagi ha scritto: >>>>> On Mon, Aug 5, 2019 at 9:01 AM Alessandro
2010 Oct 07
1
Linux 64-bit R installation problem - "Failed dependencies"
I am trying to install 64 bit R on Linux. But I got the following error - rpm -i R-core-2.10.0-2.fc11.x86_64.rpm warning: R-core-2.10.0-2.fc11.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 97d3544e error: Failed dependencies: /bin/bash is needed by R-core-2.10.0-2.fc11.x86_64 /bin/sh is needed by R-core-2.10.0-2.fc11.x86_64 /sbin/ldconfig is needed by
2019 Aug 08
2
C7 Kernel module compilation
Il 07/08/19 20:15, Akemi Yagi ha scritto: > On Wed, Aug 7, 2019 at 9:00 AM Alessandro Baggi > <alessandro.baggi at gmail.com> wrote: >> >> Il 07/08/19 01:02, Phil Perry ha scritto: >>> On 06/08/2019 14:45, Alessandro Baggi wrote: > >>> Please post the actual error message in dmesg or /var/log/messages. >>> >>> It's likely that the