similar to: [LLVMdev] The vc++ solution cannot live in parallel with a mingw compilation

I'll take a look at it. VC++ projects shouldn't be modifying anything in the src tree, as it's set up in src != obj mode, with obj being win32. Not sure when I can get around to it though... I'm in FreeBSD mode right now :) > From llvmdev-bounces at cs.uiuc.edu Mon Dec 20 16:06:07 2004 > From: "Henrik Bach" <henrik_bach_llvm at hotmail.com> > To: llvmdev

Hi Jeff, It seems that the above project isn't committed into cvs. Henrik. ============================================================= Henrik Bach Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/

This is one of the reasons I'm getting rid of the "platform" link. I'm not sure what platform you're working on, but on Cygwin it causes problems. Cygwin doesn't like .. through a soft link and generates incorrect file names. I imagine this is what is happening to the dependencies. In any event, the "platform" link will be gone before the new year. Sorry for

Henrik. ============================================================= Henrik Bach Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/ =============================================================

Hi Reid, The error still exists. However, looking on the function in Win32/Path.cpp: -------------- void sys::CopyFile(const sys::Path &Dest, const sys::Path &Src) { if (!::CopyFile(Src.c_str(), Dest.c_str(), false)) ThrowError("Can't copy '" + Src.toString() + "' to '" + Dest.toString() + "'"); } -------------- I

Hi Reid, Looking closer at the build process, I find that Path.cpp doesn't get compiled, even if it is a newer version than its *.o file. That's probaly the reason the error still exists. I've zipped and attached the trace after the point the new Path.cpp was updated by cvs. It clearly shows that it newer gets compiled and now shows that it is the dependencies in the makefile

Hi Reid, Looking closer at the build process, I find that Path.cpp doesn't get compiled, even if it is a newer version than its *.o file. That's probaly the reason the error still exists. I've zipped and attached the trace after the point the new Path.cpp was updated by cvs. It clearly shows that it newer gets compiled and now shows that it is the dependencies in the makefile

Hi Reid, I don't think I've initiated a parallel build by this command: ------------------------ make TOOLLINKOPTSB+=-ldbghelp TOOLLINKOPTSB+=-lpsapi LDFLAGS+='-Wl,--no-keep-memory' -r VERBOSE=1 ------------------------ Henrik. >From: Reid Spencer Date: Wed, 26 Jan 2005 12:05:51 -0800 > >It looks like what you're getting is a sharing violation. Although, I

I have no problems... Henrik Bach wrote: > Henrik. > > ============================================================= > Henrik Bach > Open Source Developer > > e-mail: henrik_bach_llvm at hotmail.com > ============================================================= > Got Freedom? > Software Freedom Day 2004 - 28th of August > http://www.softwarefreedomday.org/ >

Hi, When I compile FileUtilities.cpp I get this error: ---------------- llvm[1]: Compiling FileUtilities.cpp for Debug build c:/projects/src/llvm-1/llvm/lib/Support/FileUtilities.cpp: In destructor `llvm::FDHandle::~FDHandle()': c:/projects/src/llvm-1/llvm/lib/Support/FileUtilities.cpp:79: error: `close' undeclared (first use this function) ---------------- Shouldn't function close

Hi, Is there an easy way to test whether an llvm-tool is functioning properly? Henrik. ============================================================= Henrik Bach LLVM Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= No Software patents - Thank you Poland: http://www.nosoftwarepatents.com/en/m/intro/app0411.html Got

============================================================= Henrik Bach LLVM Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= 'Nothing is impossible; The impossible just takes longer time :)' - Inventor of a new energy saver light bulp from Denmark. No software patents! Got Freedom? Software Freedom Day - 10th

Hi Jeff and others, When building the llvm runtime, I always get this error message: 'Can't destroy file: The process cannot access the file because it is being used by another process.' The file is destoyed anyway. I think that the the real error is the path for the file (*/\file.tmp). However, I can't find the bug in the source. Do you have any clue?:

>From: "Baptiste Lepilleur" >Date: Tue, 20 Sep 2005 09:29:07 +0200 > >Henrik Bach wrote: >>Hi, >> >>Please have a look on my private Getting started with MinGW: >> >>http://www.geocities.com/henrik_bach_llvm/ > > >Thanks Henrik.The make line was most useful. Though, in my case I also >needed to add a -L so libimagehlp.a would be

Hi, Can anyone tell me why CopyFile is the only undefined reference from Path.cpp? --------------- llvm[2]: Linking Debug executable gccld c:/projects/build/MinGW/llvm-1-1/tools/gccld/Debug/gccld.o(.text+0x439): In function `Z15EmitShellScriptPPc': c:/projects/src/llvm-1/llvm/tools/gccld/gccld.cpp:127: undefined reference to `llvm::sys::CopyFile(llvm::sys::Path const&, llvm::sys::Path

And I had just fixed VC++ so that it *did* handle the dependencies with platform correctly... This means that each file in System you change to eliminate the #include from platform will require a corresponding change to System.vproj. I'd appreciate it if you got it over with all at once, otherwise VC++ support will be broken more often than not. Reid Spencer wrote: >This is one of

Replace __time_t with time_t in my question. I've compiled function: std::string TimeValue::toString() const { // Alas, asctime is not re-entrant on Windows... //hb: __time64_t ourTime = this->toEpochTime(); time_t ourTime = this->toEpochTime(); //hb: char* buffer = ::asctime(::_localtime64(&ourTime)); char* buffer = ::asctime(::localtime(&ourTime)); std::string

Well Chris, then I've to ask the guys who really have the hands into the guts of the VC++ code: On Tue, 16 Nov 2004, Henrik Bach wrote: > Hi Chris, > > I'm reading release notes for the fifth public release of LLVM and came > across this line: > > "The LLVM source code is now compatible with Microsoft Visual C++." > > which is almost true, if

It looks like what you're getting is a sharing violation. Although, I don't understand why. The llvm-ar.exe when its building an archive file always builds it in a temporary. Only when that is complete does it remove the old one and rename the temporary. Perhaps this is a result of doing parallel build and the "lib3.tmp" file (that name looks wrong to me) is being accessed by

Henrik Bach wrote: >> From: "Baptiste Lepilleur" >> Date: Tue, 20 Sep 2005 09:29:07 +0200 >> >> Henrik Bach wrote: >>> Hi, >>> >>> Please have a look on my private Getting started with MinGW: >>> >>> http://www.geocities.com/henrik_bach_llvm/ >> >> >> Thanks Henrik.The make line was most useful.