Re: setup, upx, and TLS
On Sep 5 20:59, Yaakov S 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. I've been asking for months now for updates to lighttpd (security), nano (security, wchar support) and tidy (latest release, split lib packages), with ready-to-use builds in Ports, and still no response. Lapo? Any chance you can chime in on this discussion? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[ITA] ocaml 3.12.0
Dear Cygwin packagers, It looks like the ocaml package is abandoned: the current version (OCaml 3.08.1) dates back to 2006, and the listed maintainer is Igor Pechtchanski (from before he changed his name). Unless it is by design that OCaml is held back to an obsolete version, I would like to volunteer to take over maintainership. I'm one of the main developers of OCaml, and I've been a cygwin user for a few years now. I'm getting tired of reinstalling OCaml by hand on every new cygwin I install... I have read through the Cygwin Package Contributor's Guide (twice). This is the contents of my setup.hint file for the updated package, mostly unchanged from Igor's version: -- sdesc: The Objective Caml compiler and runtime ldesc: Objective Caml is a fast modern type-inferring functional programming language descended from the ML (Meta Language) family. The OCaml compiler is developed at INRIA's project-team Gallium requires: cygwin libncurses7 category: Interpreters Devel -- -- Damien
Re: [ITA] ocaml 3.12.0
On Sep 6 13:47, Damien Doligez wrote: Dear Cygwin packagers, It looks like the ocaml package is abandoned: the current version (OCaml 3.08.1) dates back to 2006, and the listed maintainer is Igor Pechtchanski (from before he changed his name). Yes, Igor is AWOL for quite some time now, unfortunately. Unless it is by design that OCaml is held back to an obsolete version, I would like to volunteer to take over maintainership. That would be nice. I'm one of the main developers of OCaml, and I've been a cygwin user for a few years now. I'm getting tired of reinstalling OCaml by hand on every new cygwin I install... I have read through the Cygwin Package Contributor's Guide (twice). This is the contents of my setup.hint file for the updated package, mostly unchanged from Igor's version: -- sdesc: The Objective Caml compiler and runtime ldesc: Objective Caml is a fast modern type-inferring functional programming language descended from the ML (Meta Language) family. The OCaml compiler is developed at INRIA's project-team Gallium requires: cygwin libncurses7 category: Interpreters Devel -- That's ok, but for an ITA you should also provide links to the binary and source packages. It's hard to check them for correctness otherwise... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] ocaml 3.12.0
On 9/6/2010 7:47 AM, Damien Doligez wrote: This is the contents of my setup.hint file for the updated package, mostly unchanged from Igor's version: -- sdesc: The Objective Caml compiler and runtime ldesc: Objective Caml is a fast modern type-inferring functional programming language descended from the ML (Meta Language) family. The OCaml compiler is developed at INRIA's project-team Gallium requires: cygwin libncurses7 category: Interpreters Devel -- Are you sure that your new version requires libncurses7? The only current libncurses-dev package will cause you to link against libncurses10... Try cygcheck /usr/bin/name-of-ocaml-exe and see what DLLs it actually uses... Also, new policy is NOT to list 'cygwin' in the requires... -- Chuck
RFU: googlecl-0.9.10-1
Please upload: --- wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.10-1.tar.bz2 \ http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.10-1-src.tar.bz2 --- Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 8/31/2010 7:00 PM, Jon TURNEY wrote: Okay, I think I have worked out the correct thing to do do to handle bpp changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps you could try it and see if it works for you? Note that you will need to use -resize with this build to turn on RANDR in any mode. If you can make this crash, with or without -resize, a backtrace would be very helpful. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 Hmm.. I don't get seg faults while resizing, but every once in a while I'll alt-tab to an xterm and start typing, only to have the xterm evaporate. Once it also happened to emacs, which left both emacs and the terminal pretty well unusable. Unfortunately, I don't get a stack trace or any messages in /var/log/XWin.*.log. It just goes away. I'd never seen this behavior with 1.8.2-0 (or earlier), so I'm rolling back to it. I'll holler if the problem continues. Ideas? Ryan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 9/6/2010 11:01 PM, Ryan Johnson wrote: On 8/31/2010 7:00 PM, Jon TURNEY wrote: Okay, I think I have worked out the correct thing to do do to handle bpp changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps you could try it and see if it works for you? Note that you will need to use -resize with this build to turn on RANDR in any mode. If you can make this crash, with or without -resize, a backtrace would be very helpful. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 Hmm.. I don't get seg faults while resizing, but every once in a while I'll alt-tab to an xterm and start typing, only to have the xterm evaporate. Once it also happened to emacs, which left both emacs and the terminal pretty well unusable. Unfortunately, I don't get a stack trace or any messages in /var/log/XWin.*.log. It just goes away. I'd never seen this behavior with 1.8.2-0 (or earlier), so I'm rolling back to it. I'll holler if the problem continues. Oops. It just happened for 1.8.2-0 and for diff.exe. I've posted the issue to the cygwin mailing list because it doesn't seem x-related if diff.exe dies... Ryan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: frequently getting a STATUS_ACCESS_VIOLATION exception under win7
I was having this same issue. Cygwin Xserver was working properly under Win XP, but the fork failure began occuring when I migrated to Win 7 Home Premium 32-bit. My issue was Microsoft Security Essentials was set to default which allows it to real time scan all files/directories/real-time processes. If you are also running this, I guarantee it is your problem (or at least one of them). To resolve, open Security Essentials and navigate to the settings tab. Under the Excluded files locations menu, add the cygwin root directory (C:\cygwin\ if you used the default install config). Under excluded processes, add startx.exe, startxwin.exe, xterm.exe, and Cygwin.bat. These files will all be in the C:\cygwin\ and C:\cygwin\bin\ directories. Save the changes to the firewall and give it a shot. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog Makefile.in device ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-06 09:47:01 Modified files: winsup/cygwin : ChangeLog Makefile.in devices.cc devices.h devices.in dtable.cc fhandler.h fhandler_disk_file.cc fhandler_netdrive.cc fhandler_proc.cc fhandler_process.cc fhandler_procnet.cc fhandler_registry.cc fhandler_virtual.cc fhandler_virtual.h mount.cc ntdll.h path.cc path.h Added files: winsup/cygwin : fhandler_procsys.cc Log message: * Makefile.in (DLL_OFILES): Add fhandler_procsys.o. * devices.h (enum fh_devices): Add FH_PROCSYS. * devices.in (dev_procsys_storage): New device. * devices.cc: Regenerate. * dtable.cc (build_fh_pc): Add code to allocate fhandler_procsys. * fhandler.h (proc_len): Convert to size_t. (procsys): Declare. (procsys_len): Declare. (enum virtual_ftype_t): Move here from fhandler_virtual.h. Add members supported by fhandler_procsys. (fhandler_virtual::exists): Return virtual_ftype_t. Change in all derived classes. (class fhandler_procsys): New class. (fhandler_union): Add fhandler_procnet and fhandler_procsys members. * fhandler_disk_file.cc (__DIR_mounts::check_missing_mount): Use ro_u_proc. (fhandler_base::fstat_by_handle): Don't copy attributes if file is an NT device. (fhandler_base::fstat_by_name): Ditto. * fhandler_netdrive.cc (fhandler_netdrive::exists): Return virtual_ftype_t. * fhandler_proc.cc (proc_tab): Sort alphabetically. Use _VN macro to store length. (proc_len): Change to size_t. (proc_tab_cmp): New static function. (virt_tab_search): New function to search entry in virt_tab_t arrays. Use throughout in /proc and sibling classes instead of loop. (fhandler_proc::exists): Return virtual_ftype_t. * fhandler_process.cc (process_tab): Sort alphabetically. Use _VN macro to store length. (fhandler_process::exists): Return virtual_ftype_t. (fhandler_process::open): Simplify code. * fhandler_procnet.cc (procnet_tab): Sort alphabetically. Use _VN macro to store length. (fhandler_procnet::exists): Return virtual_ftype_t. (fhandler_procnet::open): Simplify. * fhandler_procsys.cc: New file. * fhandler_registry.cc (fhandler_registry::exists): Return virtual_ftype_t. * fhandler_virtual.cc (fhandler_virtual::exists): Ditto. * fhandler_virtual.h (enum virtual_ftype_t): Move to fhandler.h. (virt_tab_t): Add name_len member. (_VN): New macro. (virt_tab_search): Declare. * mount.cc (mount_info::conv_to_win32_path): Fix comment. Backslashify isprocsys_dev paths. * ntdll.h (STATUS_OBJECT_TYPE_MISMATCH): Define (STATUS_INSTANCE_NOT_AVAILABLE): Define. (STATUS_PIPE_NOT_AVAILABLE): Define. (STATUS_INVALID_PIPE_STATE): Define. (STATUS_PIPE_BUSY): Define. (SYMBOLIC_LINK_QUERY): Define. (NtOpenSymbolicLinkObject): Declare. (NtQuerySymbolicLinkObject): Declare. * path.cc (path_conv::check): Accommodate fact that exists method returns virtual_ftype_t now. Add cases for new virtual_ftype_t types. (cygwin_conv_path): Add GLOBALROOT prefix to native device paths. Make sure to strip \\?\ prefix only for actual filesystem-based paths, not for all paths. * path.h (isproc_dev): Add FH_PROCSYS. (isprocsys_dev): Define. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_procsys.cc.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5025r2=1.5026 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/Makefile.in.diff?cvsroot=srcr1=1.237r2=1.238 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/devices.cc.diff?cvsroot=srcr1=1.31r2=1.32 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/devices.h.diff?cvsroot=srcr1=1.25r2=1.26 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/devices.in.diff?cvsroot=srcr1=1.22r2=1.23 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dtable.cc.diff?cvsroot=srcr1=1.216r2=1.217 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.h.diff?cvsroot=srcr1=1.403r2=1.404 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.334r2=1.335 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_netdrive.cc.diff?cvsroot=srcr1=1.29r2=1.30 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_proc.cc.diff?cvsroot=srcr1=1.92r2=1.93
src/winsup/utils ChangeLog cygpath.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-06 09:48:55 Modified files: winsup/utils : ChangeLog cygpath.cc Log message: * cygpath.cc (RtlEqualUnicodePathPrefix): New helper function. (HARDDISK_PREFIX): Move. (GLOBALROOT_PREFIX): Define. (get_device_name): Take GLOBALROOT_PREFIX into account. Improve check for path to allow filesystem access via block devices. Potentially drop \\.\ prefix if resulting path is a valid DOS pathname. (do_pathconv): Make sure to drop \\?\ prefix only if path is actually a filesystem based path. (print_version): Fix copyright. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.541r2=1.542 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/cygpath.cc.diff?cvsroot=srcr1=1.63r2=1.64
src/winsup/doc ChangeLog new-features.sgml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-06 14:42:30 Modified files: winsup/doc : ChangeLog new-features.sgml Log message: * new-features.sgml (ov-new1.7.8): Document /proc/sys. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.315r2=1.316 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/new-features.sgml.diff?cvsroot=srcr1=1.55r2=1.56
Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
Thanks for the patch and for all of the work you put into it. On Mon, Sep 06, 2010 at 03:24:09PM +0200, Corinna Vinschen wrote: The patch is also missing a ChangeLog entry. I only took a quick glance over the patch itself. The code doesn't look correctly formatted in GNU style. Also, using the diff -up flags would be helpful. And, this is the type of patch which would be better served if submitted in small chunks. You have multiple changes in your 1158 line patch and they don't seem to all be interrelated. Also, in addition to formatting concerns, you don't seem to have used comments very much. Corinna and I have been making a concerted effort to comment changes more thoroughly so it would be nice if your patch contained more of those. I didn't look at the patch very closely either since there are copyright issues but some of your conclusions don't seem right to me. I agree with Corinna's response. cgf
RE: Packaging error with Octave 3.2.4?
it seems a problem on my last update of libqhull_5 downgrading from 2010.1-1 to 2009.1.1-1 solves the problem. Thanks, Marco! that did the trick. tanti saluti, Peter -- 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: .exe magic reloaded
On Sep 5 16:28, Al wrote: I came accross the following. These two files existed. /home/prefix/gentoo/bin/tr.exe /home/prefix/gentoo/usr/bin/tr - /home/prefix/gentoo.bin/tr.exe ^^^ dot, not slash? So we have a symblic link to an executable from a different directory. Perls configuration script detected /home/prefix/gentoo/usr/bin/tr and called it as /home/prefix/gentoo/usr/bin/tr.exe. That didn't work. Obviously the .exe magic does not work for symbolic links from a different directory. It does: $ cd tmp $ mkdir dir1 dir2 $ cp /bin/echo.exe dir1 $ ln -s `pwd`/dir1/echo.exe dir2/echo $ ls -l dir* dir1: total 52 -rwxr-xr-x 1 corinna vinschen 49166 2010-09-06 10:59 echo.exe dir2: total 1 lrwxrwxrwx 1 corinna vinschen 31 2010-09-06 11:00 echo - /home/corinna/tmp/dir1/echo.exe $ dir2/echo hello hello $ /home/corinna/tmp/dir2/echo hello hello I solved that by adding a second symbolic link /home/prefix/gentoo/usr/bin/tr.exe. What is the best way to go here? Find out what *really* has gone wrong. 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: LC_ALL=ru_RU.cp1251 ls -l encoding problem.
On Sep 5 21:16, Oleksandr Gavenko wrote: As you can see user/group always printed in UTF-8 and discard LC_ALL=cp1251. $ LC_ALL=ru_RU.cp1251 mintty The problem is, what is the encoding of the /etc/passwd file itself? If it's UTF-8, it's UTF-8. If you want to use another encoding throughout, you would have to generate the /etc/passwd and /etc/group files in that other encoding as well. 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: .exe magic reloaded
It does not: It does: $ cd tmp $ mkdir dir1 dir2 $ cp /bin/echo.exe dir1 $ ln -s `pwd`/dir1/echo.exe dir2/echo $ ls -l dir* dir1: total 52 -rwxr-xr-x 1 corinna vinschen 49166 2010-09-06 10:59 echo.exe dir2: total 1 lrwxrwxrwx 1 corinna vinschen 31 2010-09-06 11:00 echo - /home/corinna/tmp/dir1/echo.exe $ dir2/echo hello hello $ /home/corinna/tmp/dir2/echo hello hello $ /home/corinna/tmp/dir2/echo.exe hello bash: /home/corinna/tmp/dir2/echo.exe: No such file or directory That's what Perls Configure does. Still the magic works only in the target directory, but not on the level of the symlink itself. Al -- 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: .exe magic reloaded
On Sep 6 11:53, Al wrote: It does not: It does: $ cd tmp $ mkdir dir1 dir2 $ cp /bin/echo.exe dir1 $ ln -s `pwd`/dir1/echo.exe dir2/echo $ ls -l dir* dir1: total 52 -rwxr-xr-x 1 corinna vinschen 49166 2010-09-06 10:59 echo.exe dir2: total 1 lrwxrwxrwx 1 corinna vinschen 31 2010-09-06 11:00 echo - /home/corinna/tmp/dir1/echo.exe $ dir2/echo hello hello $ /home/corinna/tmp/dir2/echo hello hello $ /home/corinna/tmp/dir2/echo.exe hello bash: /home/corinna/tmp/dir2/echo.exe: No such file or directory That's what Perls Configure does. Still the magic works only in the target directory, but not on the level of the symlink itself. Uh, I see. That's a bug in perl's Configure. It shouldn't use the .exe suffix at all. 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: .exe magic reloaded
That's what Perls Configure does. Still the magic works only in the target directory, but not on the level of the symlink itself. Uh, I see. That's a bug in perl's Configure. It shouldn't use the .exe suffix at all. Right, Perl wants to be superschlau and adds the .exe suffix. That would work in Cygwins standard locations, where /bin and /usr/bin seems to be the same. Is this a Bug on the side of Perls Configure or rather a limitation in Cygwins .exe magic? As there is no official standard, how to deal with this, it remains a point of philosophy. So far it was the only case in 30 packages I compiled. Al -- 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: rakudo-star-201007-1, Updated: rakudo-201007_47-1 (aka perl6)
2010/9/1 Michael Schaap cygwin.li...@mscha.org:
However, with rakudo-star 201007-1, rakudo_47-1 and parrot 2.6.0-1
installed:
$ perl6 -e 'say hello;'
hello
$ perl6 -e 'sub hello() { say hello; }'
===SORRY!===
No such file or directory
Works for me, but it looks like a missing packaging dependency in the hint
$ perl6 -e 'sub hello() { say hello; }'
$ perl6 -e 'sub hello() { say hello; }; hello'
hello
Can you try
$ ldd /usr/bin/perl6.exe
ntdll.dll = /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x76e8)
kernel32.dll = /cygdrive/c/Windows/system32/kernel32.dll (0x754f)
KERNELBASE.dll = /cygdrive/c/Windows/system32/KERNELBASE.dll
(0x751f)
cygwin1.dll = /usr/bin/cygwin1.dll (0x6100)
ADVAPI32.DLL = /cygdrive/c/Windows/system32/ADVAPI32.DLL (0x7595)
msvcrt.dll = /cygdrive/c/Windows/system32/msvcrt.dll (0x75d5)
sechost.dll = /cygdrive/c/Windows/SYSTEM32/sechost.dll (0x75e9)
RPCRT4.dll = /cygdrive/c/Windows/system32/RPCRT4.dll (0x756a)
cygparrot2_6_0.dll = /usr/bin/cygparrot2_6_0.dll (0x6334)
cyggcc_s-1.dll = /usr/bin/cyggcc_s-1.dll (0x6bf4)
cygssp-0.dll = /usr/bin/cygssp-0.dll (0x6728)
cyggmp-3.dll = /usr/bin/cyggmp-3.dll (0x6d3a)
cygintl-8.dll = /usr/bin/cygintl-8.dll (0x6a35)
cygiconv-2.dll = /usr/bin/cygiconv-2.dll (0x6c33)
cygreadline7.dll = /usr/bin/cygreadline7.dll (0x6887)
cygncurses-9.dll = /usr/bin/cygncurses-9.dll (0x68b6)
USER32.dll = /cygdrive/c/Windows/system32/USER32.dll (0x7534)
GDI32.dll = /cygdrive/c/Windows/system32/GDI32.dll (0x75e1)
LPK.dll = /cygdrive/c/Windows/system32/LPK.dll (0x75e0)
USP10.dll = /cygdrive/c/Windows/system32/USP10.dll (0x75eb)
cygicuuc38.dll = /usr/bin/cygicuuc38.dll (0x6b53)
cygstdc++-6.dll = /usr/bin/cygstdc++-6.dll (0x6c48)
cygicudata38.dll = /usr/bin/cygicudata38.dll (0x19a)
SspiCli.dll = /cygdrive/c/Windows/system32/SspiCli.dll (0x74ee)
and report the missing dll.
Or if it's dynamic maybe install parrot-devel.
However I didn't saw any dynext missing.
$ strace perl6 -e 'sub hello() { say hello; }; hello' 21 |grep .dll \
/usr/src/perl/parrot/perl6.deps.strace
# dynexts
$ grep src /usr/lib/parrot/2.6.0/dynext/
/usr/src/perl/parrot/perl6.deps.strace
# vs
$ zgrep dynext /etc/setup/rakudo.lst.gz
# and
$ zgrep dynext /etc/setup/parrot.lst.gz
# and the rest
$ grep .dll /usr/src/perl/parrot/perl6.deps.strace|grep -v dynext
Dynamically loaded:
/usr/bin/cygiconv-2.dll
/usr/bin/cygintl-8.dll
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
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: Cygwin slow on x64 systems
Hi Magnus, I applied your patch but I don't notice for any improvement in performance with my test case (I still get only 7 lines/sec). I tried it with several cygwin 1.7.7-1 revisions Which version of cygwin sources do you use ? Did you try it with the latest snapshot ? Thanks, Sagi. Magnus Holmgren wrote: I did some testing on my 64-bit Vista system, and it appears that CreateThread is the main cause. To test this, I removed the call to sigproc_init in dll_crt0_0 and made sure it was always called in dll_crt0_1 instead. Suddenly the sigp thread started executing immediately, and its initialization was complete long before wait_for_sigthread was called. Since you obviously have a patch, would you mind sharing it, rather than just your conclusions from said patch? Not quite ready for commit as is, but here it is: Index: src/winsup/cygwin/dcrt0.cc === RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v retrieving revision 1.382 diff -r1.382 dcrt0.cc 746,747c746,747 if (!dynamically_loaded) sigproc_init (); --- //if (!dynamically_loaded) //sigproc_init (); 792c792 if (dynamically_loaded) --- //if (dynamically_loaded) Magnus -- 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: .exe magic reloaded
On Sep 6 12:36, Al wrote: That's what Perls Configure does. Still the magic works only in the target directory, but not on the level of the symlink itself. Uh, I see. That's a bug in perl's Configure. It shouldn't use the .exe suffix at all. Right, Perl wants to be superschlau and adds the .exe suffix. That would work in Cygwins standard locations, where /bin and /usr/bin seems to be the same. Is this a Bug on the side of Perls Configure or rather a limitation in Cygwins .exe magic? As there is no official standard, how to deal with this, it remains a point of philosophy. So far it was the only case in 30 packages I compiled. It's definitely a bug in perl's Configure. If the name of the symlink is foo, there's not the faintest reason to assume that foo.exe should work at all. 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: .exe magic reloaded
It's definitely a bug in perl's Configure. If the name of the symlink is foo, there's not the faintest reason to assume that foo.exe should work at all. Corinna Magic is when it does the right thing magically. With your approach you don't need any magic at all. Al -- 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: .exe magic reloaded
On Sep 6 14:56, Al wrote: It's definitely a bug in perl's Configure. If the name of the symlink is foo, there's not the faintest reason to assume that foo.exe should work at all. Corinna Magic is when it does the right thing magically. With your approach you don't need any magic at all. You don't seem to understand the magic here. The magic is to add the .exe suffix to a filename. If you have a file foo.exe and call foo, you get foo.exe. If you have a symlink foo-sym pointing to foo, and you call foo-sym, you also get foo.exe, since the exe magic still works after the symlink has been evaluated. However, if you call foo-syml.exe, you made a mistake. There is no file called foo-sym.exe, which could be opened, neither is there a symlink called foo-sym.exe. The magic is to *add* the .exe suffix automatically, not *removing* it when you specified it wrongly. If you think that further, you would also expect that I can open a file foo.txt by calling `vim foo.txt.exe'. 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: rakudo-star-201007-1, Updated: rakudo-201007_47-1 (aka perl6)
On 6-Sep-2010 13:04, Reini Urban wrote:
2010/9/1 Michael Schaapcygwin.li...@mscha.org:
However, with rakudo-star 201007-1, rakudo_47-1 and parrot 2.6.0-1
installed:
$ perl6 -e 'say hello;'
hello
$ perl6 -e 'sub hello() { say hello; }'
===SORRY!===
No such file or directory
Works for me, but it looks like a missing packaging dependency in the hint
$ perl6 -e 'sub hello() { say hello; }'
$ perl6 -e 'sub hello() { say hello; }; hello'
hello
Can you try
$ ldd /usr/bin/perl6.exe
ntdll.dll = /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x76e8)
kernel32.dll = /cygdrive/c/Windows/system32/kernel32.dll (0x754f)
KERNELBASE.dll = /cygdrive/c/Windows/system32/KERNELBASE.dll
(0x751f)
cygwin1.dll = /usr/bin/cygwin1.dll (0x6100)
ADVAPI32.DLL = /cygdrive/c/Windows/system32/ADVAPI32.DLL (0x7595)
msvcrt.dll = /cygdrive/c/Windows/system32/msvcrt.dll (0x75d5)
sechost.dll = /cygdrive/c/Windows/SYSTEM32/sechost.dll (0x75e9)
RPCRT4.dll = /cygdrive/c/Windows/system32/RPCRT4.dll (0x756a)
cygparrot2_6_0.dll = /usr/bin/cygparrot2_6_0.dll (0x6334)
cyggcc_s-1.dll = /usr/bin/cyggcc_s-1.dll (0x6bf4)
cygssp-0.dll = /usr/bin/cygssp-0.dll (0x6728)
cyggmp-3.dll = /usr/bin/cyggmp-3.dll (0x6d3a)
cygintl-8.dll = /usr/bin/cygintl-8.dll (0x6a35)
cygiconv-2.dll = /usr/bin/cygiconv-2.dll (0x6c33)
cygreadline7.dll = /usr/bin/cygreadline7.dll (0x6887)
cygncurses-9.dll = /usr/bin/cygncurses-9.dll (0x68b6)
USER32.dll = /cygdrive/c/Windows/system32/USER32.dll (0x7534)
GDI32.dll = /cygdrive/c/Windows/system32/GDI32.dll (0x75e1)
LPK.dll = /cygdrive/c/Windows/system32/LPK.dll (0x75e0)
USP10.dll = /cygdrive/c/Windows/system32/USP10.dll (0x75eb)
cygicuuc38.dll = /usr/bin/cygicuuc38.dll (0x6b53)
cygstdc++-6.dll = /usr/bin/cygstdc++-6.dll (0x6c48)
cygicudata38.dll = /usr/bin/cygicudata38.dll (0x19a)
SspiCli.dll = /cygdrive/c/Windows/system32/SspiCli.dll (0x74ee)
Looks the same here. (That was to be expected, since perl6 -e 'say
hello;' works fine.)
and report the missing dll.
Or if it's dynamic maybe install parrot-devel.
Installing parrot-devel (and the following (direct and indirect)
dependencies) worked indeed!
gmp (4.3.1-3)
GMP is a free library for arbitrary precision arithmetic
Required by: libgmp-devel
icu (3.8-7)
IBM Internationalization Components for Unicode (apps and docs)
Required by: libicu-devel
libgdbm-devel (1.8.3-20)
GNU dbm database routines (development)
Required by: parrot-devel
libgmp-devel (4.3.1-3)
Development library for GMP arbitrary precision arithmetic library
Required by: parrot-devel
libicu-devel (3.8-7)
IBM Internationalization Components for Unicode (development)
Required by: parrot-devel
libncurses-devel (5.7-18)
(devel) libraries for terminal handling
Required by: parrot-devel, readline
libpcre-devel (8.02-1)
Perl-Compatible Regular Expressions library (C development)
Required by: pcre-devel
pcre-devel (7.9-1)
Obsolete package
Required by: parrot-devel
readline (6.0.3-2)
GNU readline and history libraries
Required by: parrot-devel
However I didn't saw any dynext missing.
$ strace perl6 -e 'sub hello() { say hello; }; hello' 21 |grep .dll \
/usr/src/perl/parrot/perl6.deps.strace
# dynexts
$ grep src /usr/lib/parrot/2.6.0/dynext/
/usr/src/perl/parrot/perl6.deps.strace
# vs
$ zgrep dynext /etc/setup/rakudo.lst.gz
# and
$ zgrep dynext /etc/setup/parrot.lst.gz
# and the rest
$ grep .dll /usr/src/perl/parrot/perl6.deps.strace|grep -v dynext
Dynamically loaded:
/usr/bin/cygiconv-2.dll
/usr/bin/cygintl-8.dll
It doesn't appear to be a .dll, I didn't see anything suspicious. (The
dynext stuff was certainly complete.)
I did compare the before-and-after strace output, and the first
significant difference is when it tries to load
/usr/lib/parrot/2.6.0/include/except_types.pasm, which is indeed present
in parrot-devel.
– Michael
--
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: .exe magic reloaded
The magic is to *add* the .exe suffix automatically, not *removing* it Aaaahh! That is one point I missed. The magic is still more limited than I assumed. It felt to work bidirectional. I have tested this. The unidirectonal magic also works for symlinks, if the symlink has the .exe suffix itself. Back to the starting point. It follows the sysmlink should be: /home/prefix/gentoo/usr/bin/tr.exe - /home/prefix/gentoo/bin/tr.exe instead of /home/prefix/gentoo/usr/bin/tr - /home/prefix/gentoo/bin/tr.exe Then it would proxy all available .exe magic and even Perls Configure would work. This means that not only the Perl package but also my Coreutils package should be optimized. when you specified it wrongly. If you think that further, you would also expect that I can open a file foo.txt by calling `vim foo.txt.exe'. If foo.txt is not executable it would not be expanded. Thank you very much Corinna Al -- 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
permission denied when removing files on remote file share that is offline
Hi I think my problem appeared after upgrading to cygwin 1.7.7 but it might have been present before that as well, I am not sure. I'm using a file share with Offline Folders such that I can access it when not connected to our intranet. In cygwin I cannot remove any files that I create on the share when it's offline: $ touch /xxx/testfile $ rm /xxx/testfile rm: cannot remove `/xxx/testfile': Permission denied I can create/modify the files without trouble, but not delete them. I can delete the file with Windows Explorer. getfacl doesn't show anything strange. I can delte the file once the file share gets @connected@ again. Everything works fine on my local disks. This happens both when specifying the file share, or when using a drive letter: $ mount //fileserver/myusername$ /xxx $ mount h: /xxx Some extra info: $ net use New connections will be remembered. Status Local RemoteNetwork --- OK H:\\fileserver\myusername$ Microsoft Windows Network The command completed successfully. after mounting the file share explicitly $ mount |grep xxx //fileserver/myusername$ on /xxx type ntfs (binary,notexec,user) Anyone any suggestions? Thanks! Kris -- 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: rakudo-star-201007-1, Updated: rakudo-201007_47-1 (aka perl6)
2010/9/6 Michael Schaap: /usr/lib/parrot/2.6.0/include/except_types.pasm Good! I'll report upstream to move it to main. There are several errors like this expected, as the -devel package layout and testing is poorly maintained. I fixed those years ago for my earlier cygwin packages, but most of my fixes were never applied. It's still beta quality after all. -- 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
Re: .exe magic reloaded
2010/9/6 Al: The magic is to *add* the .exe suffix automatically, not *removing* it Aaaahh! That is one point I missed. The magic is still more limited than I assumed. It felt to work bidirectional. I have tested this. The unidirectonal magic also works for symlinks, if the symlink has the .exe suffix itself. Back to the starting point. It follows the sysmlink should be: /home/prefix/gentoo/usr/bin/tr.exe - /home/prefix/gentoo/bin/tr.exe instead of /home/prefix/gentoo/usr/bin/tr - /home/prefix/gentoo/bin/tr.exe Then it would proxy all available .exe magic and even Perls Configure would work. I got a little bit confused now. Should I report now upstream at Perl that Configure has a problem by adding .exe, or is it just a problem with your layout? AFAIK perl does not symlink tr.exe, just its own files when using -Dmksymlinks. And failing to read a wrong tr.exe symlink does not look like perls fault. -- 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
Re: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
On 08/12/2010 01:45 PM, Corinna Vinschen wrote: http://dch.posterous.com/cygwin-dumps-core-on-windows-2008-r1sp2-on-ec So, this muse-ing of yours is not correct. To me this implies that the Amazon Cloud VMs have some BLODA installed by default. I'm not going to check this voluntarily. I suggest that somebody who wants to run Cygwin on such a machine investigates this further, or just asks Amazon to fix this and hope for the best. I'm not into Cygwin development enough to know what a BLODA is, but you may like to know the bug is in the Xen hypervisor used by Amazon. I don't know exactly what releases or Xen are affected, but for sure all RHEL5 (and CentOS 5) hypervisors are. The reason why you see it only on 64-bit Windows, is that the bug is about Xen mishandling the SWAPGS instruction which, well, is only present in 64-bit processors and in 64-bit mode. https://bugzilla.redhat.com/show_bug.cgi?id=613187 Paolo ps: KVM was also affected until last February. I haven't checked if RHEL/CentOS KVM has the bug, but I'll ask fellow developers around about it. -- 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: .exe magic reloaded
I got a little bit confused now. Should I report now upstream at Perl that Configure has a problem by adding .exe, or is it just a problem with your layout? AFAIK perl does not symlink tr.exe, just its own files when using -Dmksymlinks. And failing to read a wrong tr.exe symlink does not look like perls fault. I estimate it as a very low priority bug in Perls Configure script. * It doesn't matter outside Cygwin. * It doesn't matter for a standard Cygwin installation. * It only matters for installations on a prefixed location in Cygwin. My bottomline: It is not worth to report it. It can be patched downstream in the special situation. But to make Perls setup more perfect ... who knows! Al -- 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: .exe magic reloaded
I got a little bit confused now. Should I report now upstream at Perl that Configure has a problem by adding .exe, or is it just a problem with your layout? AFAIK perl does not symlink tr.exe, just its own files when using -Dmksymlinks. And failing to read a wrong tr.exe symlink does not look like perls fault. -- Reini Urban As you ask for bugs in Perl on Cygwin. I found a second issue in my Makefile, the all target: all: $(FIRSTMAKEFILE) miniperl$(EXE_EXT) miniperl $(generated_pods) $(private) $(unidatafiles) $(public) $(dynamic_ext) $(nonxs_ext) extras.make I think that is one miniperl to much. This did break, when I compiled with make -j3. The error was: make: *** No rule to make target `miniperl', needed by `all'. Stop. It's possible that this is already fixed in the Cygwin source. See: http://en.gentoo-wiki.com/wiki/Prefix/Cygwin#dev-lang.2Fperl:_No_rule_to_make_target_miniperl Al -- 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: permission denied when removing files on remote file share that is offline
On Sep 6 15:33, Thielemans, Kris wrote: Hi I think my problem appeared after upgrading to cygwin 1.7.7 but it might have been present before that as well, I am not sure. I'm using a file share with Offline Folders such that I can access it when not connected to our intranet. In cygwin I cannot remove any files that I create on the share when it's offline: $ touch /xxx/testfile $ rm /xxx/testfile rm: cannot remove `/xxx/testfile': Permission denied I can create/modify the files without trouble, but not delete them. I can delete the file with Windows Explorer. getfacl doesn't show anything strange. I can delte the file once the file share gets @connected@ again. Everything works fine on my local disks. This happens both when specifying the file share, or when using a drive letter: $ mount //fileserver/myusername$ /xxx $ mount h: /xxx Some extra info: $ net use New connections will be remembered. Status Local RemoteNetwork --- OK H:\\fileserver\myusername$ Microsoft Windows Network The command completed successfully. after mounting the file share explicitly $ mount |grep xxx //fileserver/myusername$ on /xxx type ntfs (binary,notexec,user) Strange. I cannot reproduce this problem. I created a share on a server just for this purpose, then, on the client, made it available offline and synced it once. Then I disconnected the NIC: $ net use Status Local RemoteNetwork --- Disconnected H:\\fileserver\myusername$ Microsoft Windows Network The command completed successfully. $ touch /mnt/h/xyz/testfile $ rm /mnt/h/xyz/testfile Works like a charm. I tried the same with an additional explicit Cygwin mount, which worked fine as well. Can you run rm under strace? Maybe there's a status code which gives some helpful information. Look for the unlink_nt function. 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
XEmacs warning
Hi All, I have been getting the following Xemacs error with all 1.7 Cygwin releases that I have tried: WARNING: Couldn't find an obvious default for the root of the XEmacs hierarchy. I saw a similar issue came up in 2006, and Dr. Volker Zell fixed it with a new XEmacs release. The output of cygcheck -c follows. Thanks, David Cygwin Package Information Package Version Status _update-info-dir 00914-1 OK alternatives 1.3.30c-10 OK base-cygwin 2.1-1 OK base-files 3.9-3 OK base-passwd 3.1-1 OK bash 3.2.51-24 OK bc 1.06-2 OK binutils 2.20.51-2 OK bison2.4.2-1 OK bzip21.0.5-10OK cocom0.995-1 OK compface 1.5.2-11OK coreutils8.5-2 OK crypt1.1-1 OK cvs 1.12.13-10 OK cygutils 1.4.4-1 OK cygwin 1.7.7-1 OK cygwin-doc 1.7-1 OK dash 0.5.6.1-2 OK dejagnu 20021217-2 OK diffutils2.9-1 OK editrights 1.01-2 OK emacs23.2-1 OK expect 20030128-1 OK findutils4.5.9-1 OK flex 2.5.35-1OK gawk 3.1.8-1 OK gcc-core 3.4.4-999 OK gcc-g++ 3.4.4-999 OK gcc-mingw-core 20050522-1 OK gcc-mingw-g++20050522-1 OK gettext 0.17-11 OK grep 2.6.3-1 OK groff1.20.1-2OK gzip 1.3.12-2OK ipc-utils1.0-1 OK less 436-1 OK libattr1 2.4.43-1OK libaudio21.9.2-1 OK libbz2_1 1.0.5-10OK libcharset1 1.13.1-1OK libcompface0 1.5.2-11OK libdb4.2 4.2.52.5-2 OK libdb4.5 4.5.20.2-2 OK libexpat12.0.1-1 OK libfontconfig1 2.8.0-1 OK libfreetype6 2.3.12-1OK libgcc1 4.3.4-3 OK libgdbm4 1.8.3-20OK libgmp3 4.3.1-3 OK libICE6 1.0.6-1 OK libiconv 1.13.1-1OK libiconv21.13.1-1OK libintl3 0.14.5-1OK libintl8 0.17-11 OK libjbig2 2.0-11 OK libjpeg626b-21 OK libjpeg7 7-10OK liblzma1 4.999.9beta-11 OK libncurses10 5.7-18 OK libncurses8 5.5-10 OK libncurses9 5.7-16 OK libncursesw105.7-18 OK libopenldap2_3_0 2.3.43-1OK libopenssl0980.9.8o-2OK libpcre0 8.02-1 OK libpng12 1.2.44-1OK libpopt0 1.6.4-4 OK libpq5 8.2.11-1OK libreadline6 5.2.14-12 OK libreadline7 6.0.3-2 OK libsasl2 2.1.23-1OK libsigsegv0 2.6-1 OK libsigsegv2 2.8-1 OK libSM6 1.1.1-2 OK libssp0 4.3.4-3 OK libstdc++6 4.3.4-3 OK libtiff5 3.9.2-1 OK libuuid1 2.17.2-1OK libX11_6 1.3.3-1 OK libXau6 1.0.6-1 OK libXaw3d71.5D-10 OK libxcb1 1.6-1 OK libXdmcp61.0.3-1 OK libXext6 1.1.2-1 OK libXft2 2.1.14-1OK libXmu6 1.0.5-1 OK libXpm4 3.5.8-1 OK libXrender1 0.9.6-1 OK libXt6 1.0.8-1 OK login1.10-10 OK m4 1.4.15-1OK make 3.81-2 OK man 1.6f-1 OK mingw-runtime3.18-1 OK minires 1.02-1 OK openssl 0.9.8o-2OK perl 5.10.1-3OK rebase 3.0.1-1 OK run 1.1.12-11 OK sed 4.2.1-1 OK tar 1.23-1 OK tcltk20080420-1 OK terminfo 5.7_20091114-14 OK
Re: Cygwin slow on x64 systems
On Mon, Sep 06, 2010 at 02:31:54PM +0300, Sagi Ben-Akiva wrote: Hi Magnus, I applied your patch but I don't notice for any improvement in performance with my test case (I still get only 7 lines/sec). I tried it with several cygwin 1.7.7-1 revisions Which version of cygwin sources do you use ? Did you try it with the latest snapshot ? Why are you trying obsolete patches when I've indicated that there is a fix available in the latest snapshot? cgf -- 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: XEmacs warning
David Morgan writes: Hi All, I have been getting the following Xemacs error with all 1.7 Cygwin releases that I have tried: WARNING: Couldn't find an obvious default for the root of the XEmacs hierarchy. I saw a similar issue came up in 2006, and Dr. Volker Zell fixed it with a new XEmacs release. The output of cygcheck -c follows. Hi David it works perfectly fine for me. I guess you'll have to give some more details about your installation. (I have no idea what's relevant though...) Kris -- 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: Cygwin slow on x64 systems
On 06/09/2010 19:29, Christopher Faylor wrote: On Mon, Sep 06, 2010 at 02:31:54PM +0300, Sagi Ben-Akiva wrote: Hi Magnus, I applied your patch but I don't notice for any improvement in performance with my test case (I still get only 7 lines/sec). I tried it with several cygwin 1.7.7-1 revisions Which version of cygwin sources do you use ? Did you try it with the latest snapshot ? Why are you trying obsolete patches when I've indicated that there is a fix available in the latest snapshot? cgf Because with the snapshot that you published I still get slow performance. I tried the cygwin1.dll snapshot from 2010-09-01 and from 2010-09-04. Sagi. -- 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
Fw: Hello, I need help with PHP compiling and/or how to get PCTNL extension working under cygwin
I have research this issue over google and mailing list and I haven't been able to find a solution to my problem. I want to write a PHPProxyServer under CYGWIN since I don't have access to a linux box. I need the PCTNL functions so I could fork() processes, which is not supported under windows. I try decending into the extensions directory in PHP src provided by cygwinports and try to compile the extension myself. Everything seems to work fine up until the desired extension *.dll wasn't created and make install failed with cp: target `/usr/lib/php/20060613/#i...@3872#' is not a directory. So I decided to try to compile the newest version of PHP available, epic failure because apparently, PHP ./configure doesn't support autoconf 2.65, only 2.13 which isn't available in the repos. I was hoping that maybe someone might have already have already compiled PCNTL extension available that I could download for PHP 5.2.6 or the new PHP binaries with PCNTL enabled? Or any support to compile PHP under cygwin? -- 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: XEmacs warning
On Mon, Sep 06, 2010 at 05:41:38PM +, Kris Thielemans wrote: it works perfectly fine for me. I guess you'll have to give some more details about your installation. (I have no idea what's relevant though...) Hi Kris, thanks for the reply. I am seeing this on two different Window 7 Professional x64 systems. I have tried running with both the standard .bashrc and my usual one. I do not have any .emacs files installed. I searched the registry for any emacs-related keys, and did not find any. None of the command-line options make any difference - even xemacs --version prints the warning. Attached are cygcheck -l outputs for xemacs and xemacs-emacs-common, as well as a printenv dump. I am willing to debug this directly, but I've never learned how to build packages other than winsup itself. Regards, David $cygcheck -l xemacs-emacs-common /usr/bin/b2m.exe /usr/bin/rcs-checkin /usr/share/doc/Cygwin/xemacs-emacs-common-21.4.22.README $cygcheck -l xemacs /usr/bin/gnuattach /usr/bin/gnuclient.exe /usr/bin/gnudoit /usr/bin/ootags.exe /usr/bin/winclient.exe /usr/bin/xemacs-21.4.22-498097a3.dmp /usr/bin/xemacs-21.4.22.exe /usr/bin/xemacs /usr/lib/xemacs-21.4.22/i686-pc-cygwin/add-big-package.sh /usr/lib/xemacs-21.4.22/i686-pc-cygwin/config.values /usr/lib/xemacs-21.4.22/i686-pc-cygwin/cvtmail.exe /usr/lib/xemacs-21.4.22/i686-pc-cygwin/digest-doc.exe /usr/lib/xemacs-21.4.22/i686-pc-cygwin/DOC /usr/lib/xemacs-21.4.22/i686-pc-cygwin/fakemail.exe /usr/lib/xemacs-21.4.22/i686-pc-cygwin/gnuserv.exe /usr/lib/xemacs-21.4.22/i686-pc-cygwin/gzip-el.sh /usr/lib/xemacs-21.4.22/i686-pc-cygwin/hexl.exe /usr/lib/xemacs-21.4.22/i686-pc-cygwin/make-docfile.exe /usr/lib/xemacs-21.4.22/i686-pc-cygwin/mmencode.exe /usr/lib/xemacs-21.4.22/i686-pc-cygwin/movemail.exe /usr/lib/xemacs-21.4.22/i686-pc-cygwin/profile.exe /usr/lib/xemacs-21.4.22/i686-pc-cygwin/rcs2log /usr/lib/xemacs-21.4.22/i686-pc-cygwin/sorted-doc.exe /usr/lib/xemacs-21.4.22/i686-pc-cygwin/vcdiff /usr/lib/xemacs-21.4.22/i686-pc-cygwin/wakeup.exe /usr/lib/xemacs-21.4.22/i686-pc-cygwin/yow.exe /usr/share/doc/Cygwin/xemacs-21.4.22.README /usr/share/doc/xemacs-21.4.22/BUGS /usr/share/doc/xemacs-21.4.22/ChangeLog /usr/share/doc/xemacs-21.4.22/CHANGES-msw /usr/share/doc/xemacs-21.4.22/CHANGES-release /usr/share/doc/xemacs-21.4.22/COPYING /usr/share/doc/xemacs-21.4.22/GETTING.GNU.SOFTWARE /usr/share/doc/xemacs-21.4.22/INSTALL /usr/share/doc/xemacs-21.4.22/PROBLEMS /usr/share/doc/xemacs-21.4.22/README /usr/share/doc/xemacs-21.4.22/README.packages /usr/share/doc/xemacs-21.4.22/sample.init.el /usr/share/man/man1/gnuattach.1.gz /usr/share/man/man1/gnuclient.1.gz /usr/share/man/man1/gnudoit.1.gz /usr/share/man/man1/gnuserv.1.gz /usr/share/man/man1/xemacs.1.gz /usr/share/xemacs-21.4.22/etc/aliases.ksh /usr/share/xemacs-21.4.22/etc/BETA /usr/share/xemacs-21.4.22/etc/cbx.png /usr/share/xemacs-21.4.22/etc/CHARSETS /usr/share/xemacs-21.4.22/etc/check_cygwin_setup.sh /usr/share/xemacs-21.4.22/etc/chr.png /usr/share/xemacs-21.4.22/etc/chrm.png /usr/share/xemacs-21.4.22/etc/CODING-STANDARDS /usr/share/xemacs-21.4.22/etc/CODINGS /usr/share/xemacs-21.4.22/etc/COPYING /usr/share/xemacs-21.4.22/etc/COPYING.LIB /usr/share/xemacs-21.4.22/etc/ctags.1 /usr/share/xemacs-21.4.22/etc/custom/check0.xpm /usr/share/xemacs-21.4.22/etc/custom/check1.xpm /usr/share/xemacs-21.4.22/etc/custom/choose-down.png /usr/share/xemacs-21.4.22/etc/custom/choose-up.png /usr/share/xemacs-21.4.22/etc/custom/done-down.png /usr/share/xemacs-21.4.22/etc/custom/done-up.png /usr/share/xemacs-21.4.22/etc/custom/down-pushed.xpm /usr/share/xemacs-21.4.22/etc/custom/down.xpm /usr/share/xemacs-21.4.22/etc/custom/example-themes/europe-theme.el /usr/share/xemacs-21.4.22/etc/custom/example-themes/ex-custom-file /usr/share/xemacs-21.4.22/etc/custom/example-themes/example-theme.el /usr/share/xemacs-21.4.22/etc/custom/face.xpm /usr/share/xemacs-21.4.22/etc/custom/folder.xpm /usr/share/xemacs-21.4.22/etc/custom/open-down.png /usr/share/xemacs-21.4.22/etc/custom/open-up.png /usr/share/xemacs-21.4.22/etc/custom/option.xpm /usr/share/xemacs-21.4.22/etc/custom/radio0.xpm /usr/share/xemacs-21.4.22/etc/custom/radio1.xpm /usr/share/xemacs-21.4.22/etc/custom/reset-down.png /usr/share/xemacs-21.4.22/etc/custom/reset-up.png /usr/share/xemacs-21.4.22/etc/custom/right-pushed.xpm /usr/share/xemacs-21.4.22/etc/custom/right.xpm /usr/share/xemacs-21.4.22/etc/custom/save-down.png /usr/share/xemacs-21.4.22/etc/custom/save-up.png /usr/share/xemacs-21.4.22/etc/custom/set-down.png /usr/share/xemacs-21.4.22/etc/custom/set-up.png /usr/share/xemacs-21.4.22/etc/custom/state-down.png /usr/share/xemacs-21.4.22/etc/custom/state-up.png /usr/share/xemacs-21.4.22/etc/custom/toggle-off-down.png /usr/share/xemacs-21.4.22/etc/custom/toggle-off-up.png /usr/share/xemacs-21.4.22/etc/custom/toggle-on-down.png /usr/share/xemacs-21.4.22/etc/custom/toggle-on-up.png /usr/share/xemacs-21.4.22/etc/DEBUG /usr/share/xemacs-21.4.22/etc/DISTRIB
Re: XEmacs warning
Sorry - I was missing the xemacs-sumo package. Adding that appears to have fixed it. David -- 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: LC_ALL=ru_RU.cp1251 ls -l encoding problem.
Am 06.09.2010 11:07, schrieb Corinna Vinschen: On Sep 5 21:16, Oleksandr Gavenko wrote: As you can see user/group always printed in UTF-8 and discard LC_ALL=cp1251. $ LC_ALL=ru_RU.cp1251 mintty The problem is, what is the encoding of the /etc/passwd file itself? If it's UTF-8, it's UTF-8. If you want to use another encoding throughout, you would have to generate the /etc/passwd and /etc/group files in that other encoding as well. Which is a problem if different users have different locale preferences, and also a problem to configure for non-experts. What about making the functions that access user/group information aware of this, i.e. interpreting the files as UTF-8 and interpreting parameters/results according to current locale? (getpwuid, getpwnam, getlogin, ...) Thomas -- 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: Unable to initialize fd 0 for /dev/tty1
On 9/6/2010 11:45 PM, Eric Berge wrote: Ryan Johnson wrote: The last couple days I've gotten some really strange errors. Sometimes I'll alt-tab to an xterm window and start typing, only to have it disappear at the first keystroke. Sometimes `emacs -nw' will get hit instead, leaving both emacs and the xterm pretty much unusable. I saw these errors with cygwin 1.7.5 but they were fixed when I went to 1.7.6. If you're on 1.7.5 you might want to try upgrading. I'm on 1.7.7-19. Ryan -- 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: Fw: Hello, I need help with PHP compiling and/or how to get PCTNL extension working under cygwin
On 9/6/2010 1:50 PM, Linux User wrote: ... So I decided to try to compile the newest version of PHP available, epic failure because apparently, PHP ./configure doesn't support autoconf 2.65, only 2.13 which isn't available in the repos... I see it. Pick the autoconf2.1 package. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Unable to initialize fd 0 for /dev/tty1
On Mon, Sep 6, 2010 at 5:34 PM, Ryan Johnson ryanj...@ece.cmu.edu wrote: Has anyone seen this before? It happens just often enough to be really Yes, with gitk: http://cygwin.com/ml/cygwin/2010-09/msg00037.html -David -- David Eisner http://cradle.brokenglass.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
cygwin-1.7.7-1 setup.exe errors and cygwin.bat/bash anomalies
I get quite unique experiences with the new update. First, it didn't like to fulfill the dependencies, though it did state they were needed. To somewhat explain what I mean, I would do the very basic install and it would say that some files are required, but wouldn't install'em. Some reason, that's gone, but it's nicer-but-still-evil brother is here. This time around the new setup.exe continues after saying there is an abnormal exit code -6, where as the other brother just said eff you and exited. The truely unique portion is yet to come! The nicer-but-still-evil brother likes to fart around with the directory it starts in when I change directories in Double Commander (open source Total Commander). This never happened in the earlier version of Cygwin. To explain this, I open one tab to Cygwin and before I run the startup batch script, I could change to another tab and maybe get some music playing, then go back to Cygwin and run the batch script; volia! I now start in the folder with the music. Happens all the time. On the same point, in the earlier version of Cygwin my changes still started me in the home directory, but now if I just open Cygwin (instead of changing directories) I'm in the root folder. Not a big deal, but still out of the norm! Now time for how I go about choosing my options from setup.exe because I know you all would like'em; install from internet - ...Desktop\cygwin\cygwin-x with All Users - ...Desktop\cygwin\cygwin_local - Direct Connection - ftp://mirrors.kernel.org - ALL BASIC, NOTHING DONE HERE - detects error, but click to continue. That's all I did. I would like to know if anybody has/had a similar problem before I (figure out how to send a) bug report. Thank you, have a nice day. -- 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: LC_ALL=ru_RU.cp1251 ls -l encoding problem.
On 6 September 2010 21:25, Thomas Wolff wrote: Am 06.09.2010 11:07, schrieb Corinna Vinschen: On Sep 5 21:16, Oleksandr Gavenko wrote: As you can see user/group always printed in UTF-8 and discard LC_ALL=cp1251. $ LC_ALL=ru_RU.cp1251 mintty The problem is, what is the encoding of the /etc/passwd file itself? If it's UTF-8, it's UTF-8. If you want to use another encoding throughout, you would have to generate the /etc/passwd and /etc/group files in that other encoding as well. Which is a problem if different users have different locale preferences, and also a problem to configure for non-experts. True, but you'd get the same problem on Linux, i.e. it's basically assumed that the same encoding is used across the whole system (and UTF-8 is the only sensible choice for that, except in limited circumstances). That doesn't need to stop Cygwin from doing better, though, as of course it does with filenames already. What about making the functions that access user/group information aware of this, i.e. interpreting the files as UTF-8 and interpreting parameters/results according to current locale? (getpwuid, getpwnam, getlogin, ...) Makes sense, me thinks. 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: cygwin-1.7.7-1 setup.exe errors and cygwin.bat/bash anomalies
On 7 September 2010 03:23, Monte Cabet wrote: I get quite unique experiences with the new update. First, it didn't like to fulfill the dependencies, though it did state they were needed. To somewhat explain what I mean, I would do the very basic install and it would say that some files are required, but wouldn't install'em. Some reason, that's gone, but it's nicer-but-still-evil brother is here. This time around the new setup.exe continues after saying there is an abnormal exit code -6, where as the other brother just said eff you and exited. The truely unique portion is yet to come! The nicer-but-still-evil brother likes to fart around with the directory it starts in when I change directories in Double Commander (open source Total Commander). This never happened in the earlier version of Cygwin. To explain this, I open one tab to Cygwin and before I run the startup batch script, I could change to another tab and maybe get some music playing, then go back to Cygwin and run the batch script; volia! I now start in the folder with the music. Happens all the time. On the same point, in the earlier version of Cygwin my changes still started me in the home directory, but now if I just open Cygwin (instead of changing directories) I'm in the root folder. Not a big deal, but still out of the norm! Now time for how I go about choosing my options from setup.exe because I know you all would like'em; install from internet - ...Desktop\cygwin\cygwin-x with All Users - ...Desktop\cygwin\cygwin_local - Direct Connection - ftp://mirrors.kernel.org - ALL BASIC, NOTHING DONE HERE - detects error, but click to continue. That's all I did. I would like to know if anybody has/had a similar problem before I (figure out how to send a) bug report. Thank you, have a nice day. I couldn't make any sense of that. Please read this: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html 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: Cygwin slow on x64 systems
On Thu, Sep 02, 2010 at 01:10:56AM -0400, Christopher Faylor wrote: On Wed, Sep 01, 2010 at 10:28:35PM -0500, Yaakov (Cygwin/X) wrote: On Wed, 2010-09-01 at 17:20 -0400, Christopher Faylor wrote: On Wed, Sep 01, 2010 at 03:19:15PM -0500, Heath Kehoe wrote: If I put the original cygwin1.dll (1.7.7) back, everything works again. I also have sources, and built the latest from CVS, and that cygwin1.dll fails in the same way. Sorry about that. It should be fixed now. http://cygwin.com/snapshots/ Services refuse to start with the 20100901 snapshot. fork() does seem to be faster, though (Win7 x64 RTM). sshd WJFFM, on XP at least. ...but I can duplicated it on Vista 64. I'll fix it tomorrow. cgf -- 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
