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 (e...@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/\0c\0r\0y\0p\0t\0o\0/\0d\0e\0s\0/\0d\0e\0s\0.\0h\0\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
--
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
