llvm dev - Nov 2005 - [LLVMdev] llvm-ranlib: Bus Error in regressions + fix

Evan Jones wrote:
> On Nov 23, 2005, at 18:17, Reid Spencer wrote:
>
>>> So this comment means that I should attempt to theoretically
support
>>> Windows, and close the current archive file before updating it?
>>
>> If you use sys::Path, it is not "theoretically" supported, it
is
>> supported.
>
>
> Well, except of course that it isn't currently possible to build LLVM 
> on Windows. Hence this is a somewhat theoretical issue.
>
News to me.  I do it all the time.  Notice the "win32" directory under
the root :)

On Nov 23, 2005, at 22:49, Jeff Cohen wrote:
> News to me.  I do it all the time.  Notice the "win32" directory
under
> the root :)
Okay, so I spoke about something that I don't really know about, since 
I don't use Windows. But what was the whole "Still can't compile 
backend of frontend on Windows" discussion about? My impression is that 
LLVM only builds under Cygwin. This doesn't really count (IMO) since it 
makes Windows look like Unix anyway, from an API perspective.

In fact, with regards to the specific "cannot unlink while open"
issue,
Cygwin works around it (partially) by removing the file as soon as the 
file is closed. I'm not sure that would be sufficient in this case, but 
it might be.

Evan Jones

--
Evan Jones
http://evanjones.ca/

Evan Jones wrote:
> On Nov 23, 2005, at 22:49, Jeff Cohen wrote:
>
>> News to me.  I do it all the time.  Notice the "win32"
directory
>> under the root :)
>
>
> Okay, so I spoke about something that I don't really know about, since 
> I don't use Windows. But what was the whole "Still can't
compile
> backend of frontend on Windows" discussion about? My impression is 
> that LLVM only builds under Cygwin. This doesn't really count (IMO) 
> since it makes Windows look like Unix anyway, from an API perspective.
No, it builds using Microsoft's Visual C++.  In fact, there have been 
more problems building it with cygwin than with Visual Studio.  The 
project and solution files for Visual Studio are all under the win32 
directory.  It uses the native Win32 API (see lib/System/Win32).  The 
entire backend, except for a (very) few tools, builds natively.  The 
front end cannot build this way because it's a hacked-up GCC, which is 
well known for being unbuildable with VC++.  But that isn't really 
LLVM's problem; we can just distribute a pre-built llvm-gcc binary 
compiled with cygwin or mingw.  Anyway, the usefulness of LLVM is not 
limited to compiling C/C++ code.
> In fact, with regards to the specific "cannot unlink while open" 
> issue, Cygwin works around it (partially) by removing the file as soon 
> as the file is closed. I'm not sure that would be sufficient in this 
> case, but it might be.
Cygwin isn't involved, so this is irrelevant.  Windows does permit a 
file to be deleted while it is still open, but only when it was opened 
with delete share permission.  This requires that the file be opened 
with the CreateFile API, which LLVM cannot do in a portable fashion.  
This functionality cannot be accessed via fopen.
>
> Evan Jones
>
> -- 
> Evan Jones
> http://evanjones.ca/
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>

Evan Jones wrote:
> Windows look like Unix anyway, from an API perspective.
> 
> In fact, with regards to the specific "cannot unlink while open"
issue,
> Cygwin works around it (partially) by removing the file as soon as the 
> file is closed. I'm not sure that would be sufficient in this case, but
> it might be.
That occurs because of a sharing violation within the Windows operating system. 
Windows doesn't have the notion of unlink. If you remove a file, its gone. 
There are no links. Consequently, if you try to modify a file that is open by 
another handle, you get a sharing violation.  To work around that, you have to 
close or remove the file first. Cygwin does work around this, but that is not 
our solution. We have Windows specific code in lib/System that also works 
around this by closing the file handles properly.  That is why I suggested that 
you use the sys::Path class so that the operations on the files work reliably 
on all platforms (and if not, we only have to fix it in one place).

Reid.