search for: vkutuzov

We have had a script for a while that does this for you in http://llvm.org/svn/llvm-project/llvm/trunk/utils/crosstool/ARM/ . It also uses the CodeSourcery toolchain so it saves you some effort. Does that work for you? On Mon, Jan 18, 2010 at 2:52 PM, Viktor Kutuzov <vkutuzov at accesssoftek.com>wrote: > Hello Corina, > > I used a two-stage sequence to build the llvm and llvm-gcc with the > codesourcery toolchain and my custom built arm toolchain. There is some > scripted chunks for each step. I have attached them as a single file to this > email....

...p;revision=74608 Your comment below makes sense, however, so I tweaked it again here: http://llvm.org/viewvc/llvm-project?view=rev&revision=74645 so that relative paths work. Does this look reasonable to you? Also, does it work? :) - Daniel On Wed, Jul 1, 2009 at 10:04 AM, Viktor Kutuzov<vkutuzov at accesssoftek.com> wrote: > Hi Chris, > >> Please use sys::Path::isAbsolute to check to see if it is an absolute > > I didn't want to check if it is an absolute, I wanted to check if > there is any directory part (absolute or relative). Is there anything > wrong w...

--emit-llvm?? On Fri, Oct 30, 2009 at 7:55 AM, Viktor Kutuzov <vkutuzov at accesssoftek.com>wrote: > Hello everyone, > > I'm working on passing parameters for gold/LTO plug-in and could add this > one as well. > Just need an option name. Could anybody suggest one? > > Viktor > > ----- Original Message ----- > From: "Nick Lewyc...

--emit-llvm, if not conflict >>> Paul Davey <plmdvy at gmail.com> 10/30/2009 11:11 AM >>> --emit-llvm?? On Fri, Oct 30, 2009 at 7:55 AM, Viktor Kutuzov <vkutuzov at accesssoftek.com> wrote: Hello everyone, I'm working on passing parameters for gold/LTO plug-in and could add this one as well. Just need an option name. Could anybody suggest one? Viktor ----- Original Message ----- From: "Nick Lewycky" <nicholas at mxc.ca> To:...

Hello Corina, I used a two-stage sequence to build the llvm and llvm-gcc with the codesourcery toolchain and my custom built arm toolchain. There is some scripted chunks for each step. I have attached them as a single file to this email. May be it will help you somehow. Viktor. --- From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of corina s [corina_fff at

Hello, I am building llvm-gcc4.2-2.6 for ARM target.I used the next command line option: >> .../configure --enable-languages=c,c++ --enable-checking --target=arm-eabi >> and then >> make target_alias=arm-eabi >> And then I obtain the following error: In file included from ../../gcc/config/arm/arm.c:59: ../../../libcpp/internal.h: In function ‘ufputs’:

Hello everyone, I'm working on passing parameters for gold/LTO plug-in and could add this one as well. Just need an option name. Could anybody suggest one? Viktor ----- Original Message ----- From: "Nick Lewycky" <nicholas at mxc.ca> To: "Daniel Dunbar" <daniel at zuster.org> Cc: "Kelly, Terence P (HP Labs Researcher)" <terence.p.kelly at

Daniel Dunbar wrote: > On Thu, Oct 15, 2009 at 7:14 AM, Timo Juhani Lindfors > <timo.lindfors at iki.fi> wrote: >> Tianwei <tianwei.sheng at gmail.com> writes: >>> someone suggested me to use gold-plugin, I know nothing about it yet, I will >>> have a try later. Does anyone have a good solution for this problem? >> Afaik gold does not help here. I

Hello everyone, The Path::makeAbsolute is broken for Windows. It doesn't handle correctly a given absolute path with a drive letter or any UNC name. Please find the patch attached. -Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: makeAbsolute.patch Type: application/octet-stream Size: 2937 bytes Desc: not available URL:

Hello David, I'm working on bugpoint. There are 2 patched out there for review that fix problems and make remote execution work. I'm looking at adding it to the test-suit and use make to run tests remotely for cross-compilation (following Evan's suggestion). Let's coorddinate our effort. Best regards, Viktor ----- Original Message ----- From: "David Goodwin"

Hello everyone, The bugpoint is changed to escalate remote client return status 255 (per discussion - Re: [llvm-commits] [llvm] r75665 - /llvm/trunk/tools/bugpoint/ToolRunner.cpp) Please find the patch attached. -Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: ToolRunner.diff Type: application/octet-stream Size: 4710 bytes Desc: not available URL:

Hello everyone, Please find the patch attached. This fixes the bugpoint -remote-client and adds a helper script for a remote run. -Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: ToolRunner.diff Type: application/octet-stream Size: 4210 bytes Desc: not available URL:

David, Please find attached 2 diffs. Please notice that RemoteRunSafely.sh may get moved to the test suite sub-tree. We have targeted different areas fso far which is great. What's your plan? I have been thinking of using -run-custom and -safe-run-custom argumants for the cross-tools to keep bugpoint out of knowing any target details ans such. Best regards, Viktor ----- Original Message

> I will investigate. I'm in the middle of it as well. Best regards, Viktor ----- Original Message ----- From: "David Goodwin" <david_goodwin at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Friday, July 10, 2009 2:43 PM Subject: Re: [LLVMdev] Heads up! Working on bugpoint >I just checked in my changes to bugpoint and

Hello Evan, Thanks for looking at the patch. > This should use std::cerr and make sure it is wrapped inside the DEBUG > macro. Will do. > Also, we don't want RemoteRunSafely.sh to be under utils/bugpoint. > Can you move it to test-suite? Are you planning to change the llvm > test suite makefile to make use of RemoteRunSafely.sh? I thought about bugpoint remote mode

> bugpoint should be a standalone tool. It should not require a separate > script to handle remote execution. Why is the script needed? Bugpoint is a standalone too and does not require any separate script. The script is a helper for using ssh as a remote client. Bugpoint should not be aware of any details how the test program will be delivered to a remote target, get executed there, and