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