similar to: LibC++ tests in tree

Displaying 20 results from an estimated 8000 matches similar to: "LibC++ tests in tree"

2016 Jul 11
2
LibC++ failure on ARM
Hi Marshal, ARM has recently moved the buildslave from single test to with/without exception: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-arm-linux http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-arm-linux-noexceptions but both slaves have the same error that wasn't there before: ******************** TEST 'libc++ ::
2017 Jun 04
2
building llvm_Rel400 on Scientific Linux (RHEL) 7.3 x86_64
On Sat, 3 Jun 2017 16:04:57 -0700 Tim Northover <t.p.northover at gmail.com> wrote: [snip] > I think you should be able to fix it by changing the > compiler-rt/lib/xray/test/CMakeLists.txt. If you find the > "add_compiler_rt_test" call and move "-lstdc++" to the end, just after > "-lrt" it should work. Thanks, Tim. I don't see "-lrt":
2016 Jan 19
8
[3.8 Release] RC1 has been tagged
(cc'ing non-legacy llvm-dev this time; apologies if you get this twice. Please don't reply-all to the first one.) On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at chromium.org> wrote: > Dear testers, > > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at > r258223. (It took a little longer than I'd planned, sorry about that.) > > There
2017 Aug 01
2
ubsan no longer compiles when libc++ is the default
Hi, Trying to compile llvm with the following configuration on Linux x86-64: cmake -G Ninja -DBUILD_SHARED_LIBS=ON \ -DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=gold" \ -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=gold"\ -DCMAKE_BUILD_TYPE=RelWithDebInfo ' \ -DCMAKE_C_FLAGS="-O2 -g" \
2007 May 08
1
[LLVMdev] llvm-ld support of native libraries
What is the current status of llvm-ld's support of native libraries? I have a bytecode file that needs to link against librt.so. So, I ran: llvm-ld -native -o x.exe x.bc -L/usr/lib64 -lrt and I get the following error: /tmp/ccB7DGu1.o(.text+0x1a3): In function `main': : undefined reference to `clock_gettime' /tmp/ccB7DGu1.o(.text+0x6d8): In function `main': : undefined
2005 Mar 01
2
[LLVMdev] Re: question about gccld and external libraries
Misha Brukman wrote: > Hey, Jakob -- > > On Tue, Mar 01, 2005 at 05:55:07PM +0100, Jakob Praher wrote: > >>I'm really new to llvm. I've successfully bootstrapped llvm-14 on my >>system and am able to successfully compile c code to llvm. >> >>the problem is now that gccld is complaining that it can't find the >>libraries, like "c" or
2017 Aug 02
2
ubsan no longer compiles when libc++ is the default
Hi, I see the following variables in the CMakeCache.txt: SANITIZER_CXX_ABI:STRING=default //STRINGS property for variable: SANITIZER_CXX_ABI SANITIZER_CXX_ABI-STRINGS:INTERNAL=none;default;libcxxabi;libstdc++ Regards, ismail On Tue, Aug 1, 2017 at 7:32 PM, Vedant Kumar <vsk at apple.com> wrote: > >> On Aug 1, 2017, at 7:07 AM, İsmail Dönmez via llvm-dev <llvm-dev at
2005 Mar 01
0
[LLVMdev] Re: question about gccld and external libraries
On Tue, 1 Mar 2005, Jakob Praher wrote: > thanks for the pointer. Yes I've done that, but in the new shell session I > apparently forgot to set the LLVM_LIB_SEARCH_PATH. > > now gccld isn't complaining anymore but the interpreter doesn't seem to like > it still: It looks like the jit doesn't find these because they are located in librt. Try this (or adapt to
2017 Jun 05
3
libc++ failed to link against musl
I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain. The configuration is the following: LIBCXX_HAS_MUSL_LIBC=ON LIBCXX_HAS_GCC_S_LIB=OFF CLANG_DEFAULT_CXX_STDLIB=libc++ CLANG_DEFAULT_LINKER=lld CLANG_DEFAULT_RTLIB=compiler-rt LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl LLVM_TARGET_ARCH=x86_64
2017 Jun 03
2
building llvm_Rel400 on Scientific Linux (RHEL) 7.3 x86_64
Hi, I am trying to build the LLVM suite on a RedHat Enterprise Linux clone (Scientific Linux <https://www.scientificlinux.org/>). In the latest attempt, the build seems to complete without any explicit failures but the `check-all` process fails. Any ideas about what is wrong or suggestions for how to proceed would be much appreciated. This is the current procedure: sudo yum install
2015 Jul 08
2
[LLVMdev] Building clang + libc++ + libc++abi
[Sorry about the crosspost. Since this is a clang build question but the build is invoked from the top-level LLVM directory I'm not sure where the question should go.] I've got a clang build against libstdc++ on Linux but I would really like one built against libc++/libc++abi. In other words I'd like to rebuild clang/llvm with clang using libc++ and libc++abi on Linux. I looked at
2017 Dec 19
3
RFC: Default path for cross-compiled runtimes
Today, there're two different locations for runtimes files within Clang's installation: compiler-rt: headers: $prefix/lib/clang/$version/include(/sanitizer) libraries: $prefix/lib/clang/$version/lib/$os/libclang_rt.$name-$arch.$ext libc++, libc++abi, libunwind: headers: $prefix/include/c++/v1 libraries: $prefix/lib/$name.$ext The scheme used by libc++, libc++abi, libunwind
2015 Nov 25
2
"Failed to start domain..."
Sadly, I'm back with another issue. I can do a "system list --all" just fine; however, if I attempt to start the machines, I get back: maas@Bill-MAAS-cc:~$ strace -s 1024 -f -o /tmp/asdfasdf.log virsh -c vbox+ssh://gbadmin@10.20.0.1/system start PXE-client-07 error: Failed to start domain PXE-client-07 error: An error occurred, but the cause is unknown Log files on both client
2017 Dec 19
2
RFC: Default path for cross-compiled runtimes
On Tue, Dec 19, 2017 at 8:33 AM Jonathan Roelofs <jonathan at codesourcery.com> wrote: > On 12/19/17 9:15 AM, Petr Hosek via llvm-dev wrote: > > Today, there're two different locations for runtimes files within > > Clang's installation: > > > > compiler-rt: > > headers: $prefix/lib/clang/$version/include(/sanitizer) > > libraries: >
2013 Aug 03
2
Call for testing: OpenSSH-6.3
On 2013-08-03 01:41, Darren Tucker wrote: > On Sat, Aug 3, 2013 at 5:58 PM, Damien Miller <djm at mindrot.org> wrote: >>> Looking at failure logs - this is what's killing it: >>> clock_gettime: Invalid argument > [...] >> Maybe these platforms lack CLOCK_MONOTONIC? Darren, perhaps we should >> wrap clock_gettime and have a fallback for
2016 Jan 21
2
greendragon build noisy due to mmap_stress.cc
Ah ha! I found crash reports: green-dragon-03:DiagnosticReports buildslave$ cat mmap_stress.cc.tmp_2016-01-19-231335_green-dragon-03.crash Process: mmap_stress.cc.tmp [95010] Path: /Users/USER/*/mmap_stress.cc.tmp Identifier: mmap_stress.cc.tmp Version: 0 Code Type: X86-64 (Native) Parent Process: bash [95004] User ID:
2008 Feb 06
1
POSIX semaphores in CentOS 5.1?
According to the man pages for sem_wait, etc., POSIX semaphores are available in Linux 2.6 (with the right NTPL threading in glibc). However, I have a program that compiles just fine but won't link because it can't find the library for the semaphore operations. What am I missing? I ran a find and grep through all the libc's on the system and they turned up nothing: $ find /lib
2019 Jun 21
4
Memory overflow during cmake/ninja build
I'm trying to do a simple build from the git 8.0.0 sources. The sources seem to build OK but a link step fails from running out of memory. I need some clues how to figure out where the bottleneck might be. The cmake command is: cmake -G Ninja                                          \     -DLLVM_TARGETS_TO_BUILD=X86                         \    
2019 Mar 25
3
Trying to create a pure LLVM toolchain on musl based distribution
Hello, I'm trying to create a pure LLVM toolchain (that will not depend on GNU and produce GNU-free code too) on a musl based distribution. For now, I use gcc to bootstrap and build all LLVM components. I do it individually because I was running out of space and memory trying to build all using LLVM_ENABLE_PROJECTS. Also, I don't want to create a all-in-one package. Then, once
2016 Jan 20
2
greendragon build noisy due to mmap_stress.cc
On Wed, Jan 20, 2016 at 1:31 PM, Chris Matthews <chris.matthews at apple.com> wrote: > I worded that poorly, the Jenkins check I added will explain to the user > that we know this fails sometimes. > > On Jan 20, 2016, at 1:30 PM, Chris Matthews <chris.matthews at apple.com> > wrote: > > I have added a Jenkins check for this test, which explains why it fails on