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

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 >

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

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

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

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

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

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

Hi all, > Please try it out, if it doesn't work, please tell us what's > wrong, or, better yet, submit a patch. :) Alright, here are the results of building the latest llvm from CVS under cygwin: lib\Debugger\SourceFile.cpp needs #include <assert.h> when building with gcc 3.3.3 tools\gccld\gccld.cpp line 128 tools\llvm-ld\llvm-ld line 318 need

Hi Reid, > I've been doing a Cygwin build today too. All these problems > have been updated in the current CVS. Please update your tree > and give it another try. Alright, this time everything works quite a bit better. However: tools\llvm-ld\llvm-ld.cpp needs the CopyFile() invocation fix identical to gccld.cpp Also, it turns out gcc 3.3.3 in cygwin is buggy and it's unable

Hello Mike, I know from my customers that moving files under macOS Ventura on a SMB share is a mess and completely broken by Apple (e. g. moved files cannot be opened until you reconnect). Unfortunately I do not have a ZFS-backed machine to test against available right now to confirm the behaviour. Is your order of "vfs objects? correct? Regards, Alexander > On Thursday, Mar 02, 2023 at

Hi folks, I have a number of Mac users connecting to our Samba fileserver over VPN. When they copy/move files between shares it takes quite a long time due to our miserable business internet connection. I set fruit:copyfile = yes in smb.conf expecting that to enable server-side copy for Mac users. Unfortunately, it did not. Befuddled, I tried the same copy operation from a Windows VM and it

gccld passes -shared through if it's generating a shared library, but if you're compiling a program that needs to have its symbols externally accessible, it doesn't pass -export-dynamic through to gcc for the final link. The attached patch fixes this. I've tested with a small test case I sent Chris, and with Python; both seem to work. I also fixed some inaccurate comments in

Hi LLVM'ers, I'm trying to build the DotGNU project with the LLVM-tools. After minor modifications of source and build code and some configure housekeeping, it seems that I've managed so far to build all the DotGNU tools. However, when extensively using the DotGNU tools I get this error message: make[1]: Entering directory `/home/hb/projects/build/LLVM/pnet-1-1/samples'

Hi, i used CVS to checkout the source of llvm and llvm-gcc, compiled and built them on my machine successfully. i tried a c-language hello program, it was OK. But when i tried a c++-language hello program, i got: ~/project/llvm/examples$ llvm-g++ t3.cc -o t3 gccld: /developer/zsth/project/llvm/src/llvm/lib/Analysis/IPA/CallGraph.cpp:277: void

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Hi,<br> I am newbie to llvm.<br> <br> I am unable to generate

I was getting some weird errors from gccld and traced it to path construction in isBytecodeLPath. If the path doesn't end with a /, then Path just tries to stick filenames onto it, which is not so good. It would be more efficient to just add a "/" to the path once, I guess. Also, I had to touch lib/System/Path.cpp to get my changes to Path.inc noticed; it seems the build system