similar to: [LLVMdev] dragonegg 3.4 branch broken

On Fri, Dec 07, 2012 at 06:57:36PM +0100, Duncan Sands wrote: > Hi Jack, can you please open a bug report asking that llvm-config only > provide the minimum set of flags needed to compile code that interfaces > with LLVM, rather than (as now) all kinds of unneeded flags such as -g > and warnings. > > Thanks, Duncan. > Duncan, I have opened

Hi Jack, can you please open a bug report asking that llvm-config only provide the minimum set of flags needed to compile code that interfaces with LLVM, rather than (as now) all kinds of unneeded flags such as -g and warnings. Thanks, Duncan. On 07/12/12 18:55, Jack Howarth wrote: > On Fri, Dec 07, 2012 at 06:20:37PM +0100, Duncan Sands wrote: >> Hi Jack, this occurs because you

Hi Jack, this occurs because you compiled LLVM with clang (right?) and dragonegg is compiled with the same flags used to compile LLVM (it is an llvm-config bug in my opinion that llvm-config output includes these kinds of optional flags). Ciao, Duncan. On 07/12/12 18:11, Jack Howarth wrote: > Duncan, > I am unable to complile dragonegg 3.2 with FSF gcc 4.7 due the the > compiler

Duncan, I am unable to complile dragonegg 3.2 with FSF gcc 4.7 due the the compiler errors... GCC=/sw/lib/gcc4.7/bin/gcc-4 LLVM_CONFIG=/sw/opt/llvm-3.2/bin/llvm-config VERBOSE=1 ENABLE_LLVM_PLUGINS=1 make CPPFLAGS="-g -DENABLE_LTO -I/sw/include" /sw/lib/gcc4.7/bin/gcc-4 --version > /dev/null /sw/opt/llvm-3.2/bin/llvm-config --version > /dev/null Compiling utils/TargetInfo.cpp

On Fri, Dec 07, 2012 at 06:20:37PM +0100, Duncan Sands wrote: > Hi Jack, this occurs because you compiled LLVM with clang (right?) and > dragonegg is compiled with the same flags used to compile LLVM (it is > an llvm-config bug in my opinion that llvm-config output includes these > kinds of optional flags). Duncan, Yes. I believe both fink and MacPorts now default to the clang

On Sat, Dec 01, 2012 at 05:42:15PM +0400, Kostya Serebryany wrote: > +kremenek, ganna > > On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > > > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > > Just want to remind everyone that we plan to stop using mach_override in > > > asanin favor of OSX's

+kremenek, ganna On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > Just want to remind everyone that we plan to stop using mach_override in > > asanin favor of OSX's native function interposition. > > So, we probably don't want to spend too much effort fixing

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > Just want to remind everyone that we plan to stop using mach_override in > asanin favor of OSX's native function interposition. > So, we probably don't want to spend too much effort fixing mach_override. > > --kcc Kostya, Unless I am misunderstanding the code in asan/asan_intercepted_functions.h,

On Tue, Dec 04, 2012 at 10:36:18AM -0800, Alexander Potapenko wrote: > Currently the replacement of allocation routines is based on creating > a new malloc zone and a new CFAllocator (because the allocator > replacement is done later than it could be, we must have both). This > makes us depend on CoreFoundation to call CFAllocatorSetDefault. > Because of some bugs in CF which start

The datetime.R issue looks familiar. Darwin (the basis for OS X) copied a lot of things from FreeBSD, bugs and all. So I expect the same remedy applies (http://cran.r-project.org/doc/manuals/r-patched/R-admin.html#OS-X): 'Configure option --with-internal-tzcode is the default on OS X, as the system implementation of time zones does not work correctly for times before 1902 or after 2037

I tried compiling using GCC. First, I changed config.site to: ~/R-3.2.2$ svn diff config.site Index: config.site =================================================================== --- config.site (revision 69236) +++ config.site (working copy) @@ -278,3 +278,8 @@ ## Path to the version of pkg-config to be used for locating cairographics. ## PKGCONF = +F77=gfortran48 +FC=${F77} +CC=gcc48

Dirk, Dirk Eddelbuettel <edd at debian.org> writes: > On 21 November 2016 at 23:24, Joseph Mingrone wrote: > | Dirk Eddelbuettel <edd at debian.org> writes: > | > On 20 November 2016 at 21:49, Joseph Mingrone wrote: > | > | Hello Dirk, > | > | > | > | Dirk Eddelbuettel <edd at debian.org> writes: > | > | > | > | > On 20 November

Adding the flags in an opt pass seems to do the trick. I added the flags as follows M.addModuleFlag(llvm::Module::Warning, "Dwarf Version", 3); M.addModuleFlag(llvm::Module::Error, "Debug Info Version", llvm::DEBUG_METADATA_VERSION); llvm-dwarfdump and addr2line now point at a line in .ll files, not the source files. Thanks! /Muneeb On 15 Oct

Hi Brian, Thanks for sharing your experience with dragonegg. I would like to use tilera-gcc as the compiler driver. native gcc would not be able to handle things like tilera specific intrinsics in the source code. I built dragonegg using GCC=/path/to/tilera-gcc48/bin/tile-gcc LLVM_CONFIG=/path/to/tilera-llvm/bin/tilegx-llvm-config make and also tried only emitting the IR

On Fri, Apr 08, 2011 at 01:58:10PM +0200, Duncan Sands wrote: >> Is there anything I can do to make the build more verbose so I can debug this? > > make VERBOSE=1 Duncan, Oddly this shows... GCC=/sw/lib/gcc4.5/bin/gcc-4 LLVM_CONFIG=/sw/bin/llvm-config make VERBOSE=1 CPPFLAGS="-DENABLE_LTO -I/sw/include" Compiling utils/TargetInfo.cpp g++ -c

No. The gcc cross compiler being used (tilera-gcc) is indeed 64-bit. Thanks On Tue, Oct 28, 2014 at 11:01 AM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > Looks like your gcc is 32-bit and you're trying to load 64-bit plugin. > > On Tue, Oct 28, 2014 at 8:27 PM, Ajay Panyala <ajay.panyala at gmail.com> > wrote: > > Hi Brian, > > > >

Hi, I'm trying to install from source code the 'nlme' package in RStudio. When I try, I get the following error message: ld: warning: directory not found for option '-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2' ld: library not found for -lgfortran clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [nlme.so] Error 1 ERROR:

Hello, I'm not sure if this is right list, but has anything recently changed which could explain why cmake c++ project (http://sourceforge.net/projects/gemrb/) started to fail upon linking stage (looking like libstdc++ is not included /usr/include/c++/4.2/)? It works normally if passed gcc48 as compiler which subsequently uses (ld) binutils from ports and relevant libstdc++. I have in

Just a report about compiler warnings generated when building opusfile from current git. Regards. # x86-Linux builds / gcc48 and clang-3.3 (no warnings) # x86-Linux builds / gcc34 src/opusfile.c: In function `op_calc_bitrate': src/opusfile.c:1777: warning: integer constant is too large for "long" type src/opusfile.c: In function `op_open2': src/opusfile.c:1131: warning:

Package: src:xcp-vncterm Version: 0.1-2 Severity: important Tags: sid jessie User: debian-glibc at lists.debian.org Usertags: ftbfs-glibc-2.17 The package fails to build in a test rebuild on at least amd64 with eglibc-2.17, but succeeds to build with eglibc-2.13. The severity of this report may be raised before the jessie release. The test rebuild was done together with GCC-4.8, so some issues