search for: executeandwait

On Sun, 10 Apr 2005, Markus F.X.J. Oberhumer wrote: > sys::Program::ExecuteAndWait() requires that the first element in "args" > should be the name of the program, but (at least) llvm-ld.cpp and gccld.cpp > fail to do so, thereby effectively swallowing the first parameter. > This is the reason that -native-cbe has not working for some time - actually > I...

It's correct; the win32 version also expects the first arg to be the name of the program. Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: > >> On Sun, 10 Apr 2005, Markus F.X.J. Oberhumer wrote: >> >>> sys::Program::ExecuteAndWait() requires that the first element in >>> "args" should be the name of the program, but (at least) llvm-ld.cpp >>> and gccld.cpp fail to do so, thereby effectively swallowing the >>> first parameter. >>> This is the reason that -native-cbe has not wor...

...to find it. const char *PathStr = getenv("PATH"); - if (PathStr == 0) + if (PathStr == 0) return Path(); // Now we have a colon separated list of directories to search; try them. @@ -142,14 +142,14 @@ static void SetMemoryLimits (unsigned size) #endif } -int -Program::ExecuteAndWait(const Path& path, +int +Program::ExecuteAndWait(const Path& path, const char** args, const char** envp, const Path** redirects, unsigned secondsToWait, unsigned memo...

...=============== RCS file: /var/cvs/llvm/llvm/tools/gccld/GenerateCode.cpp,v retrieving revision 1.50 diff -u -r1.50 GenerateCode.cpp --- tools/gccld/GenerateCode.cpp 8 Jul 2005 16:48:52 -0000 1.50 +++ tools/gccld/GenerateCode.cpp 1 Aug 2005 22:06:26 -0000 @@ -325,8 +325,7 @@ return sys::Program::ExecuteAndWait(llc, &args[0]); } -/// GenerateAssembly - generates a native assembly language source file from the -/// specified bytecode file. +/// GenerateCFile - generates a C source file from the specified bytecode file. int llvm::GenerateCFile(const std::string &OutputFile,...

...m to be executed. It is presumed this is the result of ///< the FindProgramByName method. diff --git a/lib/System/Unix/Program.inc b/lib/System/Unix/Program.inc index 342b45c..15f6e3f 100644 --- a/lib/System/Unix/Program.inc +++ b/lib/System/Unix/Program.inc @@ -274,7 +274,7 @@ Program::ExecuteAndWait(const Path& path, } -void +Program::ProcessID Program::ExecuteNoWait(const Path& path, const char** args, const char** envp, @@ -285,36 +285,36 @@ Program::ExecuteNoWait(const Path& path, if (!path.canExecute()) { if (ErrMsg)...

...=============== RCS file: /var/cvs/llvm/llvm/tools/gccld/GenerateCode.cpp,v retrieving revision 1.50 diff -u -r1.50 GenerateCode.cpp --- tools/gccld/GenerateCode.cpp 8 Jul 2005 16:48:52 -0000 1.50 +++ tools/gccld/GenerateCode.cpp 2 Aug 2005 04:11:11 -0000 @@ -325,8 +325,7 @@ return sys::Program::ExecuteAndWait(llc, &args[0]); } -/// GenerateAssembly - generates a native assembly language source file from the -/// specified bytecode file. +/// GenerateCFile - generates a C source file from the specified bytecode file. int llvm::GenerateCFile(const std::string &OutputFile,...

...med this is the result of >         ///< the FindProgramByName method. > diff --git a/lib/System/Unix/Program.inc b/lib/System/Unix/Program.inc > index 342b45c..15f6e3f 100644 > --- a/lib/System/Unix/Program.inc > +++ b/lib/System/Unix/Program.inc > @@ -274,7 +274,7 @@ Program::ExecuteAndWait(const Path& path, > >  } > > -void > +Program::ProcessID >  Program::ExecuteNoWait(const Path& path, >                        const char** args, >                        const char** envp, > @@ -285,36 +285,36 @@ Program::ExecuteNoWait(const Path& path, >  ...

Hi Daniel, Daniel Dunbar <daniel <at> zuster.org> writes: > > Ultimately I think a better API would be to provide a generic class > which represents an executed operating system process, and includes > operations to wait for its completion, redirect its IO, communicate > with it, etc. This would be a big improvement over the current > monolithic function. I agree,

On Thu, Jul 16, 2009 at 7:48 PM, Mikhail Glushenkov<foldr at codedgers.com> wrote: > Hi Daniel, > > Daniel Dunbar <daniel <at> zuster.org> writes: > >> >> Ultimately I think a better API would be to provide a generic class >> which represents an executed operating system process, and includes >> operations to wait for its completion, redirect

On Tue, 27 Sep 2005, Kevin J. Stephano wrote: > I am currently running on a Mac OSX 10.3.8 and trying to > compile llvm-1.4 on my local machine for Prof. Adve's class. > > I am using Apple's provided gcc 3.3 as my compiler. > > I ran into this compile error: > SysUtils.c: In function `executeProgram': > SysUtils.c:119: error: `RTLD_NEXT' undeclared (first

I am currently running on a Mac OSX 10.3.8 and trying to compile llvm-1.4 on my local machine for Prof. Adve's class. I am using Apple's provided gcc 3.3 as my compiler. I ran into this compile error: SysUtils.c: In function `executeProgram': SysUtils.c:119: error: `RTLD_NEXT' undeclared (first use in this function) SysUtils.c:119: error: (Each undeclared identifier is reported

...39; > 2) gcc 3.5 (mainline CVS) > Mostly result using ~0 (negative signed int) expression as value of > unsigned int function parameter. > Compiling Program.cpp /usr/home/wanderer/pkg/build/llvm/obj/lib/System/platform/../Unix/Program.cpp: In member function `int llvm::sys::Program::ExecuteAndWait(const std::vector<std::string, std::allocator<std::string> >&) const': /usr/home/wanderer/pkg/build/llvm/obj/lib/System/platform/../Unix/Program.cpp:132: warning: control reaches end of non-void function Compiling TableGen.cpp /home/wanderer/pkg/build/llvm/src/llvm/utils/Tabl...

LLVM build without big problems in obj dir == src dir case (for example, last night tester build) But I have problem with building CVS version LLVM in obj dir != src dir case. ======= Finished building ModuleMaker debug executable (without symbols) ======= gmake[2]: Leaving directory `/usr/home/wanderer/pkg/build/llvm/obj/examples/ModuleMaker' gmake[1]: Leaving directory

...> > Mostly result using ~0 (negative signed int) expression as value of > > unsigned int function parameter. > > > > Compiling Program.cpp > /usr/home/wanderer/pkg/build/llvm/obj/lib/System/platform/../Unix/Program.cpp: > In member function `int llvm::sys::Program::ExecuteAndWait(const > std::vector<std::string, std::allocator<std::string> >&) const': > /usr/home/wanderer/pkg/build/llvm/obj/lib/System/platform/../Unix/Program.cpp:132: > warning: control reaches end of non-void function Not sure what's up with that. 3.4 doesn't generat...

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached

...g &ErrMsg) { + if (MergeObjs) + MergedObjFile = FileMgr.CreateObjFile("merged"); + + if (!generateMakefile(ErrMsg)) + return false; + + const char *args[] = {"/usr/bin/make", "-C", 0, 0}; + args[2] = FileMgr.getWorkDir().c_str(); + + bool Fail; + sys::ExecuteAndWait("/usr/bin/make", args, 0/*envp*/, 0/*redirect*/, 0/*wait*/, 0, &ErrMsg, &Fail); + return !Fail; +} Index: tools/lto/LTOCodeGenerator.h =================================================================== --- tools/lto/LTOCodeGenerator.h (revision 186109) +++ tools/lto/LTOCodeGener...