Subject: [clisp-list] Next try for cygwin binaries for 2.29

From: Karsten <[email-masked]>
Date: Sat Aug 3 08:21:02 2002

I made a new binary release for cygwin that at least on my system builds 
correctly.
The binary is available on 
http://perso.wanadoo.es/karsten.poeck/clisp-2.29.1-i686-unknown-cygwin_me-4.90-1.3.12.tar.gz

The problem with cygwin is that the make distrib does not work correctly 
since the tar command does not resolves the links.

Un saludo

Karsten

---

From: Randall R Schulz <[email-masked]>
Date: Sat Aug 3 08:30:05 2002

Karsten,

Would you explain the problem you had with Cygwin's tar? It handles Cygwin 
symlinks (no other TAR command will, since Cygwin's symlinks are a 
specially tagged Windows shortcut) and likewise it handles hard links, 
provided the file system to which the files are being extracted or from 
which they originated is an NTFS file system volume (since that's the only 
Windows file system that supports hard links).

By the way, I must apologize for not being able to get the Cygwin package 
out, but attempting to compile it causes my system to hang (repeatably and 
reliably, when compiling a particular file). I think it's a hardware 
problem--the system hangs like this from time to time, though never before 
predictably or repeatably). So far I've neither diagnosed the real problem 
nor found a work-around.

Randall Schulz
Mountain View, CA USA

---

From: Karsten <[email-masked]>
Date: Sun Aug 4 05:01:02 2002

regarding the potential cygwin tar problems:

Let me first describe the effects:
Downloading and installing clisp-2.29-i686-unknown-cygwin_nt-5.0-1.3.12.tar.gz
results in the following error:

$ make
gcc -O  base/modules.o base/lisp.a base/libsigsegv.a base/libintl.a 
base/libicon
v.a base/libreadline.a base/libavcall.a base/libcallback.a -lncurses -lm -o 
base
/lisp.run
base/libintl.a: file not recognized: File format not recognized
collect2: ld returned 1 exit status
make: *** [base/lisp.run] Error 1

Inspecting libintl.a shows that it is a very short file containing some 
binary fields and fianlly some bytes looking like gettext/intl/libint.a 
gettext\intl\libintl.a

Similar things happens with nearly all files in the distribution. 
Interesting enough is src: all .lisp files are broken, all fasl files are 
correct.

Analysing this a bit further one can see that both fasl and lisp files are 
copied with the same instruction in the make distrib

ln $(LISPFILES) $(FASFILES) $(TOPDIR)/src

Ok, so a simple ln is not the problem.

By further inspecting the origin of the  lispfiles in the current directory 
one notes an important difference: The *.lisp files are already links ,e.g.
lrwxrwxrwx    1 default  544           153 Aug  3 23:53 xcharin.lisp -> 
../src/x
charin.lisp

By further investigation in the makefile one finds that the *.lisp files in 
the directory are generated via
ln -s, i.e. are symbolic links.

Conclusion:
In Cygwin applying ln -s to a file and afterwards ln to the link results in 
an unusable file. Since the same chain of instructions works fine in my 
Linux, I assume this is a problem within cygwin.

Now it seems i shoudn't have said that tar is the culprit, the problems 
seems to be a step earlier.

Karsten

PS:
A while ago somebody asked why bother with cygwin at all if there are so 
many problems with clisp. One reason is that at least on my box cygwin 
clisp is twice as fast a the windows clisp. It is even faster than in 
Linux, probably because I used gcc 304 in cygwin and gcc 2.95 something in 
Linux.

---

From: Randall R Schulz <[email-masked]>
Date: Sun Aug 4 07:36:02 2002

Karsten,

Interesting.

This is the precise problem that Sam Steingold reported to the Cygwin mail 
list just a few days ago. The head Cygwin developer, Chris Faylor (at 
Redhat) has already devised a fix but it's only available in a patch 
release of the Cygwin "kernel" (cygwin1.dll).

The problem, in short, is making a hard link to a symbolic link. That hard 
link to a symbolic link does not get the ".lnk" suffix it needs and so is 
not interpreted as a symbolic link, even though that's what its contents 
really are (since it's just a nother name for the symbolic link).

I can suggest a work-around that might make things manageable for you.

Wherever appears an "ln" (plain old hard-link "ln" invocations) whose 
target (first argument) is a symbolic link, the newly created link name 
should manually / explicitly supply a ".lnk" suffix.

Thus:

# "symLinkTarget" is a symbolic link to some other file
# "hardLinkToTarget" is the hard link to create
#   that should alias the "symLinkTarget"

# No good:
% ln symLinkTarget hardLinkToSymlink

# Work-around:
% ln symnlinkTarget hardLinkToSymlink.lnk

Here's an example:

% echo "realFile" >realFile
% ln -s realFile realFile-sl

# No good:
% ln realFile-sl realFile-sl-hl1

# Work-around:
% ln realFile-sl realFile-sl-hl2.lnk

# Test
% cat realFile
realFile
% cat realFile-sl
realFile
% od -c realFile-sl-hl1
0000000   L  \0  \0  \0 001 024 002  \0  \0  \0  \0  \0 300  \0  \0  \0
0000020  \0  \0  \0   F  \f  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000040  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000060  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 001  \0  \0  \0
0000100  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \b  \0   r   e
0000120   a   l   F   i   l   e  \b  \0   r   e   a   l   F   i   l   e
0000140
% cat realFile-sl-hl2
realFile

You can also simplly rename, via "mv", the existing hardlinks to the 
symbolic links that have no ".lnk" suffix:

% mv realFile-sl-hl1 realFile-sl-hl1.lnk
% cat realFile-sl-hl1.lnk
realFile

I hope that helps. I'll let you and Sam (and the CLISP list) know when a 
release version of Cygwin is available that fixes this problem.

Lastly, so you know and can think about the consequences, the fix that 
Chris Faylor has devised is simply to resolve the symbolic link when making 
a hard link to it. Thus a request to make a hard link to the symbolic link 
will end up making a hard link to the ultimate target of the symbolic link 
instead.

Good luck. Feel free to ask more about this or other Cygwin issues.

Randall

At 04:09 2002-08-04, Karsten wrote:
>v.a base/libreadline.a base/libavcall.a base/libcallback.a -lncurses -lm 
>-o base
>/lisp.run
>By further inspecting the origin of the  lispfiles in the current 
>directory one notes an important difference: The *.lisp files are already 
>links ,e.g.
>By further investigation in the makefile one finds that the *.lisp files 
>in the directory are generated via
>In Cygwin applying ln -s to a file and afterwards ln to the link results 
>in an unusable file. Since the same chain of instructions works fine in my