Re: [ITP] mingw-w64 Second try
On 9/10/2010 08:51, JonY wrote: On 9/10/2010 07:09, Charles Wilson wrote: On 9/9/2010 6:10 AM, JonY wrote: OK, we're amost there. binutils and runtime are GTG. gcc, headers, and pthreads are really close. Everything rebuilds from source fine, and the uploaded packages actually match the rebuilt versions (or vice versa). So that's all good. Plus, I was able to build a sample project using these tools (mingw64-x86_86-xz-4.999.9beta-1) with no problems. However, when I tried to install these packages via setup.exe, I ran into problems with the setup.hints. In the first case, genini (*) did not like some of them -- complained about missing fields -- AND, genini couldn't actually parse the package name of mingw64-x86_64-headers. (*) genini is a user script that can be used to generate a setup.ini for a cygwin package repository. On the sourceware server, a different tool -- upset -- is used. Now, maybe -- MAYBE -- upset is smarter than genini, and won't complain. However, it's usually better to make sure that genini is happy; then you are much more likely to NOT cause the upset script on sourceware to send cgf a bunch of nasty warnings via email. That makes cgf angry. You wouldn't like cgf when he's angry. Here are the bad setup.hints: mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-gcc/setup.hint mingw64-x86_64-pthreads/setup.hint Plus there are bigger changes required to the -headers package. We'll talk about that last. In each of the following cases, the setup.hint was missing an ldesc: field. This annoys genini, but upset might be ok with it. mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-pthreads/setup.hint The top gcc setup.hint was missing both an ldesc: and a requires: field (requires was empty, of course). mingw64-x86_64-gcc/setup.hint I've attached the updated setup.hints. Here's what I would suggest we do, for gcc: DON'T bother to rebuild it. Just save these setup.hints, and make sure to fold them in to your NEXT official release's CYGWIN-PATCHES/ directory. When I upload this first version of mingw64-gcc, I'll be sure to use these new hints instead of the ones you pasted inline. Let's call gcc GTG with alternate hint files. For pthreads, I'd suggest you actually rebuild and re-upload it with the attached hint (it doesn't take nearly as long...) but if you want to treat it just like gcc, above, that's fine. Let me know -- we'll call pthreads GTG with alternate hint files, or as rebuilt. Now...headers. Here's the problem: genini requires that the version part of the package name begin with a numeral. I think this is true of upset as well, but I'm not sure (but again, better safe than sorry. You wouldn't like cgf when he's angry). Also, genini and cygport do NOT like having a hyphen in the version number (but upset is ok with it). So, just liike your earlier gendef and libmangle packages -- where we discovered that they had to be named, e.g. gendef-1.0-svn2931-1.tar.bz2 gendef-1.0-svn2931-1-src.tar.bz2 libmangle-1.0-svn2930-1.tar.bz2 libmangle-1.0-svn2930-1-src.tar.bz2 ...the current name of the headers package is no good: mingw64-x86_64-headers-svn3433-1.tar.bz2 mingw64-x86_64-headers-svn3433-1-src.tar.bz2 ^^^ must start with numeral Now, following the gendef/libmangle pattern, I tried mingw64-x86_64-headers-1.0b-svn3433-1.tar.bz2 where 1.0b came from the configure.ac file, but I discovered that genini doesn't like the hyphen between 1.0b and svn3433 -- when you do that, genini (and cygport-0.10.0, for that matter) thinks the package name is mingw64-x86_64-headers-1.0b, and the version is svn3433, and we're right back where we started! Now, upset doesn't care about this -- obviously -- since gendef and libmangle, which use '-' between 1.0 and svn -- have not yet caused cgf to become angry. But...let's also try to keep genini happy. And, it may be a regression in cygport -- I'm not sure (obv. you were able to build gendef and libmangle with an older version of cygport, even with a hyphen in the middle of the version string), but we have to keep cygport happy, too. So, I rebuilt as: mingw64-x86_64-headers-1.0b_svn3433-1.tar.bz2 mingw64-x86_64-headers-1.0b_svn3433-1-src.tar.bz2 OK, this is fine. And that worked fine (genini was happy, cygport was happy, setup.exe was happy -- and presumably upset will be happy == no angry cgf). I've uploaded the modified version here: http://cygwin.cwilson.fastmail.fm/mingw64-x86_64-headers-1.0b_svn3433-1-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/mingw64-x86_64-headers-1.0b_svn3433-1.tar.bz2 so you can download it and pick it apart. The only thing that's different is (a) the package name, (b) the name of the
Re: setup, upx, and TLS
[previous message was sent to the wrong mailing list; a nice reminder not to write emails at 5:27 in the night...] Yaakov (Cygwin/X) wrote: On Sun, 2010-09-05 at 15:27 -0400, Charles Wilson wrote: Lapo, are you still here? Could we get an updated upx package, please? I'm not so sure that he is still here. Sorry guys, a long strike of too many things to do at the same time had me going a bit in rounds. I've packaged upx (I hope not to have forgot anything of the process ;)), but I fear I'll have the next decently sized time-slot on monday (uh, that'll be a problem to send the announce mesage earlier too). Oh, and I had ready-to-release packages of monotone and tidy, though the first I'm fairly sure it's good, while the latter was copied directly from CygPorts but I didn't really have time to look into the way the package is divided in three and I'd prefer uploading it in a few days (same goes for other packages). http://lapo.it/cygwin/upx/setup.hint http://lapo.it/cygwin/upx/upx-3.07-1-src.tar.bz2 http://lapo.it/cygwin/upx/upx-3.07-1.tar.bz2 http://lapo.it/cygwin/monotone/monotone-0.48-1-src.tar.bz2 http://lapo.it/cygwin/monotone/monotone-0.48-1.tar.bz2 http://lapo.it/cygwin/monotone/setup.hint -- Lapo Luchini - http://lapo.it/ “C is quirky, flawed, and an enormous success.” (Dennis M. Ritchie) “The Magic Words are Squeamish Ossifrage” (Ron Rivest, RSA-129 challenge, 1977)
Re: setup, upx, and TLS
On Sep 11 10:23, Lapo Luchini wrote: http://lapo.it/cygwin/upx/setup.hint http://lapo.it/cygwin/upx/upx-3.07-1-src.tar.bz2 http://lapo.it/cygwin/upx/upx-3.07-1.tar.bz2 http://lapo.it/cygwin/monotone/monotone-0.48-1-src.tar.bz2 http://lapo.it/cygwin/monotone/monotone-0.48-1.tar.bz2 http://lapo.it/cygwin/monotone/setup.hint Both packages uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
setup.exe compilation fix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi.
I just tried to compile setup.exe from source and run into a problem in
propsheet.cc. The names like PropSheet_SetCurSel() are macros and already
contain the `::' resulting into `' and compile error. The attached patch
fixes it for me. Changelog below.
- --
VH
2010-09-10 Václav Haisman v.hais...@sh.cvut.cz
* propsheet.cc (PropSheet::SetActivePage): Remove :: before
PropSheet_SetCurSel.
(PropSheet::SetActivePageByID): Remove :: before
PropSheet_SetCurSelByID.
(PropSheet::SetButtons): Remove :: before PropSheet_SetWizButtons.
(PropSheet::PressButton): Remove :: before PropSheet_PressButton.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iF4EAREIAAYFAkyLkMcACgkQeqrf2dJjGj41mQD8C6nc9hM8rBY9fdsvI6bV0OLb
aCliFrdPSSLJ66gIWUMA/0m4Fh3yUglWAv6vxmDwrHo28FWn+A7wbiLgzTOUm6yQ
=/PMJ
-END PGP SIGNATURE-
Index: propsheet.cc
===
RCS file: /cvs/cygwin-apps/setup/propsheet.cc,v
retrieving revision 2.15
diff -u -p -r2.15 propsheet.cc
--- propsheet.cc30 Jun 2009 04:14:29 - 2.15
+++ propsheet.cc11 Sep 2010 14:14:33 -
@@ -441,7 +441,7 @@ bool
PropSheet::SetActivePage (int i)
{
// Posts a message to the message queue, so this won't block
- return static_cast bool (::PropSheet_SetCurSel (GetHWND (), NULL, i));
+ return static_cast bool (PropSheet_SetCurSel (GetHWND (), NULL, i));
}
bool
@@ -449,18 +449,18 @@ PropSheet::SetActivePageByID (int resour
{
// Posts a message to the message queue, so this won't block
return static_cast bool
-(::PropSheet_SetCurSelByID (GetHWND (), resource_id));
+(PropSheet_SetCurSelByID (GetHWND (), resource_id));
}
void
PropSheet::SetButtons (DWORD flags)
{
// Posts a message to the message queue, so this won't block
- ::PropSheet_SetWizButtons (GetHWND (), flags);
+ PropSheet_SetWizButtons (GetHWND (), flags);
}
void
PropSheet::PressButton (int button)
{
- ::PropSheet_PressButton (GetHWND (), button);
+ PropSheet_PressButton (GetHWND (), button);
}
propsheet.cc.diff.sig
Description: Binary data
src/winsup/cygwin Makefile.in autoload.cc crt0 ...
CVSROOT:/cvs/src Module name:src Changes by: da...@sourceware.org2010-09-11 06:53:28 Modified files: winsup/cygwin : Makefile.in autoload.cc crt0.c cygwin.din posix.sgml ChangeLog winsup/cygwin/include/cygwin: version.h Added files: winsup/cygwin : fenv.cc winsup/cygwin/include: fenv.h Log message: winsup/cygwin/ChangeLog: * Makefile.in (DLL_OFILES): Add new fenv.o module. (fenv_CFLAGS): New flags definition for fenv.o compile. * autoload.cc (std_dll_init): Use fenv.h functions instead of direct manipulation of x87 FPU registers. * crt0.c (mainCRTStartup): Likewise. * cygwin.din (feclearexcept, fegetexceptflag, feraiseexcept, fesetexceptflag, fetestexcept, fegetround, fesetround, fegetenv, feholdexcept, fesetenv, feupdateenv, fegetprec, fesetprec, feenableexcept, fedisableexcept, fegetexcept, _feinitialise, _fe_dfl_env, _fe_nomask_env): Export new functions and data items. * fenv.cc: New file. * posix.sgml: Update status of newly-implemented APIs. * include/fenv.h: Likewise related header. * include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fenv.cc.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/Makefile.in.diff?cvsroot=srcr1=1.238r2=1.239 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/autoload.cc.diff?cvsroot=srcr1=1.172r2=1.173 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/crt0.c.diff?cvsroot=srcr1=1.5r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwin.din.diff?cvsroot=srcr1=1.224r2=1.225 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/posix.sgml.diff?cvsroot=srcr1=1.48r2=1.49 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5034r2=1.5035 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/fenv.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/version.h.diff?cvsroot=srcr1=1.326r2=1.327
src/winsup/cygwin ChangeLog fhandler_disk_file.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-11 10:58:42 Modified files: winsup/cygwin : ChangeLog fhandler_disk_file.cc Log message: * fhandler_disk_file.cc (fhandler_disk_file::rmdir): More thoroughly check the existence condition on remote drives. Enhance comment. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5035r2=1.5036 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.335r2=1.336
src/winsup/doc new-features.sgml ChangeLog
CVSROOT:/cvs/src Module name:src Changes by: da...@sourceware.org2010-09-11 11:42:16 Modified files: winsup/doc : new-features.sgml ChangeLog Log message: * new-features.sgml: Mention fenv support. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/new-features.sgml.diff?cvsroot=srcr1=1.56r2=1.57 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.316r2=1.317
Re: [PATCH] Add fenv.h and support.
Hi Dave, On Sep 11 08:11, Dave Korn wrote: On 11/09/2010 06:10, Christopher Faylor wrote: On Sat, Sep 11, 2010 at 01:42:49AM +0100, Dave Korn wrote: On 10/09/2010 22:43, Christopher Faylor wrote: Looks nice to me with one HUGE caveat: Please maintain the pseudo-sorted order in cygwin.din. Sorry to have to impose this burden on you. No, that's fine; I've never been sure whether we need to care about the ordinal numbers or not in that file. (AFAIK, we don't have any realistic scenarios where anyone would be linking against the Cygwin DLL by ordinal imports, but I hate making assumptions based only on my own limited experience...) It never even occurred to me about ordinal numbers but since I've been reorganizing that file for years I guess it hasn't been a problem. I checked. Something somewhere sorts all the exports it turns out, so they all get ordinals assigned in alphanumeric sort order anyway, regardless of cygwin.din order. So, I ended up committing it like so: Can you please add some words to doc/new-features.sgml? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH] Add fenv.h and support.
On 11/09/2010 09:09, Corinna Vinschen wrote: Hi Dave, Morning! On Sep 11 08:11, Dave Korn wrote: So, I ended up committing it like so: Can you please add some words to doc/new-features.sgml? How's this look? winsup/doc/ChangeLog: * new-features.sgml: Mention fenv support. cheers, DaveK Index: new-features.sgml === RCS file: /cvs/src/src/winsup/doc/new-features.sgml,v retrieving revision 1.56 diff -p -u -r1.56 new-features.sgml --- new-features.sgml 6 Sep 2010 14:42:30 - 1.56 +++ new-features.sgml 11 Sep 2010 10:57:56 - @@ -5,6 +5,19 @@ itemizedlist mark=bullet listitempara +Cygwin now ships the C standard library fenv.h header file, and implements the +related APIs (including GNU/glibc extensions): feclearexcept, fedisableexcept, +feenableexcept, fegetenv, fegetexcept, fegetexceptflag, fegetprec, fegetround, +feholdexcept, feraiseexcept, fesetenv, fesetexceptflag, fesetprec, fesetround, +fetestexcept, feupdateenv, and predefines both default and no-mask FP +environments. See the +ulink url=http://www.opengroup.org/onlinepubs/95399/basedefs/fenv.h.html; +Single Unix Specification/ulink and the +ulink url=http://www.gnu.org/software/libc/manual/html_node/Arithmetic.html; +GNU C Library manual/ulink for full details of this functionality. +/para/listitem + +listitempara /proc/sys allows to access the native NT namespace. /para/listitem
Re: [PATCH] Add fenv.h and support.
On Sep 11 12:22, Dave Korn wrote: On 11/09/2010 09:09, Corinna Vinschen wrote: Hi Dave, Morning! On Sep 11 08:11, Dave Korn wrote: So, I ended up committing it like so: Can you please add some words to doc/new-features.sgml? How's this look? winsup/doc/ChangeLog: * new-features.sgml: Mention fenv support. I would remove the opengroup link and just keep the gnu C lib one, but other than that it looks good. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup, upx, and TLS
Lapo Luchini wrote: I've packaged upx Wrong mailing list, sorry for the noise. -- Lapo Luchini - http://lapo.it/ “It is dangerous to be right when the government is wrong.” (Voltaire) -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 11 00:12, John Carey wrote: On Sep 04 02:26 Corinna Vinschen wrote: The problem only starts with Vista. I have no objections to use undocumented features, if they work. If there's any way to replace the cwd handle with our own *and* keep the Win32 API happy, I'll take it. I think I've found a way to open the directory handle for backup intent on Vista and later versions. Essentially, I emulate the new things that SetCurrentDirectory() is doing, but in order to get the necessary addresses, I have to do some very ugly hacks. The proof-of-concept code follows (and is also attached). It includes an analysis of what is going on--to the extent that I know what is going on, of course. Please let me know what you think. First of all, I'm thoroughly impressed. This looks like a lot of detective work and I'm also impressed by the amount of time you apparently put into this. I'm hopeful we can create something for Cygwin from this. I have just a few discussing points for now. The PEB does NOT seem to point to any VistaCwd instances. Instead, That puzzles me a bit... After creating the new VistaCwd instance; call it newCwd, the SetCurrentDirectory () implementation modifies the PEB and Cwd under a lock on CwdCS, as follows: Params.CurrentDirectoryHandle = newCwd.DirectoryHandle; Params.CurrentDirectoryName.Buffer = newCwd.Path.Buffer; ...because, at this point it *does* point to the newCWD, even if only indirectly. Let's name the VistaCwd structure Cwd points to curCwd for now. Since we have the address of curCwd.Path.Buffer in Params.CurrentDirectoryName.Buffer, we can infer the address of curCwd from here, right? It's start is just a constant offset from the Buffer address. Given that, wouldn't it be potentially possible to override the content of curCwd? The problem is probably (just as in my old Cygwin code up to 1.7.5) to make sure that this is thread safe. Probably we would still need CwdCS. cout showbase hex (size_t)CwdCS == critical section endl; cout showbase hex (size_t)Cwd == Vista++ CWD struct pointer endl; Is there any connection between these two addresses, like, say, they are side by side? Can't we find Cwd by scanning the .data segment of ntdll.h for the address we inferred from the Params.CurrentDirectoryName.Buffer value? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Oddities with file deletion on CIFS drive
On Sep 10 10:48, Quanah Gibson-Mount wrote: --On Friday, September 10, 2010 7:09 PM +0200 Corinna Vinschen wrote: Let me know if there is anything else I can provide. I'm not sure. I don't think so. The problem is that the unlink(2) function in Cygwin does not get any error code from any of the OS functions it calls. So, from the Cygwin POV everything worked fine. How is it supposed to know that anything has gone wrong, if the underlying OS doesn't tell? Heh, magic I guess. If I mount the drive as a CIFS drive from a Linux box, I can delete the files just fine, so for now that gives me a workaround (I'll move my deletion process to a Linux box). This morning I had an idea. While we were looking into the ACL, we neglected the DOS attributes. When you call `attrib' on one of the files for which you didn't call chmod yet, is the R/O attribute set? If so, it *could* explain why Cygwin thought it has successfully deleted the file, but it hasn't. I also might have a workaround for this. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
New issue on x64 Win7 box
Hello, with recent cygwin version (cygwin1.dll 1.7.7 (1007.7.0.0)) I get while building gcc the following error message: /home/ktietz/source/rth/gcc/buildw64/./gcc/as: fork: Resource temporarily unavaiable. This behavior is new as with older version I didn't saw this problem. Is this an already known issue? Regards, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- 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: rm -r removes directory but reports cannot remove 'dir', directory not empty
On Sep 10 23:32, Saurabh T wrote: What is that I: drive? What does `mount' print as filesystem type of /cygdrive/i, and what does `/usr/lib/csih/getVolInfo /cygdrive/i' print(*)? I assume I: is not Samba, right? Corinna mount shows: I: on /cygdrive/i type cifs (binary,posix=0,user,noumount,auto) compared to C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) /usr/lib/csih/getVolInfo /cygdrive/ Device Type: 7 Characteristics: 10 Volume Name: build Serial Number : 110167052 Max Filenamelength : 255 Filesystemname : NTFS Flags : 3 FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE I believe I: is Samba (says so in My Computer). I don't think so. It's not recognized as Samba by Cygwin because the FILE_PERSISTENT_ACLS flag is not set. That should always be set by Samba when faking an NTFS. However, this gives us potentially a lever to workaround your problem. I've checked in a change to rmdir into CVS. Please test your case with the next developer's snapshot from http://cygwin.com/snapshots/ and report back. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
Btw... On Sep 11 00:12, John Carey wrote: // The real SetCurrentDirectory () implementation calls // a non-exported function that appears to expand relative // paths to absolute paths and convert / to \. It might // also do other things. Isn't that just one of RtlDosPathNameToNtPathName_U or RtlDosPathNameToNtPathName_U_WithStatus? Both functions are exported, afaics. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 issue on x64 Win7 box
On 9/11/2010 6:41 AM, Kai Tietz wrote: with recent cygwin version (cygwin1.dll 1.7.7 (1007.7.0.0)) I get while building gcc the following error message: /home/ktietz/source/rth/gcc/buildw64/./gcc/as: fork: Resource temporarily unavaiable. This behavior is new as with older version I didn't saw this problem. Is this an already known issue? It's the old fork can't relocate DLLs to the same location in the child's memory space as they were in the parent's problem. The workaround is to use 'rebaseall'. See /usr/share/doc/Cygwin/rebase-3.0.1.README -- Chuck -- 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: incredibly slow file listing script on windoze 7 pro 4 core 64 bit
On 9/8/10, Eric Blake ebl...@russianhut.comie wrote: On 09/08/2010 09:24 AM, Larry Hall (Cygwin) wrote: To somewhat sooth your curiousity, Windows (or perhaps it's more accurate to say NTFS) ain't great with directories with a large number of files. I expect you would be less than impressed with the performance of of 'dir' in 'cmd.exe' in the same directory. That said, you're asking for allot more work than you may realize when doing the same thing in Cygwin. In order to I don't want to add more clutter with this contrived example but just to make a point, I just got a 500G WD USB disk and sent these things to their final resting place. I had to reformat it is as vfat as that seems to be the only thing that is RW everywhere. I ran the script on this newer debian install with vfat and USB disk and it is faster than 'doze and probably faster than old emachines because I now have 2.8ghz CPU LOL. fill in the information you ask for when you use the '-l' flag for 'ls', Cygwin needs to open and close the files, which takes a good chunk of time en masse. The same does not need to happen in Linux/UNIX-land. Additionally, the stat() interface is puny - it MUST take the time to fill out the complete struct, even if the caller only cares for part of the information. If the Linux kernel ever incorporates the pending xstat() kernel call[1], then cygwin adds support for it, and coreutils is taught to make good use of it, then operations like ls can be sped up by asking for only the portions of the stat data that they plan on actually using, letting cygwin skip the work of obtaining the rest of the stat information just to be thrown away by the caller. [1]version 6 of that kernel patch is still being debated; as recently as http://lkml.indiana.edu/hypermail/linux/kernel/1008.2/00274.html -- 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: How to get a script file to use bash and ssh
PaulHR schrieb am 02.09.2010 um 12:10 (-0700): I want to create script files that are not bound to my user id. I want to create over 20 different scripts files, one for each server I manage. I have uploaded keys to each server. So all I should have to is enter is the ssh command Sounds like you want to explore what options ~/.ssh/config has: Host s22 HostName server-22.bla.rz User superadmin Then type: ssh s22 Same mechanism available for PuTTY. -- Michael Ludwig -- 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: OpenGL linking problems
--- Mer 8/9/10, Jon TURNEY ha scritto: On 08/09/2010 13:53, David Doria wrote: Oh, I guess you have a makefile generated by cmake? In which case you need make VERBOSE=1 to get it to show you what it is doing. Ok, now there is some useful output. I see an -lGL, what else should I be looking for? /usr/bin/c++.exe -Wno-deprecated -mwin32 [list of .o files snipped] CMakeFiles/GraphicsCxxTests.dir/TestDecimatePolylineFilter.cxx.o -o ../../../bin/GraphicsCxxTests.exe -Wl,--out-implib,../../../bin/libGraphicsCxxTests.dll.a -Wl,--major-image-version,0,--minor-image-version,0 ../../../bin/libvtkRendering.a ../../../bin/libvtkIO.a -lGL -lGLU ../../../bin/libvtkDICOMParser.a ../../../bin/libvtkNetCDF_cxx.a ../../../bin/libvtkNetCDF.a ../../../bin/libvtkmetaio.a -lcomctl32 ../../../bin/libvtksqlite.a ../../../bin/libvtkpng.a ../../../bin/libvtktiff.a ../../../bin/libvtkzlib.a ../../../bin/libvtkjpeg.a ../../../bin/libvtkexpat.a -lvfw32 ../../../bin/libvtkGraphics.a ../../../bin/libvtkverdict.a ../../../bin/libvtkImaging.a ../../../bin/libvtkFiltering.a ../../../bin/libvtkCommon.a ../../../bin/libvtksys.a -lws2_32 -lm -lpthread -lwsock32 -lgdi32 ../../../bin/libvtkftgl.a ../../../bin/libvtkfreetype.a /usr/lib/w32api/libopengl32.a -lXt -lSM -lICE -lX11 -lXext Oh my! That's very confused about if it's building a w32api or an X11 application. eventually it is a problem of the current cmake-2.6.4 Using the previous cygport cmake-2.8.1-11 and with only a patch at Utilities/vtkpng/pngconf.h to remove the wrong #if defined(__CYGWIN__) ... #endif at row 104-147 plus a small additional modification during build at Examples/Charts/Cxx/CMakeFiles/GraphItem.dir/link.txt to help VTK to find one of its dll's I was able to compile the full vtk-5.6.0 with : --- 98% tests passed, 7 tests failed out of 371 Total Test time (real) = 1910.59 sec The following tests FAILED: 1 - HeaderTesting-Common (Failed) 19 - TestPolynomialSolversUnivariate (Failed) 127 - SLACReaderLinear (Failed) 128 - SLACReaderQuadratic (Failed) 129 - SLACParticleReader (SEGFAULT) 228 - HeaderTesting-Widgets (Failed) 265 - TestSplineWidget (Failed) Errors while running CTest and the dll's are correctly linked with cygGL-1.dll 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
Question marks in localized man pages
Hi. My default LANG is C.UTF-8. If I change it to ru.UTF-8, all non-ascii characters in man pages are displayed as question marks. I found that on Linux before going to nroff, the unzipped man page is first piped through /usr/bin/preconv that escapes non-ascii chars: vim \- Vi IMproved (\[u0423]\[u043B]\[u0443]\[u0447]\[u0448]\[u0435]\[u043D]\[u043D]\[u044B]\[u0439] Vi) On Cygwin the unzipped man page goes directly to nroff, which replaces unknown characters with question marks. I added preconv to /etc/man.conf as follows: NROFF /usr/bin/preconv -e UTF-8 | /usr/bin/nroff -c -mandoc 2/dev/null That solved my problem. I wonder why preconv isn't there by default. -- 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: Question marks in localized man pages
On Saturday, September 11, 2010, Ilya Basin wrote: Hi. My default LANG is C.UTF-8. If I change it to ru.UTF-8, all non-ascii characters in man pages are displayed as question marks. ru.UTF-8 isn't a valid locale setting; you need a territory in there as well, e.g. ru_RU.UTF-8, otherwise you end up in the ASCII-only C locale. Andy -- 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[2]: Question marks in localized man pages
AK On Saturday, September 11, 2010, Ilya Basin wrote: Hi. My default LANG is C.UTF-8. If I change it to ru.UTF-8, all non-ascii characters in man pages are displayed as question marks. AK ru.UTF-8 isn't a valid locale setting; you need a territory in there AK as well, e.g. ru_RU.UTF-8, otherwise you end up in the ASCII-only C AK locale. AK Andy For some reason with the standard ru_RU.UTF-8 man pages are in 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: ***Fatal error couldn't allocate heap win 32 error 487***
2010/9/10 Larry Hall (Cygwin): On 9/10/2010 3:14 PM, Sridhar Balasubramanian wrote: For the past few days, i have been facing this particular problem with cygwin:-- I have a perl script to convert .pgm files to .tif file. It used to be working perfectly fine through cygwin bash shell. However, couple of days back it stopped working and throws the following error: Since this is perl-related, I'd say start with perlrebase. perlrebase is generally not needed when you already did a successful rebaseall. It' just faster and also rebases cpan installed site_perl dll's which are not covered by rebaseall. Only such a new dll can cause a conflict. You can fix these by perlrebase Note that there is a known bug with perlrebase, and the new version is still in internal testing. See http://sourceware.org/ml/cygwin/2010-07/msg00146.html Does it work if you close heavy MS programs, like internet explorer and such? -- Reini Urban -- 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
