similar to: [LLVMdev] conflicting c++ libs for building dragonegg

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] conflicting c++ libs for building dragonegg"

2013 Aug 30
2
[LLVMdev] conflicting c++ libs for building dragonegg
On Thu, Aug 29, 2013 at 07:40:46PM +0200, Duncan Sands wrote: > Hi Jack, > > On 29/08/13 18:35, Jack Howarth wrote: >> Duncan, >> Is there a long term plan for handling the conflicting c++ libraries in building >> dragonegg? In particular, as vendors switch their clang++ system compilers to default >> to -stdlib=libc++, the resulting builds of llvm against
2013 Aug 29
0
[LLVMdev] conflicting c++ libs for building dragonegg
Hi Jack, On 29/08/13 18:35, Jack Howarth wrote: > Duncan, > Is there a long term plan for handling the conflicting c++ libraries in building > dragonegg? In particular, as vendors switch their clang++ system compilers to default > to -stdlib=libc++, the resulting builds of llvm against those compilers will be using > the libc++ ABI but the dragonegg plugin will still need to be
2013 Aug 30
0
[LLVMdev] conflicting c++ libs for building dragonegg
Hi Jack, On 30/08/13 15:56, Jack Howarth wrote: > On Thu, Aug 29, 2013 at 07:40:46PM +0200, Duncan Sands wrote: >> Hi Jack, >> >> On 29/08/13 18:35, Jack Howarth wrote: >>> Duncan, >>> Is there a long term plan for handling the conflicting c++ libraries in building >>> dragonegg? In particular, as vendors switch their clang++ system compilers
2013 Aug 30
1
[LLVMdev] conflicting c++ libs for building dragonegg
On 30 Aug 2013, at 19:42, Duncan Sands <baldrick at free.fr> wrote: > First off, is libc++ supposed to be incompatible with > libstdc++? libc++ does not, and never had, ABI compatibility with libstdc++ as a goal. Actually, libstdc++ periodically breaks ABI compatibility too, as we have recently found in the FreeBSD ports tree with certain projects requiring a newer libstdc++ than
2012 Oct 22
5
[LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range
Jack, I looks like the code is calling dlopen() on LLVMPolly.so and it or something it links against has an initializer. The initialer is run before dlopen() returns and the crash is in the initializer. The message: dyld: fast lazy bind offset out of range (53437, max=7640) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 means the initializer called something which
2013 Feb 03
1
Ports and WITH_LIBCPLUSPLUS
Hello, I wanted to try the new c++ stuff, ie clang-3.2, libc++ and libcxxrt, so I used poudriere to build a jail setup for that ( WITH_LIBCPLUSPLUS=yes in src.conf, CXXFLAGS+=-stdlib=libc++ and libsupc++.so.1 libcxxrt.so.1 in libmap.conf ), and started to build my normal set of packages ( see desktop.list ). Please note that I also have WITH_NEW_XORG=yes and WITH_KMS=yes, as well as using the
2012 Oct 22
5
[LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range
On Oct 22, 2012, at 11:34 AM, Jack Howarth wrote: > Nick, > I have uploaded the full walk with 'set env DYLD_PRINT_INITIALIZERS'. It didn't seem very informative > as the dyld error occurs right after... > > (gdb) > llvm::sys::DynamicLibrary::getPermanentLibrary (filename=0x142903da8 "/sw/opt/llvm-3.2/lib/LLVMPolly.so", errMsg=0x7fff5fbfe6e0) at
2012 Oct 23
2
[LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range
On Tue, Oct 23, 2012 at 01:05:04PM -0700, Nick Kledzik wrote: > On Oct 23, 2012, at 12:50 PM, Jack Howarth wrote: > > On Mon, Oct 22, 2012 at 11:40:32AM -0700, Nick Kledzik wrote: > >> > >> On Oct 22, 2012, at 11:34 AM, Jack Howarth wrote: > >> > >>> Nick, > >>> I have uploaded the full walk with 'set env
2016 Jul 28
3
[RFC] One or many git repositories?
On 28 Jul 2016 8:36 a.m., "David Chisnall via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > This does not apply to libc++. We support building the entire LLVM suite with other C++ standard library implementations (at least libstdc++, and I think also with Visual Studio’s implementation), so there is no dependency of anything on libc++. Similarly, we support building libc++
2012 Oct 21
2
[LLVMdev] dragonegg polly support broken?
On Sun, Oct 21, 2012 at 10:38:48AM -0700, Tobias Grosser wrote: > On 10/21/2012 09:13 AM, Jack Howarth wrote: >> On Sun, Oct 21, 2012 at 08:38:21AM -0700, Tobias Grosser wrote: >>> On 10/20/2012 05:38 PM, Jack Howarth wrote: >>>> Duncan, >>>> Is the documentation for using Polly support in dragonegg correct? I built llvm/polly/dragonegg
2012 Oct 21
2
[LLVMdev] dragonegg polly support broken?
On Sun, Oct 21, 2012 at 11:01:37AM -0700, Tobias Grosser wrote: > On 10/21/2012 10:57 AM, Jack Howarth wrote: >> On Sun, Oct 21, 2012 at 10:38:48AM -0700, Tobias Grosser wrote: >>> On 10/21/2012 09:13 AM, Jack Howarth wrote: >>>> On Sun, Oct 21, 2012 at 08:38:21AM -0700, Tobias Grosser wrote: >>>>> On 10/20/2012 05:38 PM, Jack Howarth wrote:
2013 May 09
4
[LLVMdev] gcc 4.8.x dragonegg support
On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote: > On Wed, May 08, 2013 at 09:25:55AM -0400, Jack Howarth wrote: > > Duncan, > > I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn > > for the llvm 3.3 release? Is the deprecation and poisoning of IDENT_ASM_OP too problematic > > to work around without some
2012 Oct 21
0
[LLVMdev] dragonegg polly support broken?
On Sun, Oct 21, 2012 at 02:35:49PM -0400, Jack Howarth wrote: > On Sun, Oct 21, 2012 at 11:01:37AM -0700, Tobias Grosser wrote: > > On 10/21/2012 10:57 AM, Jack Howarth wrote: > >> On Sun, Oct 21, 2012 at 10:38:48AM -0700, Tobias Grosser wrote: > >>> On 10/21/2012 09:13 AM, Jack Howarth wrote: > >>>> On Sun, Oct 21, 2012 at 08:38:21AM -0700, Tobias
2016 Jul 28
0
[RFC] One or many git repositories?
On 28 Jul 2016, at 08:59, Renato Golin <renato.golin at linaro.org> wrote: > > On 28 Jul 2016 8:36 a.m., "David Chisnall via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > > This does not apply to libc++. We support building the entire LLVM suite with other C++ standard library implementations (at least libstdc++, and I think also with Visual Studio’s
2012 Oct 21
0
[LLVMdev] dragonegg polly support broken?
On 10/21/2012 10:57 AM, Jack Howarth wrote: > On Sun, Oct 21, 2012 at 10:38:48AM -0700, Tobias Grosser wrote: >> On 10/21/2012 09:13 AM, Jack Howarth wrote: >>> On Sun, Oct 21, 2012 at 08:38:21AM -0700, Tobias Grosser wrote: >>>> On 10/20/2012 05:38 PM, Jack Howarth wrote: >>>>> Duncan, >>>>> Is the documentation for using Polly
2013 Nov 22
2
[LLVMdev] dragonegg vs -Ofast
Duncan, What is the situation with -Ofast in dragonegg 3.4? Are we now enabling all of the same optimizations for that case as are done in clang when it is passed -Ofast? Thanks in advance for any clarification. Jack
2012 Oct 21
0
[LLVMdev] dragonegg polly support broken?
On 10/21/2012 09:13 AM, Jack Howarth wrote: > On Sun, Oct 21, 2012 at 08:38:21AM -0700, Tobias Grosser wrote: >> On 10/20/2012 05:38 PM, Jack Howarth wrote: >>> Duncan, >>> Is the documentation for using Polly support in dragonegg correct? I built llvm/polly/dragonegg >>> using the documentation at
2012 Oct 21
2
[LLVMdev] dragonegg polly support broken?
On Sun, Oct 21, 2012 at 08:38:21AM -0700, Tobias Grosser wrote: > On 10/20/2012 05:38 PM, Jack Howarth wrote: >> Duncan, >> Is the documentation for using Polly support in dragonegg correct? I built llvm/polly/dragonegg >> using the documentation at http://polly.llvm.org/example_load_Polly_into_dragonegg.html >> with... >> >> GCC=/sw/lib/gcc4.7/bin/gcc-4
2017 Jun 06
3
libc++ failed to link against musl
On 5 Jun 2017, at 15:17, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 6/5/17 5:17 AM, Dmitry Golovin via llvm-dev wrote: >> 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 >>
2007 Aug 10
2
yum install libstdc++-devel
On CentOS 4.5 (x86_64); happening on several different machines with libstdc++ and libstdc++-devel v. 3.4.6-8 only one of the i386 or x86_64 versions of libstc++-devel is installed if I yum install libstdc++-devel it will install the x86_64 version and remove the i386 version, but not warn me. Similarly if the i386 version is installed it will install the x86_64 and remove the i386,