similar to: [LLVMdev] Haiku support in googletest

Hi Kees, You added some support for Minix to LLVM's copy of googletest: http://llvm.org/viewvc/llvm-project?view=rev&revision=100895 Is it still being used? If so, would you mind pushing these patches upstream to the googletest project: http://code.google.com/p/googletest/ Otherwise we may drop them, because it makes it harder to import new releases of googletest into the LLVM

Hello Jay, At the time I submitted those patches I also submitted them to googletest. As far as I know they got accepted, although I didn't verify that. I am no longer working on the Minix project, but since the Minix project is most definitely using llvm, I am cc:-ing this to the Minix developers mailing list. Perhaps they want to respond to this. -- Kees On 27 Jul 2011, at 11:43, Jay

Hi Jay, >> yes, they are annoying aren't they. They all come from google's unittest >> library. I think it is best to fix them upstream at google. > > We're using googletest 1.5.0. These warnings seem to be fixed in > 1.6.0, so here's a patch to upgrade us. Disclaimer: I've only tested > this by doing "make check-all" on Linux/x86_64. >

On 24 July 2011 10:59, Duncan Sands <baldrick at free.fr> wrote: > Hi Edward, > >> Building of llvm with gcc-4.5.2-1 gives these warnings: >> >> 1) Building FileManagerTest >> >> "llvm[4]: Compiling FileManagerTest.cpp for Debug+Asserts build >> C:/Programming/VersionControl/llvm/tools/clang/unittests/Basic/FileManagerTest.cpp: >> In

Another observation: GettingStarted.html still gives these instructions for cross-compiling LLVM: 1. Configure and build LLVM as a native compiler. You will need just TableGen from that build. * If you have $LLVM_OBJ_ROOT=$LLVM_SRC_ROOT just execute make -C utils/TableGen after configuring. * Otherwise you will need to monitor building process and terminate it just after

2008/12/31 Chris Lattner <clattner at apple.com> > On Dec 30, 2008, at 2:54 PM, Talin wrote: > > OK changes made and new patch attached. > > +++ utils/unittest/Makefile (revision 0) > > ... > +# This has to come after Makefile.common, since it doesn't allow us to > +# override the VPATH value unless we set PROJECT_NAME, which we don't want > +# to do.

The next problem I have is: llvm[2]: Linking Debug executable opt /home/foad/llvm/objdir-mingw/Debug/lib/libLLVMSystem.a(DynamicLibrary.o):/home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/DynamicLibrary.inc:179: undefined reference to `___eprintf' collect2: ld returned 1 exit status I can work around this by removing the two references to __eprintf from

On 18 July 2011 15:23, David Blaikie <dblaikie at gmail.com> wrote: > Looks like that break came > from http://llvm.org/viewvc/llvm-project?view=rev&revision=135154 > Judging by this ArrayRef ctor you should be able to simplify those calls by > changing the last two arguments from "&foo, 1" to, simply, "foo". I've done this in r135472. Jay.

On Tue, Jul 19, 2011 at 10:12:47AM +0100, Jay Foad wrote: > On 18 July 2011 15:23, David Blaikie <dblaikie at gmail.com> wrote: > > Looks like that break came > > from http://llvm.org/viewvc/llvm-project?view=rev&revision=135154 > > Judging by this ArrayRef ctor you should be able to simplify those calls by > > changing the last two arguments from

Hooray! I'm thinking that getting unit tests for the classes in ADT should be an early goal. I also wanted to mention a point about the general philosophy of unit testing, which is that the presence of such tests alters the calculation of risk when making changes to a code base. Programmers have various rules of thumb for estimating risk - for example, a change which affects a large

> I can work around this by removing the two references to __eprintf > from lib/System/Win32/DynamicLibrary.inc, but... why are they there in > the first place, and why don't I have __eprintf on my system? > > I see that these references were introduced here: > > http://llvm.org/viewvc/llvm-project?view=rev&revision=52037 > > but I don't understand what they

> Someone else would have to > try 3.X. It works for me. I can now build LLVM on Cygwin with GCC 3.4.4, where I used to fall over this problem before. Thanks, Jay.

On 27 July 2011 11:20, dr. ir. Kees van Reeuwijk <reeuwijk at few.vu.nl> wrote: > At the time I submitted  those patches I also submitted them to googletest. As far as I know they got accepted, although I didn't verify that. OK, I see from this thread: http://groups.google.com/group/googletestframework/browse_thread/thread/3081a14965764366/332ce9869f4bbe31 ... that rather than add

I'm trying to cross-compile LLVM with build=, host=target=. I'm using the following packages from Debian lenny: mingw32 4.2.1.dfsg-1 mingw32-binutils 2.18.50-20080109-1 mingw32-runtime 3.13-1 The first problem I hit was when I configured with CC, CXX, AR and RANLIB set to mingw cross-tools, but forgot to specify NM as well. This resulted in a load of warnings that scrolled off the

Aaron Gray wrote: > On Sat, Feb 21, 2009 at 7:14 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Aaron Gray wrote: > > On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca> > > <mailto:nicholas at mxc.ca <mailto:nicholas at mxc.ca>>> wrote:

GCC 3.x doesn't support -Wno-missing-field-initializers or -Wno-variadic-macros, so I get this build failure (with GCC 3.4.4 on Cygwin): make[3]: Entering directory `/home/foad/llvm/objdir-svn/utils/unittest/googletest' llvm[3]: Compiling gtest.cc for Debug build cc1plus: error: unrecognized command line option "-Wno-missing-field-initializers" cc1plus: error: unrecognized

From: Haiku - http://www.haiku-os.org/about To: FreeDesktop.org GNU/Linux has gained quite some momentum on the desktop, with the help of Gnome and KDE environments, and the FreeDesktop.org project. Haiku is a Free Software (BSD/MIT) desktop targeted operating system, designed to present a coherent and simple to use environment, inspired by BeOS. Although Haiku does not use X11, it provides

I put in two slightly different fixes that I believe should cover the problem: http://llvm.org/viewvc/llvm-project?view=rev&revision=156837 http://llvm.org/viewvc/llvm-project?view=rev&revision=156838 Let me know if your experience disagrees. I'll try and get these into 3.1 if Bill lets me after the buildbots give a check mark. - Daniel On Tue, May 15, 2012 at 5:38 AM, Keno

On Dec 30, 2008, at 2:54 PM, Talin wrote: > OK changes made and new patch attached. Nice +++ utils/unittest/Makefile (revision 0) ... +# This has to come after Makefile.common, since it doesn't allow us to +# override the VPATH value unless we set PROJECT_NAME, which we don't want +# to do. +VPATH = $(LLVM_SRC_ROOT)/utils/unittest/googletest/src/ Why play with VPATH here? What

First off, I'd like to say thanks for applying the patch we recently submitted on the bug tracker to allow openssh to build on Haiku. In our current port of openssh for Haiku it's creating a directory ~/.ssh, we'd like to have this moved to ~/config/settings/ssh (without a dot in front of ssh). Haiku (and BeOS before that) has a function available to determine the location of a