How to make Cygwin handle Unicode symbolic links?
Larry Martin
Larry@GlueLogix.com
Fri Jan 3 20:55:03 GMT 2025
> I assume you meant
>>> cygcheck
>> <https://cygwin.com/cygwin-ug-net/cygcheck.html>, not symcheck ?
You're right, of course.
> what do you have for the CYGWIN environment variable,
There is no CYGWIN environment variable on either system:
> $ set | grep CYG
> CYG_SYS_BASHRC=1
Actually, I think I have the whole problem wrong. I just noticed that
the symlink is not identified as such, system to system. Here it is on
my "good" system:
> $ ls -l des.h
> lrwxrwxrwx 1 Larry Larry 22 Jan 12 2023 des.h -> ../../crypto/des/des.h
but on the "bad" system it's just a file to `ls` as well:
> $ ls -l des.h
> -rwxrwx---+ 1 Administrators None 58 Jan 3 12:21 des.h
I just pulled https://openssl.org/source/openssl-1.0.2p.tar.gz and the
shipped include folder is empty, so part of the build process must be to
set up the include links. When you copy those symlink files, even
through revision control, you lose the special permission bits. That's
the problem. Unicode was a red herring.
Apologies to the list. Can you delete a thread?
Larry
On 1/3/2025 3:40 PM, David Dyck wrote:
> I assume you meant
>>> cygcheck
>> <https://cygwin.com/cygwin-ug-net/cygcheck.html>, not symcheck ?
> ( i've been "into" symbolic links in cygwin today so the title caught
> my eye )
>> what do you have for the CYGWIN environment variable, I've been using
> winsymlinks:native
> eg
> export CYGWIN=winsymlinks:native
>> On Fri, Jan 3, 2025 at 11:58 AM Larry Martin via Cygwin
> <cygwin@cygwin.com> wrote:
>> I have two Cygwin systems, seemingly identical. But one can compile
> openssl and one can't. The problem occurs in the symbolic links that
> come with the source. They all seem to be Unicode, or at least
> recognizeable ASCII characters with 0x00's in between. Cygwin on my
> regular development system processes those symlinks just fine.
> But on a
> second PC, Cygwin just sees the symlink as a file. Per the
> instructions, the output of `symcheck -s -v -r` for both systems is
> attached. Neither system has any environment variables starting with
> "LC_" or "LANG".
>> In order to describe the problem, I have to use examples from
> openssl.
> Please remember that this is a Cygwin question, not gcc or
> openssl. I'm
> also aware that my openssl version is quite old. There are reasons
> for
> that. It doesn't affect this question.
>> On the "bad" system, the first error is "stray '377円' in program"
> when
> gcc parses openssl/include/openssl/des.h. That is a symlink to
> ../../crypto/des/des.h. In my compile folder on the bad system, this
> happens:
> > $ head openssl-1.0.2p/include/openssl/des.h
> > !<symlink>??../../crypto/des/des.h
> Note that Cygwin did _not_ follow the symlink, but printed it out
> like
> any other file.
>> On the "good" system, the same command goes more like this:
> > $ head openssl-1.0.2p/include/openssl/des.h
> > /* crypto/des/des.h */
> > /* Copyright (C) 1995-1997 Eric Young (eay@cryptsoft.com)
> > * All rights reserved.
> where Cygwin _has_ followed the symlink.
>> In emacs, the symlink in question looks like Unicode:
> > !<symlink>
> >
> .0円.0円/0円.0円.0円/0円c0円r0円y0円p0円t0円o0円/0円d0円e0円s0円/0円d0円e0円s0円.0円h0円0円0円
> It is the same on both systems.
>> When I make a new symlink on either system, it is unreadable, so I
> can't
> dump it with any hex editor including od. However, the file length
> seems to be about half that of the openssl source tree links, so it's
> probably UTF-8.
>> The question is: what might be different between these two
> Cygwin/Win11
> systems, where one follows a Unicode symlink and the other doesn't?
>> Thank you.
>> --
> Problem reports: https://cygwin.com/problems.html
> FAQ: https://cygwin.com/faq/
> Documentation: https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>
--
Larry Martin
www.GlueLogix.com
RFID for Label, Card and Wristband Makers
USA 919.342.0201
backup email: GlueLogix at gmail dot com
More information about the Cygwin
mailing list