similar to: [LLVMdev]Undefinedreferenceto`llvm::sys::CopyFile(llvm::sys::Path const&,llvm::sys::P

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

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

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, 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

No, although its declared in the Path.h file, its actually not in the Path class. Have a look. Not sure why you're still seeing that problem. The same change to Unix/Path.cpp fixed the same problem on Cygwin and Linux. Reid. On Thu, 2004-12-23 at 15:48, Henrik Bach wrote: > Hi Reid, > > The error still exists. However, looking on the function in Win32/Path.cpp: > --------------

But breaks VC++. The problem is, Windows.h defines "CopyFile" as a macro that's either "CopyFileA" or "CopyFileW". Path.h is included before Windows.h, so the declaration has the name "CopyFile" while the definition has "CopyFileA". Instant compilation error. Not sure what the best way to fix it is, but I'll check it in as soon as I

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

Its version 1.27 of lib/System/Unix/Path.cpp for Cygwin and version 1.22 of lib/System/Win32/Path.cpp for Win32 Please note that 1.22 of Win32/Path.cpp was *just* committed. I fixed the Unix side, but not the Win32 side until just now. Sorry about that. Promise to get better about this soon (more machines to test on). Reid. On Thu, 2004-12-23 at 14:06, Henrik Bach wrote: > Hi Reid, >

Hi Reid, >Get the latest version. I committed a fix to Path.cpp last night. It >wasn't being defined in the sys:: namespace which is why its undefined. It didn't do any better by removing the old debug files, getting the latest version and reconfiguration of the build. No diffs of Path.cpp and gccld.cpp against top of mainline were were found. Henrik.

Get the latest version. I committed a fix to Path.cpp last night. It wasn't being defined in the sys:: namespace which is why its undefined. Reid. On Thu, 2004-12-23 at 10:44, Henrik Bach wrote: > Hi, > > Can anyone tell me why CopyFile is the only undefined reference from > Path.cpp? > > --------------- > llvm[2]: Linking Debug executable gccld >

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 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?:

Jeff/Chris, So, I opted for the smallest "big bang" commit that made sense. Hopefully this won't be too hard for Chris to review and yet it gets the bulk of the lib/System changes over and done with. Although you'll see a log of commit messages, it turned out that the bulk of the remaining lib/System work was "remove this useless file". There are still some small

I'll see what I can do. However, I have to balance your need for "big bang" change with Chris' fervor for incremental changes. Making a huge change makes his review task harder. There are only seven files to merge so at most seven change sets. I'll probably get these done early next week. Sorry for the hassle, but I want to get lib/System simple, complete and working so I can

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

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

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

I'm not sure. Perhaps Jeff Cohen knows as he wrote this. Reid. On Tue, 2004-12-14 at 11:51, Henrik Bach wrote: > Hi, > > Is it necessary to use the VC6.1+ `__time64_t' type instead of __time_t in > win32/TimeValue.cpp? > > --------------- > In file included from > c:/projects/src/llvm-1/llvm/lib/System/TimeValue.cpp:51: >

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

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/ >