Re: New cygwin install hanging on postinstall
Ken Brown cornell.edu> writes: > Check setup.log.full. If that doesn't help, try running the script > manually to see what happens (most likely a fork failure requiring a > full rebase). Well, if it's really a fresh install, the full rebase just has happened, so if there's still a fork problem it has to be BLODA. To the OP: if you're using any third-party anti-virus solution, please try if exempting the Cygwin install directory from the real-time and/or heuristic scans helps. In some cases you can re-enable those functions after a manual full scan, but you would likely run into the same problem again when the Cygwin packages get updated. Regards, Achim. -- 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
Re: gdb 7.8 consistently fails to run executable - error is
Jon TURNEY wrote > On 14/01/2016 16:02, Tim Chick wrote: >> Jon TURNEY wrote > > I built a 32-bit version as well, but there was a slight delay with that > getting moved into the release. It should be mirroring out now, though. Hi Jon, I've just tried the 7.10.1-1 package, and it works fine for me. Thanks! Tim -- View this message in context: http://cygwin.1069669.n5.nabble.com/gdb-7-8-consistently-fails-to-run-executable-error-is-dll-path-too-long-tp110722p123827.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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
Re: less.exe v481-1 cannot seek to EOF in CRLF file; current cygwin32, Win10 only.
On 20/01/2016 19:32, KARL BOTTS wrote: In less.exe, when I use either the G or F commands on a largish CRLF file, it responds: How largish ? On Cygwin 32 bit and W7-64 I see no problem with 224 Mbytes Cannot seek to that file position (press RETURN) in the bottom "command editing line" of the display. No problem on LF-only files. Does happen with either mintty or Windows-Console, launched from either bash or cmd.exe. Two files are attached: Karl2.cygcheck.out, which is the 'cygcheck -s -v -r' output, and LessBugMoreInfo.txt, which contains background info and some speculation. --- Karl Botts, kdbo...@usa.net can you try to update to latest ? You have less 471-1OK cygwin 2.1.0-1 OK we are at cygwin 2.4.0-1 less481-1 Regards Marco -- 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
Re: df inconsistent with mount after adding a drive
On 21/01/2016 06:34, Miya Miller wrote: $ mount C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) C:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) F: on /cygdrive/f type ntfs (binary,posix=0,user,noumount,auto) $ df Filesystem 1K-blocks Used Available Use% Mounted on C:/cygwin64249698300 234618120 15080180 94% / D: 468815868 365211272 103604596 78% /cygdrive/d $ After adding an F drive a few months ago, df has been ignoring it. (Thank you) -- Dar Miya, please follow the guideline: Problem reports: http://cygwin.com/problems.html "Run cygcheck -s -v -r > cygcheck.out and include that file as an attachment in your report. Please do not compress or otherwise encode the output. Just attach it as a straight text file so that it can be easily viewed." Can you also run /usr/lib/csih/getVolInfo /cygdrive/f and provide the output ? It is part of "csih" package Regards Marco -- 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
Re: Any progress on "Fork issues ith long command lines and long $PATH"?
On 1/20/2016 9:20 PM, Richard Heintze wrote:
On 1/19/2016 6:34 PM, Richard Heintze wrote:
Regarding my choice of terms: I was trying use terms consistent with that old
link
"https://cygwin.com/ml/cygwin/2011-02/msg00416.html";.
That message doesn't even mention emacs. That's why I said in my first
reply to you that I couldn't make much sense of what you wrote.
(1) So is there a fix for the problem described in this link
"https://cygwin.com/ml/cygwin/2011-02/msg00416.html";? According to
Corinna Vinschen's comments it is a Cygwin problem, not an emacs problem. I
would love to have a fix.
I still don't know the connection between that message and emacs. Could
you say exactly what problem you're having?
(2) I was using $USERPROFILE as an example. We have dozens of these environment
variables pointing to dozens directories. They enable us to type in the same file name
to emacs's find file (ctrl-x-ctrl-f) regardless >of who is logged in or which
computer we are logged into (assuming that every account has the same directory
structure and propertly defined environment variables). Yes we can manually translate
them at a bash >prompt but this is a lot more typing, cutting and pasteing. We also
share the same .emacs file that contains thousands of file names that contain these
environment variables. We will really missing feature of native >emacs.
The fact that C-x C-f expands environment variables is not a special
feature of native Windows emacs. But the expansion has to yield a valid
file name. In the case of Cygwin emacs, that means a Posix path.
Maybe you could write a script that uses cygpath to convert the relevant
environment variables to Posix paths, and then call this script from
your .bashrc.
Ken
Ken:
Thanks for being persistent! I'm sorry for the confusion. I had to google search
"top post". I hope I'm doing it right now.
Yes, thank you.
When I run the bash prompt directly by clicking on the Cygwin icon, everything
is fine.
When I run Cygwin or native emacs on win 8 and use the emacs compile or async
shell command to run a bash command everything is fine.
When I run Cygwin emacs on win 10 and use the compile or asynch shell command
run bash command everything is fine.
However, when I run native (FSF/windows) emacs on win10 and use the compile or asynch shell command
to run bash commands that contain a pipe ("|") or child ($(bashcommand)), I get very
similar symptoms (maybe the same) as "https://cygwin.com/ml/cygwin/2011-02/msg00416.html";.
Please give details. What command did you give? How long is your PATH?
What error message did you get?
For example perl -e 'print "hello"' is fine. However, echo $(perl -e
'print "hello"') causes a stack trace like
"https://cygwin.com/ml/cygwin/2011-02/msg00416.html";
After reading Corinna's comments I'm thinking this is a Cygwin/bash problem.
What do you think?
I really have no idea whether your problem is the same as the one in the
bug report you cite. But that report says the problem occurs when the
command line or PATH is very long. You haven't given enough details for
us to know whether that's the case in your setting. Also, the fact that
you have problems only on Windows 10 makes me think something completely
different might be going on.
In the meantime, I'm looking into patching emacs so that the Cygwin
build will accept Windows file names, at least under some circumstances.
If I can do that without breaking anything else, I'll put out a test
release.
Ken
--
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
cygpath 2.4.0 (32-bits) in error?
Hi Corinna, The truth is out! :-) @@ 'cygpath -S -u' (2.4.0, 32-bits) informs us that the system directory is: /drv/c/Windows/SysWOW64 However, it probably not what we want here. (hint: do_sysfolders() in utils/cygpath.cc) Regards, Henri - @@ uname -a CYGWIN_NT-6.1-WOW Seven 2.3.1(0.291/5/3) 2015-11-14 12:42 i686 Cygwin @@ /usr/bin/cygpath -S -u /drv/c/Windows/System32 @@ /usr/bin/cygpath -S -w C:\Windows\System32 - %% uname -a CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin %% /usr/bin/cygpath -S -u /drv/c/Windows/SysWOW64 < Nice, the truth is out! ... but do we want it here? %% /usr/bin/cygpath -S -w C:\Windows\system32 %% %% /usr/bin/cygpath -S -U /proc/cygdrive/c/Windows/SysWOW64 < ditto = -- 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
Re: cygpath 2.4.0 (32-bits) in error?
Houder xs4all.nl> writes: > %% uname -a > CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin > > %% /usr/bin/cygpath -S -u > /drv/c/Windows/SysWOW64 < Nice, the truth is out! ... but do we want > it here? > %% /usr/bin/cygpath -S -w > C:\Windows\system32 > %% > %% /usr/bin/cygpath -S -U > /proc/cygdrive/c/Windows/SysWOW64 < ditto Well /usr/bin/cygpath -u $( /usr/bin/cygpath -Sw ) delivers the right result. I guess an option to chose which result to get might be nice, but I can cope either way. Regards, Achim. -- 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
Re: cygpath 2.4.0 (32-bits) in error?
On 2016-01-21 16:11, Achim Gratz wrote: Houder xs4all.nl> writes: %% uname -a CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin %% /usr/bin/cygpath -S -u /drv/c/Windows/SysWOW64 < Nice, the truth is out! ... but do we want it here? %% /usr/bin/cygpath -S -w C:\Windows\system32 %% %% /usr/bin/cygpath -S -U /proc/cygdrive/c/Windows/SysWOW64 < ditto Well /usr/bin/cygpath -u $( /usr/bin/cygpath -Sw ) delivers the right result. I guess an option to chose which result to get might be nice, but I can cope either way. ... :-) But I was only pointing out a difference between 2.3.1 and 2.4.0 ... (and I even did not bring up SysNative this time ;-) Regards, Henri -- 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
Re: cygpath 2.4.0 (32-bits) in error?
On Jan 21 15:11, Achim Gratz wrote: > Houder xs4all.nl> writes: > > %% uname -a > > CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin > > > > %% /usr/bin/cygpath -S -u > > /drv/c/Windows/SysWOW64 < Nice, the truth is out! ... but do we want > > it here? > > %% /usr/bin/cygpath -S -w > > C:\Windows\system32 > > %% > > %% /usr/bin/cygpath -S -U > > /proc/cygdrive/c/Windows/SysWOW64 < ditto > > Well > > /usr/bin/cygpath -u $( /usr/bin/cygpath -Sw ) > > delivers the right result. I guess an option to chose which result to get > might be nice, but I can cope either way. I hate this path redirection stuff. Patches welcome. Maybe we should simply replace SysWOW64 with System32, a simple string operation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Performance of "ls -F"
I am finding a large performance gap between plain "ls" and "ls -F" in a directory with many files on a network share (NetApp disguised as NTFS if that matters). This has been there for quite a while, I've just now realized what the reason was (I have "ls -F" as an alias for "ls" in my interactive shells). In a directory with 1300 files, a plain "ls" completes in 0.3s, while "ls -F" requires about 95s. Determining the file class seems to require around 70...90ms per file, which I can confirm also for directories with a lot less files. What's involved in that determination that takes such a long time? Regards, Achim. -- 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
Re: Performance of "ls -F"
On Thu, Jan 21, 2016 at 10:44 AM, Achim Gratz wrote: > I am finding a large performance gap between plain "ls" and "ls -F" in a > directory with many files on a network share (NetApp disguised as NTFS if > that matters). This has been there for quite a while, I've just now > realized what the reason was (I have "ls -F" as an alias for "ls" in my > interactive shells). In a directory with 1300 files, a plain "ls" completes > in 0.3s, while "ls -F" requires about 95s. Determining the file class seems > to require around 70...90ms per file, which I can confirm also for > directories with a lot less files. What's involved in that determination > that takes such a long time? The overhead appears to be in checking for executable files; using --file-type instead of -F, which just omits the '*' category, reduces the time for ls in one of my (local) large directories from over one second to 0.04 seconds. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- 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
Re: Performance of "ls -F"
William M. (Mike) Miller gmail.com> writes: > The overhead appears to be in checking for executable files; using > --file-type instead of -F, which just omits the '*' category, reduces > the time for ls in one of my (local) large directories from over one > second to 0.04 seconds. Indeed. Thanks for letting me know! Regards, Achim. -- 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
RE: New cygwin install hanging on postinstall
> -Original Message- > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On > Behalf Of Stephen John Smoogen > Sent: Wednesday, January 20, 2016 4:19 PM > To: cygwin@cygwin.com > Subject: Re: New cygwin install hanging on postinstall > > On 20 January 2016 at 17:06, KARR, DAVID wrote: > > I was installing cygwin for the first time on a Win7-32bit box. > It is hanging in postinstall, with "0/Perpetual" and > "/etc/postinstall/0p_texlive_prep.dash. I've tried this twice now, > and it hangs effectively forever on this step (waited 15-20 minutes > each time). What other information could I provide? I looked at > the end of the setup.log file, but that just indicates that > installation was complete. > > > > How much memory does this system have? I know that TexLive is a > real > memory hog these days in certain parts.. Does removing TexLive from > your install list go past this? It has 4g RAM. Checking "Resource Monitor" while the install is running, there is 750MB "available". I tried searching for "texlive" and setting all of those to "uninstall". The "postintall" step spends quite a while on "0p_000_autorebase.dash", but I noticed that before. However, after that finishes, it then sits on "0p_texlive_prep.dash". While it's sitting here, I dumped out "/var/log/setup.log.full". Here is the end of the file: The following DLLs couldn't be rebased because they were in use: /usr/bin/cygssp-0.dll /usr/bin/cygperl5_22.dll /usr/bin/cyggcc_s-1.dll /usr/bin/cygcrypt-0.dll /usr/lib/perl5/vendor_perl/5.22/i686-cygwin-threads-64int/auto/List/Util/Util. dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/IO/IO.dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/File/Glob/Glob.dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Fcntl/Fcntl.dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Encode/Encode.dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Digest/MD5/MD5.dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Cwd/Cwd.dll 2016/01/21 09:15:40 running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_texlive _prep.dash" 2016/01/21 09:19:20 note: Nothing needed to be installed 2016/01/21 09:19:20 Ending cygwin install --- Note that the current time is currently 9:37AM. The log file hasn't updated in almost 20 minutes. I would run the script manually, but I don't know what to run. I tried to exclude c:\cygwin from the virus scanner, but it seems doubtful that the installer would go through all the other steps if this was really an issue.
Re: libgtk3-devel dependency missing
On 2015-12-10 16:20, Ken Brown wrote: I think libgtk3-devel should require libepoxy-devel: $ grep epoxy /usr/lib/pkgconfig/gtk+-3.0.pc Requires.private: atk atk-bridge-2.0 epoxy >= 1.0 pangoft2 gio-unix-2.0 >= 2.45.8 Thanks; hopefully the GNOME deps are fixed now. -- Yaakov -- 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
Re: cygpath 2.4.0 (32-bits) in error?
On 2016-01-21 16:42, Corinna Vinschen wrote:
On Jan 21 15:11, Achim Gratz wrote:
Houder xs4all.nl> writes:
> %% uname -a
> CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin
>
> %% /usr/bin/cygpath -S -u
> /drv/c/Windows/SysWOW64 < Nice, the truth is out! ... but do we want
> it here?
> %% /usr/bin/cygpath -S -w
> C:\Windows\system32
> %%
> %% /usr/bin/cygpath -S -U
> /proc/cygdrive/c/Windows/SysWOW64 < ditto
Well
/usr/bin/cygpath -u $( /usr/bin/cygpath -Sw )
delivers the right result. I guess an option to chose which result to
get
might be nice, but I can cope either way.
I hate this path redirection stuff. Patches welcome. Maybe we should
simply replace SysWOW64 with System32, a simple string operation.
Hi Corinna,
Did not mean to get you angry ...
do_sysfolders() in cygpath.cc has changed between 2.3.1 and 2.4.0 where
it attempts to ascertain the 'system directory'.
The postprocessing after GetSystemDirectoryW() is different ...
The call to NtQueryInformationFile() in 2.4.0 spoils the result that has
been obtained by GetSystemDirectoryW() call.
Reverting your modification makes cygpath correct again (tested:
32-bits).
It is clear from the commentary what you are attempting to achieve after
the call to GetSystemDirectoryW() ...
However, the code after the call to GetSystemDirectoryW() is a mystery
to
me. Sorry.
Regards,
Henri
do_sysfolders() in cygpath.cc
-
2.3.1
case 'S':
{
HANDLE fh;
WIN32_FIND_DATAW w32_fd;
GetSystemDirectoryW (wbuf, MAX_PATH);
/* The path returned by GetSystemDirectoryW is not case preserving.
The below code is a trick to get the correct case of the system
directory from Windows. */
if ((fh = FindFirstFileW (wbuf, &w32_fd)) != INVALID_HANDLE_VALUE)
{
FindClose (fh);
wcscpy (wcsrchr (wbuf, L'\\') + 1, w32_fd.cFileName);
}
}
break;
-
2.4.0:
case 'S':
{
GetSystemDirectoryW (wbuf, MAX_PATH);
...
if (iswalpha (wbuf[0]) && wbuf[1] == L':' && wbuf[2] == L'\\')
{
OBJECT_ATTRIBUTES attr;
NTSTATUS status;
HANDLE h;
IO_STATUS_BLOCK io;
UNICODE_STRING upath;
const ULONG size = sizeof (FILE_NAME_INFORMATION)
+ PATH_MAX * sizeof (WCHAR);
PFILE_NAME_INFORMATION pfni = (PFILE_NAME_INFORMATION) alloca (size);
/* Avoid another buffer, reuse pfni. */
wcpcpy (wcpcpy (pfni->FileName, L"\\??\\"), wbuf);
wprintf (L" 1: pfni->FileName: %S\n", pfni->FileName); // still correct
RtlInitUnicodeString (&upath, pfni->FileName);
wprintf (L" 2: pfni->FileName: %S\n", pfni->FileName); // still correct
InitializeObjectAttributes (&attr, &upath, OBJ_CASE_INSENSITIVE,
NULL, NULL);
status = NtOpenFile (&h, READ_CONTROL, &attr, &io,
FILE_SHARE_VALID_FLAGS, FILE_OPEN_REPARSE_POINT);
if (NT_SUCCESS (status))
{
status = NtQueryInformationFile (h, &io, pfni, size,
FileNameInformation); // returns
the wrong path
wprintf (L" 3: pfni->FileName: %S\n", pfni->FileName); // WRONG
if (NT_SUCCESS (status))
{
pfni->FileName[pfni->FileNameLength / sizeof (WCHAR)] = L'\0';
wprintf (L" 4: pfni->FileName: %S\n", pfni->FileName);
wcscpy (wbuf + 2, pfni->FileName);
wprintf (L"wcscpy(): %S\n", wbuf);
}
NtClose (h);
}
}
=
--
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
Re: cygpath 2.4.0 (32-bits) in error?
On Jan 21 19:34, Houder wrote: > On 2016-01-21 16:42, Corinna Vinschen wrote: > >On Jan 21 15:11, Achim Gratz wrote: > >>Houder xs4all.nl> writes: > >>> %% uname -a > >>> CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin > >>> > >>> %% /usr/bin/cygpath -S -u > >>> /drv/c/Windows/SysWOW64 < Nice, the truth is out! ... but do we want > >>> it here? > >>> %% /usr/bin/cygpath -S -w > >>> C:\Windows\system32 > >>> %% > >>> %% /usr/bin/cygpath -S -U > >>> /proc/cygdrive/c/Windows/SysWOW64 < ditto > >> > >>Well > >> > >>/usr/bin/cygpath -u $( /usr/bin/cygpath -Sw ) > >> > >>delivers the right result. I guess an option to chose which result to > >>get > >>might be nice, but I can cope either way. > > > >I hate this path redirection stuff. Patches welcome. Maybe we should > >simply replace SysWOW64 with System32, a simple string operation. > > Hi Corinna, > > Did not mean to get you angry ... It's not you getting me angry here ;) > do_sysfolders() in cygpath.cc has changed between 2.3.1 and 2.4.0 where > it attempts to ascertain the 'system directory'. > > The postprocessing after GetSystemDirectoryW() is different ... Yes, that was necessary to return case-correct paths. I commited a patch and hour and a half ago and uploaded a new snapshot to https://cygwin.com/snapshots/ Please give it a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
RE: Performance of "ls -F"
Hi Achim, I'm also having this issue but my investigation has found it to be a behavior specific to C-DOT. This doesn't happen with 7mode. I currently have a support case open with NetApp to get to the bottom of this behavior. It could be a Cygwin bug. > -Original Message- > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On > Behalf Of Achim Gratz > Sent: Thursday, January 21, 2016 10:45 AM > To: cygwin@cygwin.com > Subject: Performance of "ls -F" > > I am finding a large performance gap between plain "ls" and "ls -F" in a > directory with many files on a network share (NetApp disguised as NTFS if > that matters). This has been there for quite a while, I've just now realized > what the reason was (I have "ls -F" as an alias for "ls" in my interactive > shells). > In a directory with 1300 files, a plain "ls" completes in 0.3s, while "ls -F" > requires about 95s. Determining the file class seems to require around > 70...90ms per file, which I can confirm also for directories with a lot less > files. > What's involved in that determination that takes such a long time? > > Regards, > Achim. > > > -- > 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 -- 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
Re: cygpath 2.4.0 (32-bits) in error?
On 2016-01-21 20:09, Corinna Vinschen wrote: Hi Corinna, Did not mean to get you angry ... It's not you getting me angry here ;) It is not? :-))) do_sysfolders() in cygpath.cc has changed between 2.3.1 and 2.4.0 where it attempts to ascertain the 'system directory'. The postprocessing after GetSystemDirectoryW() is different ... Yes, that was necessary to return case-correct paths. I commited a patch and hour and a half ago and uploaded a new snapshot to https://cygwin.com/snapshots/ Please give it a try. - %% uname -a CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin %% cygpath -S /drv/c/Windows/SysWOW64 %% %% ./cygpath-2.4.0-snapshot -S /drv/c/Windows/System32 < ok %% ./cygpath-2.4.0-snapshot -S -U /proc/cygdrive/c/Windows/System32 < ok - 64-%% uname -a CYGWIN_NT-6.1 Seven 2.4.0(0.293/5/3) 2016-01-15 16:16 x86_64 Cygwin 64-%% cygpath -S /drv/c/Windows/System32 64-%% 64-%% ./cygpath-64-2.4.0-snapshot -S /drv/c/Windows/System32 64-%% ./cygpath-64-2.4.0-snapshot -S -U /proc/cygdrive/c/Windows/System32 Btw, files in both cygwin-inst-20160121.tar.xz appear to be "included" multiple times (3 or more) -- just saying. Regards, Henri -- 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
RE: Performance of "ls -F"
In my particular case, we're seeing this behavior: 7-mode: (//devnas04/largedisk/bsmith/netapp) :$ //devnas04/largedisk/bsmith/netapp>time ls -ld struct5* -rw-r--r-- 1 bsmith Domain Users 0 Nov 5 10:25 struct51.log [snipped] -rw-r--r-- 1 bsmith Domain Users 0 Nov 5 10:26 struct5z.prf real0m1.308s user0m0.031s sys 0m0.125s cdot-mode: (//rdlserv/testdata/rdl117_nt/test) :$ //rdlserv/testdata/rdl117_nt/test>time ls -ld struct5* -rwxrwx---+ 1 Unknown+User Unknown+Group 23047 Nov 4 21:47 struct51.log [snipped] -rwxr-x---+ 1 Unknown+User Unknown+Group 595 Oct 31 23:53 struct5z.prf real1m7.698s user0m0.249s sys 0m11.484s The difference is 1.3 seconds versus 1 minute 7 seconds. The directory is identical on the two NetApps and they both contain ~29K files. C-dot (Cluster Data On Tap) is the newest operating system for the NetApp. It also supports the newer SMB protocols. I also tried the experiment with MKS Toolkit 8.6 and in both cases, it takes around .1 seconds. > -Original Message- > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On > Behalf Of William M. (Mike) Miller > Sent: Thursday, January 21, 2016 10:53 AM > To: cygwin@cygwin.com > Subject: Re: Performance of "ls -F" > > On Thu, Jan 21, 2016 at 10:44 AM, Achim Gratz > wrote: > > I am finding a large performance gap between plain "ls" and "ls -F" in > > a directory with many files on a network share (NetApp disguised as > > NTFS if that matters). This has been there for quite a while, I've > > just now realized what the reason was (I have "ls -F" as an alias for > > "ls" in my interactive shells). In a directory with 1300 files, a > > plain "ls" completes in 0.3s, while "ls -F" requires about 95s. > > Determining the file class seems to require around 70...90ms per file, > > which I can confirm also for directories with a lot less files. > > What's involved in that determination that takes such a long time? > > The overhead appears to be in checking for executable files; using --file-type > instead of -F, which just omits the '*' category, reduces the time for ls in > one > of my (local) large directories from over one second to 0.04 seconds. > > -- > William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com > > -- > 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
Re: Base-files-mketc.sh error for non-existing C:\Windows\SysWOW64\drivers\etc
Henri writes: > Yes, your proposal will work ... BECAUSE in that specific case, redirection > will be switched OFF (hey, study the URL that I posted). Yes, I've read that. What goes still unanswered is if that's the only place Windows ever looks for those files. I guess yes, but I can't find no positive confirmation. > Btw, Microsoft thinks the "SysNative nonsense" a necessity; it even patched > XP in order to introduce that nonsense ... I'm sure they think that and there's probably a PowerPoint with lots of bullet points that says so. But I've yet to meet anyone who thinks it was a bright idea after running into it unexpectedly. If anything, MS themselves couldn't make it work without those exceptions whose documentation is not easy to find. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
Re: cygpath 2.4.0 (32-bits) in error?
Corinna Vinschen writes: > Yes, that was necessary to return case-correct paths. I commited a > patch and hour and a half ago and uploaded a new snapshot to > https://cygwin.com/snapshots/ Please give it a try. For base-files I still plan to do cygpath -U $( cygpath -Sw ) dance so it will work with older Cygwin releases unless you think it's a bad idea. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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
Re: New cygwin install hanging on postinstall
On 1/21/2016 3:02 AM, Achim Gratz wrote: Ken Brown cornell.edu> writes: Check setup.log.full. If that doesn't help, try running the script manually to see what happens (most likely a fork failure requiring a full rebase). Well, if it's really a fresh install, the full rebase just has happened His followup message shows that it wasn't a fresh install and that a full rebase didn't happen. Ken -- 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
Re: New cygwin install hanging on postinstall
On 1/21/2016 12:40 PM, KARR, DAVID wrote: -Original Message- On 20 January 2016 at 17:06, KARR, DAVID wrote: I was installing cygwin for the first time on a Win7-32bit box. It is hanging in postinstall, with "0/Perpetual" and "/etc/postinstall/0p_texlive_prep.dash. I've tried this twice now, and it hangs effectively forever on this step (waited 15-20 minutes each time). What other information could I provide? I looked at the end of the setup.log file, but that just indicates that installation was complete. While it's sitting here, I dumped out "/var/log/setup.log.full". Here is the end of the file: The following DLLs couldn't be rebased because they were in use: /usr/bin/cygssp-0.dll /usr/bin/cygperl5_22.dll /usr/bin/cyggcc_s-1.dll /usr/bin/cygcrypt-0.dll /usr/lib/perl5/vendor_perl/5.22/i686-cygwin-threads-64int/auto/List/Util/Util. dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/IO/IO.dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/File/Glob/Glob.dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Fcntl/Fcntl.dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Encode/Encode.dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Digest/MD5/MD5.dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Cwd/Cwd.dll There's your problem. There were Cygwin processes running when you did the most recent install, so the _autorebase script couldn't do its job. You need to do a full rebase before trying again. See the instructions in https://www.cygwin.com/ml/cygwin/2016-01/msg00216.html Ken -- 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
Re: Performance of "ls -F"
Bill Smith writes: > Hi Achim, > I'm also having this issue but my investigation has found it to be a > behavior specific to C-DOT. This doesn't happen with 7mode. I > currently have a support case open with NetApp to get to the bottom of > this behavior. It could be a Cygwin bug. Hmm. I have no idea what C-DOT and 7mode are or how to check for that. But since you are able to open support cases with NetApp, any chance you can ask them for a fix of those unstable inode numbers? :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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
Re: New cygwin install hanging on postinstall
KARR, DAVID writes: > While it's sitting here, I dumped out "/var/log/setup.log.full". Here is the > end of the file: > > The following DLLs couldn't be rebased because they were in use: > /usr/bin/cygssp-0.dll > /usr/bin/cygperl5_22.dll > /usr/bin/cyggcc_s-1.dll > /usr/bin/cygcrypt-0.dll > > /usr/lib/perl5/vendor_perl/5.22/i686-cygwin-threads-64int/auto/List/Util/Util. > dll > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/IO/IO.dll > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/File/Glob/Glob.dll > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Fcntl/Fcntl.dll > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Encode/Encode.dll > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Digest/MD5/MD5.dll > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Cwd/Cwd.dll > 2016/01/21 09:15:40 running: C:\cygwin\bin\dash.exe > "/etc/postinstall/0p_texlive > _prep.dash" > 2016/01/21 09:19:20 note: Nothing needed to be installed > 2016/01/21 09:19:20 Ending cygwin install > --- So this isn't a fresh install and in fact there is not only some Cygwin process running but a full blown Perl that has loaded a number of modules. How'd you manage to do that before Cygwin was ready installing? Are you perhaps reporting from a follow-on invocation of setup.exe after the first install already failed? For your current case, you need to get rid of _all_ running Cygwin processes. Best idea is to open a shell and issue /usr/bin/rebase-trigger fullrebase /usr/bin/pkill . (you need to have procps installed for this command to be available). Then run setup again to have it re-do the rebase and run all postinstall scripts that failed before. But I'm still interested how that initial failure could have occured, so if you could maybe look in /var/log/setup.log if something indicates what happened there that would be good. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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
RE: New cygwin install hanging on postinstall
> -Original Message- > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On > Behalf Of Achim Gratz > Sent: Thursday, January 21, 2016 12:10 PM > To: cygwin@cygwin.com > Subject: Re: New cygwin install hanging on postinstall > > KARR, DAVID writes: > > While it's sitting here, I dumped out "/var/log/setup.log.full". > Here is the end of the file: > > > > The following DLLs couldn't be rebased because they were in use: > > /usr/bin/cygssp-0.dll > > /usr/bin/cygperl5_22.dll > > /usr/bin/cyggcc_s-1.dll > > /usr/bin/cygcrypt-0.dll > > /usr/lib/perl5/vendor_perl/5.22/i686-cygwin-threads- > 64int/auto/List/Util/Util. > > dll > > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/IO/IO.dll > > /usr/lib/perl5/5.22/i686-cygwin-threads- > 64int/auto/File/Glob/Glob.dll > > /usr/lib/perl5/5.22/i686-cygwin-threads- > 64int/auto/Fcntl/Fcntl.dll > > /usr/lib/perl5/5.22/i686-cygwin-threads- > 64int/auto/Encode/Encode.dll > > /usr/lib/perl5/5.22/i686-cygwin-threads- > 64int/auto/Digest/MD5/MD5.dll > > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Cwd/Cwd.dll > > 2016/01/21 09:15:40 running: C:\cygwin\bin\dash.exe > "/etc/postinstall/0p_texlive > > _prep.dash" > > 2016/01/21 09:19:20 note: Nothing needed to be installed > > 2016/01/21 09:19:20 Ending cygwin install > > --- > > So this isn't a fresh install and in fact there is not only some > Cygwin > process running but a full blown Perl that has loaded a number of > modules. How'd you manage to do that before Cygwin was ready > installing? Are you perhaps reporting from a follow-on invocation > of > setup.exe after the first install already failed? Beats the heck out of me. I didn't have Cygwin installed. I ran the installer. It hung at this point. I eventually cancelled it, because it obviously wasn't going to complete. This output is from one of the later retries. I never attempted to run anything installed in cygwin, I'm just trying to complete the installation. > For your current case, you need to get rid of _all_ running Cygwin > processes. Best idea is to open a shell and issue > > /usr/bin/rebase-trigger fullrebase > /usr/bin/pkill . > > (you need to have procps installed for this command to be > available). > Then run setup again to have it re-do the rebase and run all > postinstall > scripts that failed before. But I'm still interested how that > initial > failure could have occured, so if you could maybe look in > /var/log/setup.log if something indicates what happened there that > would > be good. More weirdness. I ran a mintty window, and I ran those command lines, but it gives me lots of lines like this: - 2 [main] bash 28452 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0x4D) != child(0x2E) bash: fork: retry: No child processes - I don't believe either of these command lines did anything, but just to be sure, after I ran them I killed the window an reran setup, and got the same symptoms. -- 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
Re: cygpath 2.4.0 (32-bits) in error?
On 2016-01-21 20:44, Houder wrote: Btw, files in both cygwin-inst-20160121.tar.xz appear to be "included" multiple times (3 or more) -- just saying. Please, ignore the above (my 7-zip exe must be in error). Regards, Henri -- 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
umask not honored?
Created a new directory in my home directory with the following: mkdir test created an empty file in this directory with: touch test/empty When I list the contents of this path I get the following: $ ls -Al test total 0 --w-rw+ 1 kdstah GROUP_CHANGED 0 Jan 21 16:35 empty My umask is set to 0022 My home directory has the following permissions: 750 (use ssh) /etc/fstab is configured with: none /cygdrive cygdrive binary,posix=0,user 0 0 If I create the same file within any existing directory, the umask is honored. Any thoughts? -- 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
Re: New cygwin install hanging on postinstall
On 21/01/16 21:17, KARR, DAVID wrote: -Original Message- From: cygwin-owner cygwin.com [mailto:cygwin-owner cygwin.com] On Behalf Of Achim Gratz Sent: Thursday, January 21, 2016 12:10 PM To: cygwin cygwin.com Subject: Re: New cygwin install hanging on postinstall KARR, DAVID writes: While it's sitting here, I dumped out "/var/log/setup.log.full". Here is the end of the file: The following DLLs couldn't be rebased because they were in use: /usr/bin/cygssp-0.dll /usr/bin/cygperl5_22.dll /usr/bin/cyggcc_s-1.dll /usr/bin/cygcrypt-0.dll /usr/lib/perl5/vendor_perl/5.22/i686-cygwin-threads- 64int/auto/List/Util/Util. dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/IO/IO.dll /usr/lib/perl5/5.22/i686-cygwin-threads- 64int/auto/File/Glob/Glob.dll /usr/lib/perl5/5.22/i686-cygwin-threads- 64int/auto/Fcntl/Fcntl.dll /usr/lib/perl5/5.22/i686-cygwin-threads- 64int/auto/Encode/Encode.dll /usr/lib/perl5/5.22/i686-cygwin-threads- 64int/auto/Digest/MD5/MD5.dll /usr/lib/perl5/5.22/i686-cygwin-threads-64int/auto/Cwd/Cwd.dll 2016/01/21 09:15:40 running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_texlive _prep.dash" 2016/01/21 09:19:20 note: Nothing needed to be installed 2016/01/21 09:19:20 Ending cygwin install --- So this isn't a fresh install and in fact there is not only some Cygwin process running but a full blown Perl that has loaded a number of modules. How'd you manage to do that before Cygwin was ready installing? Are you perhaps reporting from a follow-on invocation of setup.exe after the first install already failed? Beats the heck out of me. I didn't have Cygwin installed. I ran the installer. It hung at this point. I eventually cancelled it, because it obviously wasn't going to complete. This output is from one of the later retries. I never attempted to run anything installed in cygwin, I'm just trying to complete the installation. If setup has been killed and attempted a second time, it could be that one of the post-install scripts was left running. For your current case, you need to get rid of _all_ running Cygwin processes. Best idea is to open a shell and issue /usr/bin/rebase-trigger fullrebase /usr/bin/pkill . (you need to have procps installed for this command to be available). Then run setup again to have it re-do the rebase and run all postinstall scripts that failed before. But I'm still interested how that initial failure could have occured, so if you could maybe look in /var/log/setup.log if something indicates what happened there that would be good. More weirdness. I ran a mintty window, and I ran those command lines, but it gives me lots of lines like this: - 2 [main] bash 28452 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0x4D) != child(0x2E) bash: fork: retry: No child processes - I don't believe either of these command lines did anything, but just to be sure, after I ran them I killed the window an reran setup, and got the same symptoms. How many Cygwin packages are you attempting to install? You mentioned that you were installing on 32-bit Win 7, so you must be installing 32-bit Cygwin. The amount of address space is rather limited on 32-bit, so installing a very large number of packages could give the symptoms you're seeing. Dave. -- 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
Re: Base-files-mketc.sh error for non-existing C:\Windows\SysWOW64\drivers\etc
Thanks you all for the replies. Achim writes: > What goes still unanswered is if that's the only > place Windows ever looks for those files. I guess yes, but I can't find > no positive confirmation. Sorry not sure what you mean. Henri's link shows file system redirection does not apply to %windir%\system32\drivers\etc, therefore there are no other places to 'look for those files' - if 'other places' is meant to be places caused by file system redirection. Henri's link: https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx Thanks. David. On 22 January 2016 at 03:53, Achim Gratz wrote: > Henri writes: >> Yes, your proposal will work ... BECAUSE in that specific case, redirection >> will be switched OFF (hey, study the URL that I posted). > > Yes, I've read that. What goes still unanswered is if that's the only > place Windows ever looks for those files. I guess yes, but I can't find > no positive confirmation. > >> Btw, Microsoft thinks the "SysNative nonsense" a necessity; it even patched >> XP in order to introduce that nonsense ... > > I'm sure they think that and there's probably a PowerPoint with lots of > bullet points that says so. But I've yet to meet anyone who thinks it > was a bright idea after running into it unexpectedly. If anything, MS > themselves couldn't make it work without those exceptions whose > documentation is not easy to find. > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > Factory and User Sound Singles for Waldorf Blofeld: > http://Synth.Stromeko.net/Downloads.html#WaldorfSounds > > -- > 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 > -- 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
Compiling gcc trunk under cygwin
Until recently, I've been able to build gcc under cygwin just fine. But (relatively) recent checkins (232454 & 232071) are causing problems. I've been trying to track down what to do about them, but crawling thru the depths of makefiles, sed scripts, etc is proving difficult for this long-time Windows programmer. But I do have some clues. The problems all seem to revolve around __GXX_WEAK__. I notice that cygwin's current (and experimental 5.2.0) builds of gcc don't define __GXX_WEAK__. After reading this (https://cygwin.com/ml/cygwin/2010-04/msg00281.html), that makes sense. And that's fine by me, I don't need it anyway. But during the building of gcc, the xgcc that gets built *does* define it. And with these new changes, that leads to errors like this: ../src/c++11/.libs/libc++11convenience.a(cow-stdexcept.o): In function `_txnal_cow_string_C1_for_exceptions(void*, char const*, void*)': /cygdrive/c/cygwin64/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:236:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x2c): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU1' /cygdrive/c/cygwin64/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:248:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x39): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `transaction clone for operator new[](unsigned long)' /cygdrive/c/cygwin64/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:267:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x5d): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_memcpyRtWn' ../src/c++11/.libs/libc++11convenience.a(cow-stdexcept.o): In function `txnal_read_ptr': /cygdrive/c/cygwin64/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:278:(.text$_Z23_txnal_cow_string_c_strPKv+0x1): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8' /cygdrive/c/cygwin64/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:278:(.text$_Z23_txnal_sso_string_c_strPKv+0x1): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8' /cygdrive/c/cygwin64/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:278:(.text$_Z20_txnal_cow_string_D1Pv+0x5): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8' ../src/c++11/.libs/libc++11convenience.a(cow-stdexcept.o): In function `_txnal_cow_string_D1(void*)': /cygdrive/c/cygwin64/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:324:(.text$_Z20_txnal_cow_string_D1Pv+0x1e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_addUserCommitAction' ../src/c++11/.libs/libc++11convenience.a(cow-stdexcept.o): In function `transaction clone for std::logic_error::logic_error(char const*)': /cygdrive/c/cygwin64/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:408:(.text$_ZGTtNSt11logic_errorC1EPKc+0x2e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_memcpyRnWt' ../src/c++11/.libs/libc++11convenience.a(cow-stdexcept.o): In function `transaction clone for std::logic_error::logic_error(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&)': /cygdrive/c/cygwin64/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:408:(.text$_ZGTtNSt11logic_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x2e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_memcpyRnWt' ../src/c++11/.libs/libc++11convenience.a(cow-stdexcept.o): In function `txnal_read_ptr': /cygdrive/c/cygwin64/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:278:(.text$_ZGTtNSt11logic_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x36): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8' ../src/c++11/.libs/libc++11convenience.a(cow-stdexcept.o): In function `transaction clone for std::logic_error::~logic_error()': /cygdrive/c/cygwin64/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:408:(.text$_ZGTtNSt11logic_errorD0Ev+0x1a): additional relocation overflows omitted from the output I can fix the errors and get my build working again by: a) adding "#define __GXX_WEAK__ 0" to the top of cow-stdexcept.cc b) commenting out the undef and define of MAKE_DECL_ONE_ONLY in cygming.h But there's got to be a better way. Is there some configure option I'm supposed to be using when building gcc for cygwin? How else could your 5.2.0 not be defining __GXX_WEAK__? Looking at the configure options in gcc -v isn't showing me anything that looks like a solution. dw -- 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
Re: Base-files-mketc.sh error for non-existing C:\Windows\SysWOW64\drivers\etc
David Lee gmail.com> writes: > Sorry not sure what you mean. What I mean is this: are all the Windows versions that Cygwin supports looking for the hosts and other files in %windir%\system32\drivers\etc or are there some versions, situations or configurations where it looks for those files in a different place? That the postinstall for base-files has worked until 2.4.0 seems to indicate that the place is always the same, but the absence of a bug report is not the same as positive confirmation. Regards, Achim. -- 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
Re: Performance of "ls -F"
Bill Smith progress.com> writes: > The difference is 1.3 seconds versus 1 minute 7 seconds. The directory is identical on the two NetApps and > they both contain ~29K files. C-dot (Cluster Data On Tap) is the newest operating system for the NetApp. It > also supports the newer SMB protocols. > > I also tried the experiment with MKS Toolkit 8.6 and in both cases, it takes around .1 seconds. Could you please show the result for running /usr/lib/csih/getVolInfo on the two directories? Regards, Achim. -- 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
Re: New cygwin install hanging on postinstall
Greetings, KARR, DAVID! >> > I was installing cygwin for the first time on a Win7-32bit box. > It has 4g RAM. Checking "Resource Monitor" while the install is running, > there is 750MB "available". How much memory is "available" is not an indication for a 32-bit OS. You simply can not allocate more than 2GB of RAM to a single process without much hackery. Which means, certain applications could hit a roadblock just because of that. Same applies to your 4GB statement: You just can not use it all with 32-bit OS without much hackery on OS level, and that means slowing down entire system. You are really, really want 64-bit OS with more than 2GB RAM to see any light at the end of the tunnel. On top of that, if you are still struggling with installation, and hints offered in other messages did not helped to date, the most simple way would be to eliminate the failed Cygwin install and start anew, this time only install a base (setup default) set of tools first time, may be accompanying them by choice things of convenience, like wget and/or procps. But nothing overgrown like TexLive. -- With best regards, Andrey Repin Friday, January 22, 2016 10:27:27 Sorry for my terrible english... -- 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
Re: Base-files-mketc.sh error for non-existing C:\Windows\SysWOW64\drivers\etc
Greetings, Achim Gratz! >> Sorry not sure what you mean. > What I mean is this: are all the Windows versions that Cygwin supports > looking for the hosts and other files in > %windir%\system32\drivers\etc > or are there some versions, situations or configurations where it looks for > those files in a different place? Been that same place since NT4 at least, for all that I recall. Not the same for '9x family, but we're long past that point, I hope. > That the postinstall for base-files has worked until 2.4.0 seems to indicate > that the place is always the same, but the absence of a bug report is not > the same as positive confirmation. Indeed. -- With best regards, Andrey Repin Friday, January 22, 2016 10:22:02 Sorry for my terrible english... -- 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
