similar to: [LLVMdev] cmake build system doesn't produce libLLVM-<major>.<minor>.so

Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] cmake build system doesn't produce libLLVM-<major>.<minor>.so"

2014 May 12
2
[LLVMdev] Lots of regtest failures on PPC64/Linux
----- Original Message ----- > From: "İsmail Dönmez" <ismail at donmez.ws> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, May 12, 2014 7:18:48 AM > Subject: Re: Lots of regtest failures on PPC64/Linux > > > Hi Hal, > > > > > > On
2014 May 12
2
[LLVMdev] Build failure with libcxx
Ok looks like r207606 regressed this. CC'ing Niko. Niko, please see the messages below. This is on openSUSE 13.1 both on i586 and x86-64. Reverting r207606 fixes the second stage bootstrap. On Sun, May 11, 2014 at 10:19 PM, İsmail Dönmez <ismail at donmez.ws> wrote: > I did a diff -u broken.ii working.ii and the difference explains the > problem: > > @@ -36617,7 +36628,7
2013 Nov 22
3
[LLVMdev] [3.4 branch] SystemZ regressions
Hi, On Thu, Nov 21, 2013 at 8:16 PM, Richard Sandiford < rsandifo at linux.vnet.ibm.com> wrote: > İsmail Dönmez <ismail at donmez.ws> writes: > > Using openSUSE 13.1 on s390x machine I get two new regressions with llvm > > 3.4rc1: > > Hmm, I don't see this locally. Just to rule out one possibility, > which compiler are you using to build? Do you see the
2014 Jun 04
2
[LLVMdev] Lots of regtest failures on PPC64/Linux
missing-abstract-variable is a recent one I introduced - looking into it. On Wed, Jun 4, 2014 at 2:39 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi Hal, > > These tests failures go away when I disable static libs aka > -DBUILD_SHARED_LIBS=OFF , with that only 2 regtest failures are left: > > > [ 1314s] FAILED: cd /home/abuild/rpmbuild/BUILD/llvm/stage2/test
2014 Apr 01
2
[LLVMdev] Lots of regtest failures on PPC64/Linux
Hi, On Tue, Apr 1, 2014 at 3:26 PM, Hal Finkel <hfinkel at anl.gov> wrote: > İsmail, > > I still don't see these errors locally. Can you try with an autoconf-based > build and see if they're somehow related to (triggered by) the way that > cmake builds LLVM? > > On the same machine autoconf build is fine where as cmake has failures, reproduced simply with
2014 Mar 26
3
[LLVMdev] Lots of regtest failures on PPC64/Linux
Hi, On Wed, Mar 26, 2014 at 3:26 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "İsmail Dönmez" <ismail at donmez.ws> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Wednesday, March 26, 2014 8:20:31 AM >
2014 Mar 26
3
[LLVMdev] Lots of regtest failures on PPC64/Linux
----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "İsmail Dönmez" <ismail at donmez.ws> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, March 26, 2014 8:14:18 AM > Subject: Re: [LLVMdev] Lots of regtest failures on PPC64/Linux > > Hi Ismail, > > Is
2013 Nov 26
0
[LLVMdev] [3.4 branch] SystemZ regressions
İsmail Dönmez <ismail at donmez.ws> writes: > On Thu, Nov 21, 2013 at 8:16 PM, Richard Sandiford < > rsandifo at linux.vnet.ibm.com> wrote: >> İsmail Dönmez <ismail at donmez.ws> writes: >> > Using openSUSE 13.1 on s390x machine I get two new regressions with llvm >> > 3.4rc1: >> >> Hmm, I don't see this locally. Just to rule out one
2014 Mar 26
2
[LLVMdev] Lots of regtest failures on PPC64/Linux
Hi Hal, On Wed, Mar 26, 2014 at 3:17 PM, Hal Finkel <hfinkel at anl.gov> wrote: > İsmail, > > These are self-hosted builds? It seems like a lot of crashes in > llvm::sys::AtomicIncrement. Yes. stage1 clang is used in stage2. -------------- next part -------------- An HTML attachment was scrubbed... URL:
2013 May 13
2
[LLVMdev] ASan unit test/libcxx build break
On Mon, May 13, 2013 at 11:03 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > > On Mon, May 13, 2013 at 10:49 AM, Evgeniy Stepanov > <eugeni.stepanov at gmail.com> wrote: >> >> A recent change added defined(__linux__) condition to the code below. >> Now it says that on linux with --std=c++0x (or --std=c++11) the system >> stdlib.h header
2014 Dec 12
2
[LLVMdev] [cfe-dev] Phabricator update
On Fri Dec 12 2014 at 12:55:01 PM İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > On Fri, Dec 12, 2014 at 12:05 PM, Manuel Klimek <klimek at google.com> wrote: > > Can you point me at an example? I've spot checked stuff and cannot see > > anything out of the ordinary... > > This is only visible in GMail for me but looks like Phabricator is now >
2015 Jan 30
2
[LLVMdev] ARM regression between r223766 and r223925
On Fri, Jan 30, 2015 at 7:27 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 30 January 2015 at 17:23, İsmail Dönmez <ismail at donmez.ws> wrote: >> No idea because I already had workarounded the original issue with >> -no-integrated-as. BUT my build script log shows that I successfully >> cross-compiled with NEON on December 4 2014. I usually do basic
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
2012 Apr 24
0
[LLVMdev] compiler_rt fails to build in release_31 branch
ping? Still fails on 3.1 branch. On Tue, Apr 17, 2012 at 5:35 PM, İsmail Dönmez <ismail at namtrac.org> wrote: > > Hi; > > This is on  Linux/x86-64, I get this at stage1: > > make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/llvm/stage1/projects/compiler_rt' > Makefile:6: make/config.mk: No such file or directory > Makefile:7: make/util.mk: No such file or
2013 May 13
0
[LLVMdev] ASan unit test/libcxx build break
Hi, On Mon, May 13, 2013 at 11:07 AM, Evgeniy Stepanov < eugeni.stepanov at gmail.com> wrote: > On Mon, May 13, 2013 at 11:03 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > > I am guessing you are running on this on an old system. My glibc version > is > > 2.17 > > Yes. Ubuntu 12.04 LTS with glibc 2.15 does not have aligned_alloc. > Then I guess
2015 Jan 30
0
[LLVMdev] ARM regression between r223766 and r223925
On 30 January 2015 at 17:23, İsmail Dönmez <ismail at donmez.ws> wrote: > No idea because I already had workarounded the original issue with > -no-integrated-as. BUT my build script log shows that I successfully > cross-compiled with NEON on December 4 2014. I usually do basic > testing of those builds on ARMv7. So, I suggest trying to bootstrap > r223339 with NEON. Thats the
2015 Jan 30
2
[LLVMdev] ARM regression between r223766 and r223925
On Fri, Jan 30, 2015 at 7:20 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 30 January 2015 at 17:18, İsmail Dönmez <ismail at donmez.ws> wrote: >> My analysis was completely wrong because I had -no-integrated-as >> sneaked in libcxxabi CMakeLists.txt and then somehow I reverted it >> which showed me the initial failure. The Neon failure is completely
2013 Oct 08
2
[LLVMdev] basic-arm-instruction tests fail on trunk
Hi, On Tue, Oct 8, 2013 at 4:07 PM, Renato Golin <renato.golin at linaro.org>wrote: > On 8 October 2013 14:01, İsmail Dönmez <ismail at donmez.ws> wrote: > >> I was using a 1 week old clang to boostrap, switched to gcc and the bug >> gone away. Now I'll boostrap again with the new clang to see if the >> regression is there or not. >> > > Are
2013 Oct 08
2
[LLVMdev] basic-arm-instruction tests fail on trunk
Hi Renato, On Tue, Oct 8, 2013 at 3:57 PM, Renato Golin <renato.golin at linaro.org>wrote: > On 7 October 2013 18:33, İsmail Dönmez <ismail at donmez.ws> wrote: > >> This is with Linux on BeagleBone Black (Cortex-A8), regressed recently: >> > > Hi Ismail, > > Are you running this regularly? Do you know which commit regressed? Or at > least a window?
2015 Jan 30
2
[LLVMdev] ARM regression between r223766 and r223925
Hi, On Fri, Jan 30, 2015 at 7:15 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 13 December 2014 at 09:49, İsmail Dönmez <ismail at donmez.ws> wrote: >> With trunk things got even worse while compiling a simple hello world cpp: >> >> 1. /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/basic_string.h:114:57: >> current