> /usr/bin/uptime always reports 0/0/0 average cpu load:
WJFFM
$ uptime
10:33:16 up 6 days, 14:06, 0 users, load average: 1.88, 2.04, 2.06
$ cat /proc/loadavg
1.88 2.04 2.06 2/5
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ:
Hi all,
I have some test code that forks number of processes, and it looks like under
Cygwin it fails at fork number 255 (plus minus one).
There is no getrlimit()'s RLIMIT_NPROC on Cygwin (unlike Unices) yet I see that
my shell somehow shows the process limit of 256:
$ ulimit -u
256
I tried to
Hi all,
I don't know how current this file is:
https://cygwin.com/cygwin-pkg-maint
but was the coreutils package orphaned? It's like 4 years old now.
It'd be great if it could be refreshed in Cygwin.
Thanks,
Anton
--
Problem reports: http://cygwin.com/problems.html
FAQ:
The problem maybe in ABI incompatibility with older C++ (not C++11-compliant)
run-time libraries:
In C++11 class inheritance for many standard exceptions has changed greatly, so
all the run-time
libraries must be recompiled to match the inheritance seen by the compiler in
the header files
(when
Hi List,
I have a question, is there a way to clone-install Cygwin?
Like I have installed whatever packages I selected on some PC, then maintained
that installation for a while,
doing upgrades etc. Now I need to install the exact same set on another PC.
Can I pull up a list and use it
in a so
> Cygwin is totally portable!
I wouldn't be so sure, as some package installation scripts do modify the
actual system, which is not contained within the Cygwin installation tree.
But mostly it is indeed portable.
> You can simply copy the installation folder
If you think that didn't occur to me
Hi All,
Another question for tonight:
So there's a program that basically enters a tight loop on some incorrect input
(and needs to be debugged, obviously).
The program is otherwise rather basic, doesn't use anything outside K&R C RTL.
When I run the program under gdb, I want to interrupt it w
> What is your environment? Windows version, cygwin version and etc...
$ uname -a
CYGWIN_NT-6.1 ANTON 3.1.0(0.340/5/3) 2019-12-01 05:20 x86_64 Cygwin
Windows 7 Home; Cygwin 3.1.0
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentatio
> attached my solution to re-install or duplicate the packages of an existing
> installation.
Thank you, Marco! I'll give that a try.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsub
> As the reg entries show, you can also do this by adding or setting registry
> entries using Cygwin regtool, Windows reg, or regedit commands.
It is better and much safer to use native Windows service controller commands,
than tweaking the registry:
sc config cygsshd start= delayed-auto
Also,
> Yes, this is possible.
Thank you.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Don't see where you read that?
The service control manager waits until the service stops or the specified
preshutdown time-out value expires (this value can be set with the
ChangeServiceConfig2 function). This control code should be used only in
special circumstances, because a service that h
Hi All,
Having upgraded my Cygwin install today, I still see the old coreutils package
v8.26, from 2016.
Looks like the current version is now 8.32, released in March this year. Can
Cygwin please get this updated?
Thanks,
Anton
--
Problem reports: https://cygwin.com/problems.html
FAQ:
Hi All,
In the updated Cygwin (3.1.4), /proc/cpuinfo still reports the microcode
version wrong.
Compare:
Cygwin:
$ uname -a
CYGWIN_NT-6.1 xxx 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model
> also have to look for Update Signature
It's Windows 7 here (Windows 10 uses newer registry key names, with the word
"Revision" in them, instead).
> Could you please run:
$ head /proc/version
CYGWIN_NT-6.1-7601 version 3.1.4-340.x86_64 (corinna@calimero) (gcc version
7.4.0 20181206 (Fedora Cy
> https://cygwin.com/pipermail/cygwin/2020-June/245104.html
Wow dude! I did not expect a whole sob story out of that simple reminder;
I did not urge anybody to do it right away, yet I just mentioned that the
package
was way out of its release cycle. I think that the time it took you to write
al
> but it is missing the patch used to adapt it to Cygwin.
> The patch modifies 27 files and unfortunately does not applies
> clean to latest upstream source.
Fair enough (and again, there was no pushing); but are you sure that all 27
patches are still actual?
Testsuite ran pretty well, though.
> I'll have to recheck how Linux handles these
JFYI I was in correspondence with the cpuid utility team lately, and they told
me that Linux uses vendor-specific MSRs to pull that info out:
> Check out:
>
>MSR_IA32_UCODE_REV
>MSR_AMD64_PATCH_LEVEL
>
> Both reference MSR 0x8b.
--
Proble
> Managed to get this tested and applied thanks to your help and it has landed
> in
> new Cygwin 3.1.6 so please post your results and any further comments when you
> have a chance to upgrade and test.
I checked it out in the new Cygwin 3.1.6, and it shows microcode version
correctly now, but as
> So I think you probably encountered another Windows sleep bug
Quite possibly... The microcode version in the registry looks okay after
wake-up from hibernate, though (but that subsumes the system POST and clean
boot).
> 0 - ucode loading supported by CPU - update available and successfully
> https://software.intel.com/security-software-guidance/insights/microcode-update-guidance
Thanks, interesting reading.
I think in my case the ucode update is done via the FIT method, though, as the
latest microcode (0xA0E) is included in the re-packaged BIOS, and re-flashed
into ROM along with
Hello,
I have a problem with the ping utility on Cygwin: it keeps crashing with
segmentation fault. I've checked that all my packages (including Cygwin core)
are up to date. What am I missing? At any rate, I guess it should not have
crashed ungracefully if it needs something it doesn't have (
Hi,
Please consider the following code:
$ cat bug.cpp
#include
using namespace std;
void fun()
{
string dummy;
cin >> dummy;
}
int main()
{
cout << "FAIL = 0x" << hex << ios::failbit << endl;
cout << "EOF = 0x" << hex << ios::eofbit << endl;
cout << "BAD = 0x" << hex
Hi,
Looks like CYGWIN defines but does not honor the SOCK_NONBLOCK flag when used
with socket(2).
(It also defines SOCK_CLOEXEC but I haven't checked whether it is honored --
full disclosure.)
Consider the following code:
$ cat bug.c
#include
#include
#include
#include
#include
#include
> Cygwin GCC is configured and built with the old C++ ABI, I'm guess that's the
> problem?
The problem is that it does not work correctly because G++ and its run-time are
not consistent.
GCC doc says version 7.x uses new ABI by default, so I'd guess that's the C++
stdlib which was built with t
Hi,
Thank you for adding the chattr/lsattr utilities to Cygwin base, I think they
can come very handy.
May I have a small suggestion, please:
To use -V/--version (that lsattr does already) consistently for both, and
-v/--verbose in chattr (and update the docs too).
-V is conventionally used f
Hi all,
We're having the following problem (on a subset(*) of Windows-10 machines) with
running cygserver.
Started afresh, strace shows no activity in it, but should I execute a command
(ipcs in the example below), then cygserver begins to experience freezes like
these:
5295758 62716455 [unkn
I was trying to figure out what SID cygserver was trying to access...
When I run ipcs without cygserver running, I see this SID is being retrieved
successfully:
359 2451151 [main] ipcs 10404 pwdgrp::fetch_account_from_windows: line:
When I run ipcs with cygserver, the SID, which looks very
Hi all,
It looks like the cygrunsrv utility hardcodes 30 seconds as a maximal time for
a service to start, then bails
out with a failure.
It would be quite useful (in certain situations) to have a command-line
parameter (for the -I option)
that can specify a service startup timeout, longer or s
> No, 30 seconds is a hard system timeout in which a service must reply with
> an appropriate control message to let services.exe know it is ready to
> continue startup sequence.
I don't think there is a hard-coded system timeout, as long as the starting
service keeps
posting its START_PENDING st
Hi all,
Here's the output from ldd, of an executable built just recently on Cygwin:
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc339d)
KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
(0x7ffc31a0)
KERNELBASE.dll => /cygdrive/c/WINDOWS/System
Well, I don't think there's anything special that Cygwin does to load
executables, because these are essentially Windows processes, so they are
loaded by Windows, first and foremost.
But it gets even weirder. Below are two _consecutive!_ runs of ldd on the very
same executable. Why the output
> But it gets even weirder. Below are two _consecutive!_ runs of ldd on the
> very same executable. Why the output differs so drastically (including the
> unknown dlls all of a sudden)?
Another round of consecutive calls of ldd on the very same executable file, and
a similar "indeterministic"
Hi,
Consider the following code:
$ cat cork.c
#include
#include
#include
#include
#include
#include
#include
#include
#include
#if defined(TCP_NOPUSH) && !defined(TCP_CORK)
# define TCP_CORK TCP_NOPUSH
#endif
int main(int argc, const char* argv[])
{
union {
struct sock
> Regular SO options on Windows:
I did not ask about Windows options. I asked about a feature that is defined
in Cygwin yet appears not functional.
> You can abuse Nagle to get similar behaviour cross-platform:
This is not the same thing!
> ENOPROTOOPT (109)... "The option is not supported by
> Linux and BSD options are not available, whatever the .h #defines.
Unsupported options should not be shown as features in the headers.
> Many header and library files are shared with newlib, which is used by Cygwin
If you checked before responding with a large digress into unrelated details,
y
> Why not just write a patch to fix this and send it to the cygwin-patches
> mailing list?
I had first to make sure that the feature is indeed unsupported (and I wasn't
100% certain because it was included in the header).
Actually, nobody confirmed to me that I am not "seeing things", only taugh
Hi,
Please consider the following shell session:
$ cat dummy.c
#include
int main()
{
return 0;
}
$ gcc -o dummy dummy.c
$ mv dummy.exe dummy
$ ./dummy
$ echo $?
0
$ chmod a-x dummy
$ ./dummy
-bash: ./dummy: Permission denied
$ rm dummy
$ touch dummy
$ ./dummy
$ echo $?
0
So Cygwin lets the
I have noticed a discrepancy between the process priority shown by "top" vs.
what getpriority() returns.
I'm using the procps-based "top", so it reads the priority value from
/proc/PID/stat. The value gets there via code found in "fhandler_process.cc":
/* The BasePriority returned to a 32 bi
> zero-sized? Irrelevant.
It is actually very relevant. Because executing an empty script results in
"success" (exit code 0) -- that creates a false-positive.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cy
> But what's your basis for saying that an empty script shouldn't be executable?
I meant it only in the context of the script file lacking the proper "x"
permission.
Of course an empty script _with_ such permissions allowed must be executable,
and it will always complete with exit code 0.
--
P
> Which is why, as Ken said, the size is irrelevant.
Which makes your comment irrelevant as well. Read the thread what I was
responding and to whom before trolling.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: htt
> I did read the thread.
Really?
> which you confirmed after the fact.
Oh really? Then read again:
In my initial post that started the entire thread I wrote:
> On Unix, an empty file can only be executed (exit code 0) if there's the "x"
> permission granted.
So what's your deal, exactly?
> You seem to have worked it out already so please send a patch in
> git format-patch foramt to the cygwin-patches mailing list.
I tried :-/
:
Sorry, only subscribers may post. (#5.7.2)
I do not use git to pull Cygwin sources. The last snapshot (that corresponds
to the last-known-stable releas
I'm noticing that in a high-contention situation (many processes try to get
ahold of a semaphore) semget() on Cygwin starts to return EAGAIN (try again)
after about 62 processes has gotten to call semget() and are actively competing
for the semaphore (i.e. using the semaphore ID semget() returne
> The number of parallel open pipes, for instance. By default, 10
> worker threads handle the load and up to 62 processes can be handled
> in parallel.
Hmm, so it is not an OS-imposed restriction... Then I don't understand why it
wasn't made to "just work":
to create a thread per client until t
> Please give it a try.
diff --git a/winsup/cygwin/fhandler_process.cc
b/winsup/cygwin/fhandler_process.cc
index 2a06554..2305b53 100644
--- a/winsup/cygwin/fhandler_process.cc
+++ b/winsup/cygwin/fhandler_process.cc
@@ -1076,7 +1076,7 @@ format_process_stat (void *data, char *&destbuf)
unsign
> I pushed your patch with a short commit message.
Thanks! Thinking about that a little more, getpriority(PRIO_PROCESS) returns
the cached version of priority (since the last
setpriority()) but should return "live" version by re-getting and re-caching
the actual thing from the system:
1. The pr
Hi,
Here's the situation, I have a netmount "Z:" but I cannot make any files on it
executable from Cygwin:
$ mount
...
Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto)
$ cd /cygdrive/z
$ pwd
/cygdrive/z
$ cat a.c
#include
int main()
{
printf("Hello world!\n");
return
> Following up on the original report of 3/10/2019.
Sorry to disappoint, but in no way it was an original report
https://cygwin.com/ml/cygwin/2018-07/msg00048.html
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http
Hi,
So nobody has any suggestions per this?
https://cygwin.com/ml/cygwin/2019-08/msg00126.html
TIA
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/
Thanks for responding!
> You need the "exec" mount option.
I thought so too, but how do I give that option to a drive that is "noumount".
I cannot dis- or re-mount it AFAICT.
$ mount
...
Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto)
$ umount /cygdrive/z
umount: /cygdrive/z:
> What is your cygdrive mount options? Because default is, apparently,
> "binary,posix=0,user".
I have no idea where they are kept at, and how to change them.
Also, I couldn't make this work, anyways; yet I thought it should have worked:
> > $ mount -o exec //coredev2/home/lavr /mnt
> > $ mount
> If it's related to the ACL handling then it should start working when
> you remove the ACL on the file with 'setfacl -kb ...'
There are no special ACLs set on the file (that was just produced by GCC from
the source code, see my first email).
But I am now convinced that the problem is _entirely
> Have you checked the default ACL on the directory containing the file?
No, and there's nothing special there now that I checked. I can change the
"Read & Execute" for the .exe file from the Windows file properties
without having to deal with anything special or additional (like inherited
perm
> I suspect the containing directory has a lot to do with it.
Please elaborate what you ground your suspicion on.
Like I said previously, I can add "Read & Execute" permissions to the file in
question from the Windows
file properties dialog, and it gets converted to an "x" on Linux side, then th
> Feel free to provide a patch, just, please, create a valid git commit message
"getpriority() consistent with process priority
https://cygwin.com/ml/cygwin/2019-08/msg00122.html";
The changeset is really trivial:
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index a914ae8.
> See the '+' at the end of the modes?
I saw that, and I also showed the "getfacl" output for that file and the
directory above, which showed
nothing additional.
> Maybe, but we'd still need to know how to get to the result you're seeing.
Just take a samba server (4.x) and mount a share with de
> You can often figure permissions problems
I already figured where the problem was, in how cygwin convers (or, actually
doesn't) the UNIX's "x" bit into
the native DAC for the underlying filesystem (to store as, again, "x" in the
Linux share). Missing that DAC, SMBD
returns "Access denied" for
> This is called by acl_to_any_text, which is called by getfacl. Any
> chance you could try to debug this?
> I'm about to go on vacation, but I could try to help when I get back.
I'm headed out of town as well. But I get this very same EINVAL for any drive
(/cygdrive/X)
except for the local d
> git format-patch output with commit message, please?
Please educate me how to do that; I am just using "git diff --no-color".
> The commit message should describe what the problem is and how the patch
> fixes it. One or
> two sentences are enough.
The commit message is there:
> > "getprior
Thanks for the hints!
> so...what's your umask?
It's 022. As far as it's concerned, umask should only be considered when
creating a new file, not to affect existing files' modes
(as with the chmod command). At any rate, the "x" bit in mine is unset, so
should not be having the issues what you
Hi,
When Cygwin generates a stacktrace (coredump) is it possible to get more than
16 frames printed out?
Looking at exceptions.cc, seems like not. Can it please be increased to 32,
for example?
Thanks,
Anton
--
Problem reports: http://cygwin.com/problems.html
FAQ: htt
Hi all,
I have the following stack trace (64 bit Cygwin app), and I can't figure how
the same frame RBP at 000C7B0 can be listed 3 consecutive times for various
functions (RIPs). Also if I follow the stack trace with gdb (and the trace is
all within Cygwin.dll based at 18004), it does
Hi all,
Here's a situation: I have a binary that was built (from a C source code) with
Cygwin 3.0.7 but "accidentally" used with much older Cygwin 2.11.2.
The binary won't actually launch. Instead, it most uneventfully (silently, no
crash - no drama) exits with an exit code of 127, meaning "co
> > During startup program exited with code 0xc139.
> so Windows handles termination.
IMO if it did, the exit code wouldn't have been 127 but something with decimal
equivalent of 0x139 (or the likes).
> P.S. I didn't get to know what exactly the entry point was missing that the
> binary re
getfacl does not work even for the .socket "file" in my home directory for
which ~/sun works perfectly fine with permissions
(and all subdirectories crated with mkdir under it).
Also like I said, ~/sun also works perfectly fine in /cygdrive/g/cygwin/ but
not if I created a subdirectory with the
> Cygwin does not do this on a standard installation. Is it something you've
> done
I did use the standard Setup and nothing else... My $HOME looks fine, too:
$ cd
$ pwd
/home/ANTON
$ getfacl .
# file: .
# owner: ANTON
# group: None
user::rwx
group::---
other::---
default:user::rwx
default:gro
> That way I'm sure I won't have any surprises with permissions when working in
> /cygdrive/g/cygwin. Do you want to try that and see if it makes a difference?
I have no problems with /cygdrive/g/cygwin -- my socket file gets created there
with proper
permissions and reported so, too (both fstat
Looks like your program does not throw an exception on Cygwin (unlike it does
on Debian),
so it terminates normally, and the exit code 0 is not unexpected. Debian's
version
calls abort() and that sends a signal and terminates with a code 128+signal#,
and
SIGABRT=6, so 134 is the expected result
I forgot to mention that my "umask" is the standard 022...
The man page says that for directories with the ACLs, it is ignored.
So in my code bind() wouldn't have created the socket with 0777, and
that's fine! Which is why I call fchmod() to fix the permissions up,
and THAT does not work. BTW,
> what your test program was actually doing. But you seem to be assuming that
> calling fchmod on a socket descriptor should affect the permissions on the
> socket file (assuming the socket is bound). Is that documented anywhere?
> POSIX
> says that the behavior of fchmod on a socket descriptor
> That's not what I'm seeing when I run your test program on Linux:
>
> $ ./sun
> fstat mode = 140666
> stat mode = 140777
True, but it creates the socket file with exactly how umask(0) told it to,
and stat() shows that. So yeah, I should retract that it works on Linux with
fchmod() -- on Linux
Hi,
There's some inconsistency between and :
sys/select.h has this:
---
/*
* Select uses bit masks of file descriptors in longs.
* These macros manipulate such bit fields (the filesystem macros use chars).
* FD_SETSIZE may be defined by the user, but the default here
* sh
> I'm no expert, but it seems the FD_SETSIZE should have been 128.
> Long is 8 bytes, 64 bits. One bit if one open file, 64 * 64 = 4096.
FD_SETSIZE is the file descriptor bitset capacity in _BITS_.
64 (as currently in there) means 1 int (on 64 bit platforms, or 2 ints on 32 bit
platforms, respect
> On Linux, select(2) is really only capable to
> handle file descriptors numbers up to descriptor number 1023,
That is not true. While FD_SETSIZE is defined as a fixed constant,
Linux kernel does not actually "know" (or care) about it.
So you can have an array of fd_sets, like this, in your cod
> Remember that 64 is MAXIMUM_WAIT_OBJECTS for WaitForMultipleObjects(),
> the underlying Win32 API used to implement select(), so using more than
> 64 hits some complex code to work around that...
True but the complex code (that involves thread spawning, if that's what you're
referring to)
will
> DESCRIPTION
>WARNING: select() can monitor only file descriptors numbers that are
>less than FD_SETSIZE (1024)-an unreasonably low limit for many modern
Whoever wrote this, was wrong (they might have never consulted the actual
kernel code, or were just
blindsided by FD_SETS
> However, discussing this shows how irrelevant the actual default value
> of FD_SETSIZE is.
Correct, yet the comments in the header files (along with used values) should
be consistent :-)
> [...] to define FD_SETSIZE according to its requirements anyway.
That'd work for CYGWIN right away; but
Hi all,
I need to do some deep debugging on Cygwin so I need to produce a core... And
it does not work.
So I reduced the problem to this minimal test case:
$ cat a.c
#include
int main()
{
abort();
}
$ gcc -Wall -g a.c
$ echo $CYGWIN
error_start=c:\cygwin64\bin\dumper.exe
$ ulimit -a
c
> Try using a more recent gdb. I just tried your test case with gdb-12.1-1
> (available as a test release), and it seemed to work.
Thanks for the quick response... Though I'd rather not use test releases.
The dumper binary and gdb in my case are supposed to be consistent with each
other
(insta
> The latest version of gdb that is not a test version is 11.2. But
> you are using 9.2.
I am using the older dumper as well, my working cygwin is not cutting edge.
$ dumper -V
dumper (cygwin) 3.2.0
What I am coming at is that if dumper is not consistent with gdb,
that does not make any sense.
> I've learned that once I get a setup that seems to be stable
That's what I thought about my 3.2.0 setup, too, but following your own
conclusions about the rolling release, one can never be sure...
Anyways, maybe it's time for me to upgrade. I did not because it looked
like 3.3 was coming out w
Hi all,
It took me awhile to figure this one out, but I think I have a good test case to
demonstrate a (rather serious, actually) issue with Cygwin sockets and
select/poll.
In short, when a reading end of a socket half closes for write (basically,
signaling the
other end of no more data to expe
> This was fixed in Cygwin 3.3.0, as the announcement of the latter stated:
Thanks! So maybe it is time to upgrade... after all LOL
> But you can still run a parallel Cygwin installation
I tried that before... And it did not work out well. Unless it's a VM,
there's a small but real chance tha
> I then see "C-@" echoed in the minibuffer, and the resulting *Help* buffer
> says
WFIW, in the DEC VT terminals (from where most of ANSI controls stem from),
Ctrl-Space used to
generate a NUL character (ASCII '\0'), and so maybe it is seen as a fill
character by the OP's
terminal and, therefo
> Cygwin also generates NUL:
Thanks for checking! NULs were used as fill characters to throttle down the
line speeds, and were supposed to be ignored
in both hardware and software... I guess with the software terminal emulators
(such as MinTTY/Windows console/and such), that depends
on setting
> It seems that there's an exception: If no process has ever had the FIFO open
> for
> writing since it was opened for reading, then the FIFO is not considered to be
> at end-of-file.
IMO, when a virgin FIFO is read with a blocking read (of just one byte), it
will block -- it will not return 0.
> provided you run at least Windows 8.1
Why would that be a requirement?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: htt
> contains patches dropping W7 and W8 support:
Hmm... I understood that "dropping support" was not something that would
_require_ newer OS,
but that it may not work (or not guaranteed to work, patches not checked for
compatibility, etc)
on the older OSes... Are you saying that W7 and W8 would b
> for 3.5 (late 2023) we announced the deprecation of Windows 7 and 8
> since the first 3.3.0 release in October 2021.
I saw that. It did not look alarming. It basically was like "you'll be on
your own".
> Supporting older OSes requires to keep workarounds in the code and
Understood. But you
Sorry for pressing this, I must be slow today.
> just won't run correctly anymore on W7/8
Won't or may not?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com
> Let's consider this problem again, but I don't see a quick and easy
> solution.
$ realpath /cygdrive/s/ado/msadox.dll
/cygdrive/s/ado/msadox.dll<== IMO the problem is actually here
$ realpath msadox.dll
/cygdrive/c/Program Files/Common Files/System/ado/msadox.dll
Both paths sho
corect.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> -Original Message-
> From: Cygwin On Behalf Of
> Lavrentiev,
> Anton (NIH/NLM/NCBI) [C] via Cygwin
> Sent: Monday, December 12, 2022 9:53 AM
> To: cygwin@cygwin.com; Frank Redeker
> Cc: Corinna Vinschen
> Subje
> The problem is that resolved paths may become longer than MAX_PATH.
Oh... But that'd be the same on any other OS that exceeds MAX_PATH, symlinking
is going to help work around that,
if the full path resolution was requested.
BTW, about MAX_PATH -- was it Cygwin's or Windows'? If the former,
Was supposed to be:
> symlinking is *NOT* going to help work around that
Sorry I am struggling with MS Outlook this morning
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:ht
> I still think it's a bug in the code which requires some debugging effort
> on your side.
I think that OP does not understand that the page size constant is a property
of the platform, and not something that can be redefined at will even though
it's a macro.
> > #ifndef __CYGWIN__
> > #define
> > returns 3 and sets errno to zero.
Note that "setting errno to zero" is not guaranteed in case of a successful
completion of a library function or a system call.
Generally, "errno" reflects an error that occurred last when such a call failed
(so in other words, in case of a successful
complet
Please pay close attention to how the command was shown to you, including the
use of the whitespace:
> >$ LC_MONETARY="en_ZM.utf-8" locale -ck LC_MONETARY
> In the terminal, when I use $LC_MONETARY = "en_ZM.utf-8" locale -ck
> LC_MONETARY
> Cygwin replies "-bash: LC_MONETARY: command not fou
> Sorry, the second gdb command should be
> info line *__assert+0x42a4
> > (Note the change in symbol name: two "_" there)
>
I think it'd be easier to "catch" the problem rather than to chase it by
running all commands under the debugger.
For that, define the CYGWIN environment variable (vi
1 - 100 of 199 matches
Mail list logo
