similar to: [LLVMdev] getDirectoryContents and renameFile needs to be implemented in Win32/Path.cpp

I suspect those aren't the only two. I'll have to make a pass over Path.cpp to see what was added to the unix version and not to the win32 version. Henrik Bach wrote: > Hi Jeff, > > We need to get getDirectoryContents and renameFile implemented from > Unix/Path.cpp in Win32/Path.cpp, otherwise I can't get llvm-ar linked. > > Henrik. > > >

Indeed they weren't. It's up to date now. And now that I've done that I can't help but notice that Path.cpp is getting very Unix-centric in its interfaces, what with file permission bits and stuff. This is going to cause problems if and when LLVM is ported to other operating systems, though I have to admit it's getting difficult to name viable operating systems it could

Hi Chris and Vikram, Thank you for your acknowlegdement of my and the other external contributors work, in your latest presentation of LLVM on Compiler Research Infrastructures: "The LLVM Compiler Framework and Infrastructure Tutorial", albeit we have done a little (except Reid) compared with you true unsung heroes at the LLVM team. Henrik

Hi, To link gccld it needs this patch to Path.cpp, too. 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/

============================================================= 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 - Thank you Poland:

Hi When I run configure on Interix, I get these four error messages: ----------- ./configure[384]: test: Files/Microsoft: unexpected operator/operand ./configure[384]: test: Files/Microsoft: unexpected operator/operand ./configure[384]: test: Files/Microsoft: unexpected operator/operand ./configure[384]: test: Files/Microsoft: unexpected operator/operand checking for a BSD-compatible install...

Yes, It looks like the PATH variable in the configure script at line 384 isn't getting quoted properly. The "Files/Microsoft" is probably part of "C:\Program Files\Microsoft\...". The spaces cause it to be interpreted as separate words so it fails. I don't have time to look at this in detail right now. Have a look at the configure script and see if you can figure

On Thu, 2004-12-30 at 20:46, Jeff Cohen wrote: > And now that I've done that I can't help but notice that Path.cpp is > getting very Unix-centric in its interfaces, what with file permission > bits and stuff. This is going to cause problems if and when LLVM is > ported to other operating systems, though I have to admit it's getting > difficult to name viable

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

>From: John Criswell <criswell at cs.uiuc.edu> >Date: Mon, 25 Oct 2004 15:38:52 -0500 > >When you run configure, you'd do something like this: > >configure --prefix=<...> LDFLAGS="-L<path where libdgbhelp is installed" > >If you modify Makefile.config directly, just add the necessary -L option to >TOOLLINKOPTS. I believe that should fix

Hi Due to the mingw platform doesn't have the mmap function the above error emerges. The implementation without this function is left as an exercise. Does any one has an idea to implement this functionality? Henrik _________________________________________________________________ Find det, du s�ger p� MSN S�g http://search.msn.dk

Hi As shown below, the .\configure script found a version of alloca(): --------------------- configure:20831: checking for working alloca.h configure:20853: gcc -o conftest -g -O2 conftest.c -ldl >&5 configure:20856: $? = 0 configure:20859: test -s conftest configure:20862: $? = 0 configure:20873: result: yes configure:20883: checking for alloca configure:20925: gcc -o conftest -g -O2

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

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

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

I agree completely with you, Jeff. However, I think it somehow would be nice, if you guys could tell comming users that the win32 solution is geared toward VC++ 7.1 (and hence use of other tools are at their own risk). And, I think it also would be really cool, if you guys come up with a solution how to handle multiple VC++ x solutions/projects from the same source, possibly ranging from VC

Hi, I get this error: --------------- configure: configuring in projects/Stacker configure: running /bin/sh '/C/projects/src/llvm-2/llvm/projects/Stacker/configure' --prefix=/C/LLVM/tools/ '--prefix=/C/LLVM/tools/' 'CPPFLAGS=-D__MINGW -DLLVM_ON_WIN32=1' --cache-file=/dev/null --srcdir=/C/projects/src/llvm-2/llvm/projects/Stacker configure: error: invalid variable

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