search for: libs

Hello, I am building LLVM with ninja on Linux environment and I continue to have the error below. I am thinking that the cause might be my PC not having sufficient RAM memory. In this sense, I extended my swap memory with a swap file (90GB), but it didn't solved the problem. Should I add more physical RAM memory to my PC, or is there any software based solution I can try first? Thank you and

Hi, On a 1296-core Intel machine with 376 GB, setting -DLLVM_PARALLEL_LINK_JOB=1 does not help (switching back to ld scales) see: [5085/5201] Linking CXX executable bin/clang-11 FAILED: bin/clang-11 : && /home/usr4/c74014i/opt/clang/current/bin/clang++ -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra

Alex : Can you please try `numactl` or `taskset` after https://github.com/llvm/llvm-project/commit/09158252f777c2e2f06a86b154c44abcbcf9bb74 ? There was a tiny bug in how sched_getaffinity() was used, see: https://reviews.llvm.org/D75153#1942336 De : Alex Brachet-Mialot <alexbrachetmialot at gmail.com> Envoyé : March 28, 2020 12:11 PM À : Itaru Kitayama <itaru.kitayama at gmail.com>

Hi, My configuration is below: cmake -GNinja -DLLVM_ENABLE_LLD=ON -DLLVM_ENABLE_THREADS=OFF -DLLVM_ENABLE_LIBCXX=ON -DCMAKE_BUILD_TYPE=Release -DGCC_INSTALL_PREFIX=/home/usr4/c74014i/opt/gcc-7.5.0/ -DLIBOMPTARGET_ENABLE_DEBUG=ON -DCMAKE_INSTALL_PREFIX=$HOME/opt/clang/${today} -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="" -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_FLAGS=""

$ free -g total used free shared buff/cache available Mem: 376 149 20 1 207 225 Swap: 3 0 3 Too small swap size for a 72-core login machine? On Sun, Mar 29, 2020 at 4:28 AM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Enable threads is for building llvm with

Trying to run make to build llvm, I faced the following error: Linking CXX shared library ../../lib/libLTO.so collect2: error: ld returned 1 exit status make[2]: *** [lib/libLTO.so.3.8.0svn] Error 1 make[1]: *** [tools/lto/CMakeFiles/LTO.dir/all] Error 2 make: *** [all] Error 2 So, what's the problem here? Regards, Marwa Yusuf Teaching Assistant - Computer Engineering Department

~/Documents/llvm-project/build$ ninja After over 2,000 files compiled. [25/1074] Linking CXX executable bin/llvm-lto FAILED: bin/llvm-lto : && /usr/bin/clang++  -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long

That is slowing down the build visibly, for the speed I should stick with ld at the moment. On Sun, Mar 29, 2020 at 4:42 AM Alexandre Ganea <alexandre.ganea at ubisoft.com> wrote: > Would `taskset -c 0-3 ninja check-all -j4` work? > > > > *De :* Itaru Kitayama <itaru.kitayama at gmail.com> > *Envoyé :* March 28, 2020 3:37 PM > *À :* Alex Brachet-Mialot

Good news, I was able to use up to 37 cores for LLVM build with LLD. The build speed, did not measure precisely though, is comparable to the build with GNU ld case. Thank you all for your help! On Sun, Mar 29, 2020 at 5:04 AM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Yes unfortunately that would limit you to 4 cores. > > There’s no easy way to use lld with

On 2020-03-29, Nemanja Ivanovic via llvm-dev wrote: >Glad you got it working. >My suggestion about LLVM_ENABLE_THREADS didn't work because you didn't >apply it when building the build linker. > >When you don't have the ability to rebuild the build compiler, this doesn't >apply. In those cases, I end up doing a dirty hack where I use a wrapper >script with

The build failed. CHANGES ------- Revision 8671 committed by bitsweat on 2008-01-19 03:45:24 Support aggregations in finder conditions. Closes #10572. M /trunk/activerecord/test/cases/finder_test.rb M /trunk/activerecord/CHANGELOG M /trunk/activerecord/lib/active_record/aggregations.rb M /trunk/activerecord/lib/active_record/base.rb TEST FAILURES AND ERRORS -----------------------

This is release_50 branch of git, sha1: f1d5723be3f9456a6b16cdf687847ac2918846de Using gcc 7.2.0 from homebrew. $ CC=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-gcc-7 CXX=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-g++-7 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/Users/andy/local/llvm5 -DCMAKE_PREFIX_PATH=/Users/andy/local/llvm5 $ make VERBOSE=1 [ 92%] Linking CXX

TB --- 2013-10-31 19:50:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-10-31 19:50:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-31 19:50:43 - starting RELENG_10 tinderbox run for i386/pc98 TB --- 2013-10-31 19:50:43 - cleaning the

On 04/01/2020 01:47 PM, Itaru Kitayama via llvm-dev wrote: > Thanks for the heads up the supercomputer > Is down for maintenance this week. > I’ll give it a try when it gets back. > This doesn't look to me like it's necessarily an lld issue. Trying to build all the sub-projects without limiting the number of ninja jobs is almost guaranteed to run out of memory on a machine

...625 /usr/lib/R/lib/libR.so 00336000-003cd000 rwxp 00336000 00:00 0 003cd000-003d5000 r-xp 00000000 08:05 683486 /lib/libnss_files-2.4.90.so 003d5000-003d6000 r-xp 00007000 08:05 683486 /lib/libnss_files-2.4.90.so 003d7000-003f5000 r-xp 00000000 08:05 1045723 /usr/lib/R/library/grDevices/libs/grDevices.so 003f5000-003f6000 rwxp 0001d000 08:05 1045723 /usr/lib/R/library/grDevices/libs/grDevices.so 003f6000-003fc000 r-xp 00000000 08:05 1046746 /usr/lib/R/library/methods/libs/methods.so 003fc000-003fd000 rwxp 00005000 08:05 1046746 /usr/lib/R/library/methods/libs/methods.so 003fd000-004000...

The build failed. CHANGES ------- Revision 8649 committed by gbuesing on 2008-01-16 20:07:10 Introducing DateTime #utc, #utc? and #utc_offset, for duck-typing compatibility with Time. Closes #10002 M /trunk/activesupport/CHANGELOG M /trunk/activesupport/lib/active_support/core_ext/date_time/calculations.rb M /trunk/activesupport/test/core_ext/date_time_ext_test.rb TEST FAILURES AND

​Hi again, Teresa. Looks like I had forgotten to report back with success when finally building 3.9.0 in ThinLTO linker mode back in October. Sorry about that and thanks for helping me out. I know how important it is to get success reports as well, as a developer myself, so sorry again :(. While that worked back then, last weekend I tried to build 3.9.1 using 3.9.0 as installed from Arch Linux

On another login node which is 256 (GB)/48 (nodes) JURECA at JSC, I never had an LLD issue without setting -j when executing ninja in the past few weeks. On Thu, Apr 2, 2020 at 7:17 AM Itaru Kitayama <itaru.kitayama at gmail.com> wrote: > Tom, > Then what ratio do you think it’s minimal? > > On Thu, Apr 2, 2020 at 6:11 Tom Stellard <tstellar at redhat.com> wrote: >

...x-gnu/libnsl-2.13.so0019d000-0019e000 r--p 00015000 08:01 5243846 /lib/i386-linux-gnu/libnsl-2.13.so0019e000-0019f000 rw-p 00016000 08:01 5243846 /lib/i386-linux-gnu/libnsl-2.13.so0019f000-001a1000 rw-p 00000000 00:00 0 001a1000-001a5000 r-xp 00000000 08:01 5113047 /usr/lib/R/library/tools/libs/tools.so001a5000-001a6000 r--p 00003000 08:01 5113047 /usr/lib/R/library/tools/libs/tools.so001a6000-001a7000 rw-p 00004000 08:01 5113047 /usr/lib/R/library/tools/libs/tools.so001ab000-00323000 r-xp 00000000 08:01 5243840 /lib/i386-linux-gnu/libc-2.13.so00323000-00325000 r--p 00178000 08:0...

...e/ -------------- next part -------------- libtool: link: x86_64-w64-mingw32-g++ -shared -nostdlib D:/bda-ci/msys2/unstable/mingw64/lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/lib/../lib/dllcrt2.o D:/bda-ci/msys2/unstable/mingw64/lib/gcc/x86_64-w64-mingw32/6.3.0/crtbegin.o api/.libs/compactor.o api/.libs/constinfo.o api/.libs/decvalwtsource.o api/.libs/documentvaluelist.o api/.libs/editdistance.o api/.libs/emptypostlist.o api/.libs/error.o api/.libs/errorhandler.o api/.libs/expanddecider.o api/.libs/keymaker.o api/.libs/leafpostlist.o api/.libs/matchspy.o api/.libs/omdatabase....