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

From: Randall R Schulz <[email-masked]>
Date: Sun Aug 4 07:38:03 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:
>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.

Randy