[Ecls-list] [PATCH] Compiler error, Windows MSVC

[Juan Jose Garcia-Ripoll]

On Wed, Jan 25, 2012 at 5:56 AM, Andrew Paul <a2 at andrewpaul.com> wrote:

> With respect to the bug posted here:
>
> http://sourceforge.net/tracker/?func=detail&aid=3477551&group_id=30035&atid=398053
> I think I have found the problem and have corrected it:
>

Thanks a lot for the fix, Andrew. I am a bit surprised that this did not
pop up in any of my other installations (Debian, OSX, etc). I have
committed your patch to my local repository and will upload it later on
tonight.

In addition, there seems to be something wrong with asdf - when it is
> loaded, requiring a prebuilt contrib module (eg sockets) generates asdf
> errors, as it tries to handle it instead of the contrib loader.
> Error Output:
>
> Condition of type: FILE-ERROR
> Filesystem error with pathname #P"C:/ecl/sockets.fasc".
> Either
>  1) the file does not exist, or
> ...
> Broken at SI:BYTECODES. [Evaluation of: NIL] In: #<process TOP-LEVEL>
>

ASDF is confused by the fact that we have two types of compiled files:
native ones, built with a C compiler, ending in *.fas, and bytecompiled
ones, ending in *.fasc. I will upload a fix later on.


> Finally, a heads-up for anyone using a symlinked local-projects:
> write-file-date returns nil for windows symlinks (created with mklink /D )


This seems to be a problem with the runtime:
http://mingw-users.1079350.n2.nabble.com/How-to-check-if-file-is-a-Windows-symbolic-link-td6299831.html
Plus I have not found the Windows functions that allow me to detect whether
a file is a symbolic link or not. Handling of these objects seems to be
very lousily specified throughout the Windows API.

Juanjo
-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20120125/3c30c220/attachment.html>