Re: [ITP] mingw-w64 Second try
On 8/25/2010 12:19 AM, JonY wrote:
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Here are the packages.
Overall comments: I see you reverted to bundling the DLLs with the
compiler packages (e.g. no separate mingw64-x86_64-libfoo-* tarballs).
While it isn't the way I would do it, that's your choice as maintainer
(and Yaakov would agree with you, not me).
Many of the setup.hint's specify
requires: mingw64-x86_64-gcc
I *think* that should be
requires: mingw64-x86_64-gcc-core.
You don't actually HAVE a 'mingw64-x86_64-gcc' package, except for the
source-only one. And I'm sure you don't mean to require everybody to
install the source code...
mingw64-x86_64-pthreads
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1-src.tar.bz2/download
OK, and rebuilds fine from source.
mingw64-x86_64-headers
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1.tar.bz2/download
Rebuilds fine from source (*), but the binary tarball above is not ok.
It has the headers in the following directory:
usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/
instead of
usr/x86_64-w64-mingw32/sys-root/mingw/include/
Now, if I *rebuild*, the binary tarball generated has the headers in the
correct spot; I think you just uploaded an old version.
mingw64-x86_64-runtime
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1-src.tar.bz2/download
OK, and rebuilds fine from source (*).
mingw64-x86_64-binutils
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1.tar.bz2/download
OK, and rebuilds fine from source.
mingw64-x86_64-gcc-*
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-fortran/mingw64-x86_64-gcc-fortran-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-core/mingw64-x86_64-gcc-core-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-g%2B%2B/mingw64-x86_64-gcc-g%2B%2B-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-ada/mingw64-x86_64-gcc-ada-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-objc/mingw64-x86_64-gcc-objc-4.5.1-1.tar.bz2/download
OK, and (mostly) rebuilds fine from source. I had to comment out the Ada
parts. Even though I had gcc4-ada-4.3.4 installed, rebuilding your
package with Ada enabled failed. However, I've *never* tried to build
Ada before, so it may be that I'm missing some pre-requisite.
Or does building gcc-4.5.x Ada require a newer native Ada compiler than
4.3.4?
(*) I notice that both the -headers and -runtime cygport included this
line as the final command in src_install:
mv ${D}${CROSS_PREFIX}/${CROSS_HOST}/* ${D}${CROSS_PREFIX}
I see the same thing when I tried to use my old mingw*-zlib cygport; I
think the problem is in cygport(1), and your cygport(5) is just working
around the issue.
To sum up, assuming the Ada thing has a reasonable explanation, and the
setup.hints are fixed, I think this is GTG.
If you want to hold off and see what Yaakov does about the issue below,
and maybe revise your cygport(5)'s based on a new release of cygport(1),
that's up to you.
== POSSIBLE CYGPORT(1) BUG =
Yaakov?
the config.status for includedir has this:
S[includedir]=${prefix}/include
but other dirs are explicit:
S[bindir]=/usr/x86_64-w64-mingw32/sys-root/mingw/bin
Looking at the configure command (from config.status):
'/usr/src/mingw64/headers/mingw64-x86_64-headers-svn3433-1/src/mingw-w64-headers/configure'
'--srcdir=/usr/src/mingw64/headers/mingw64-x86_64-headers-svn3433-1/src/mingw-w64-headers'
'--prefix=/usr/x86_64-w64-mingw32/sys-root/mingw'
'--exec-prefix=/usr/x86_64-w64-mingw32/sys-root/mingw'
'--bindir=/usr/x86_64-w64-mingw32/sys-root/mingw/bin'
[ITP] mscgen 0.18
Hi, Mscgen is a message sequence chart rendering tool. It can be used standalone or with Doxygen to help document call flows and is licensed under the GPL. It's already packaged with Ubuntu: http://packages.ubuntu.com/maverick/mscgen http://packages.ubuntu.com/lucid/mscgen Mscgen builds out of the box on Cygwin and uses cygport for packaging. The files are here: wget -x -nd -P mscgen \ http://mcternan.me.uk/mscgen/cygwin-1.7/mscgen-0.18-1-src.tar.bz2 \ http://mcternan.me.uk/mscgen/cygwin-1.7/mscgen-0.18-1.tar.bz2 \ http://mcternan.me.uk/mscgen/cygwin-1.7/setup.hint Setup.hint looks like this: category: Graphics requires: libgd2 sdesc: A Message Sequence Chart Renderer ldesc: A Message Sequence Chart Renderer. This is my first Cygwin package, I hope I have it correct. Kind Regards, Mike
Possible cygport bug with cross compiles
Originally posted in
http://cygwin.com/ml/cygwin-apps/2010-08/msg00213.html
but I figure it needs its own thread.
When testing JonY's mingw64 compiler, I found that often the include
files ended up in the wrong directory. Also, JonY apparently did as
well, since his cygport(5)'s included this bit in src_install():
mv ${D}${CROSS_PREFIX}/${CROSS_HOST}/* ${D}${CROSS_PREFIX}
Looking a little more closely, the config.status for includedir has this:
S[includedir]=${prefix}/include
but other dirs are explicit:
S[bindir]=/usr/x86_64-w64-mingw32/sys-root/mingw/bin
Looking at the configure command (from config.status):
'/usr/src/mingw64/headers/mingw64-x86_64-headers-svn3433-1/src/mingw-w64-headers/configure'
'--srcdir=/usr/src/mingw64/headers/mingw64-x86_64-headers-svn3433-1/src/mingw-w64-headers'
'--prefix=/usr/x86_64-w64-mingw32/sys-root/mingw'
'--exec-prefix=/usr/x86_64-w64-mingw32/sys-root/mingw'
'--bindir=/usr/x86_64-w64-mingw32/sys-root/mingw/bin'
'--sbindir=/usr/x86_64-w64-mingw32/sys-root/mingw/sbin'
'--libexecdir=/usr/x86_64-w64-mingw32/sys-root/mingw/lib'
'--datadir=/usr/x86_64-w64-mingw32/sys-root/mingw/share'
'--localstatedir=/usr/x86_64-w64-mingw32/sys-root/mingw/var'
'--sysconfdir=/usr/x86_64-w64-mingw32/sys-root/mingw/etc'
'--datarootdir=/usr/x86_64-w64-mingw32/sys-root/mingw/share'
'--docdir=/usr/x86_64-w64-mingw32/sys-root/mingw/share/doc/mingw64-x86_64-headers'
'-C' '--build=i686-pc-cygwin' '--host=x86_64-w64-mingw32'
'--target=x86_64-w64-mingw32' '--enable-sdk=all'
'build_alias=i686-pc-cygwin' 'host_alias=x86_64-w64-mingw32'
'target_alias=x86_64-w64-mingw32' $ac_configure_extra_args --no-create
--no-recursion
I see that --includedir is missing. I think that is an oversight in
autotools.cygclass, and --includedir should be one of the elements
specified in confargs:
confargs=--prefix=${prefix} --exec-prefix=${prefix}
--bindir=${prefix}/bin \
--sbindir=${prefix}/sbin --libexecdir=${prefix}/lib \
--datadir=${prefix}/share --localstatedir=${prefix%/usr}/var \
--sysconfdir=${prefix%/usr}/etc
I'm not real sure about the ${prefix%/...} manipulation, either,
especially for cross. (The effect of this manipulation for a cross for
$host=mingw is not apparent, since $prefix doesn't actually end in /usr
in that case). But...the current code seems to be incorrect, IMO.
In a related issue, I happened to notice there is a bug in cyginstall()
when USE_DESTDIR=0, inherit cross, and $host is mingw: localstatedir
(/var) and sysconfdir (/etc) aren't handled correctly.
--
Chuck
Re: [ITP] mingw-w64 Second try
On 9/1/2010 03:32, Charles Wilson wrote:
On 8/25/2010 12:19 AM, JonY wrote:
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Here are the packages.
Overall comments: I see you reverted to bundling the DLLs with the
compiler packages (e.g. no separate mingw64-x86_64-libfoo-* tarballs).
While it isn't the way I would do it, that's your choice as maintainer
(and Yaakov would agree with you, not me).
Many of the setup.hint's specify
requires: mingw64-x86_64-gcc
I *think* that should be
requires: mingw64-x86_64-gcc-core.
You don't actually HAVE a 'mingw64-x86_64-gcc' package, except for the
source-only one. And I'm sure you don't mean to require everybody to
install the source code...
Sorry, I was recycling setup.hint from earlier tries. I will fix this.
mingw64-x86_64-pthreads
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1-src.tar.bz2/download
OK, and rebuilds fine from source.
mingw64-x86_64-headers
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1.tar.bz2/download
Rebuilds fine from source (*), but the binary tarball above is not ok.
It has the headers in the following directory:
usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/
instead of
usr/x86_64-w64-mingw32/sys-root/mingw/include/
Now, if I *rebuild*, the binary tarball generated has the headers in the
correct spot; I think you just uploaded an old version.
Strange, I'll try a rebuild. The former should be the correct location.
mingw64-x86_64-runtime
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1-src.tar.bz2/download
OK, and rebuilds fine from source (*).
mingw64-x86_64-binutils
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1.tar.bz2/download
OK, and rebuilds fine from source.
mingw64-x86_64-gcc-*
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-fortran/mingw64-x86_64-gcc-fortran-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-core/mingw64-x86_64-gcc-core-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-g%2B%2B/mingw64-x86_64-gcc-g%2B%2B-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-ada/mingw64-x86_64-gcc-ada-4.5.1-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-objc/mingw64-x86_64-gcc-objc-4.5.1-1.tar.bz2/download
OK, and (mostly) rebuilds fine from source. I had to comment out the Ada
parts. Even though I had gcc4-ada-4.3.4 installed, rebuilding your
package with Ada enabled failed. However, I've *never* tried to build
Ada before, so it may be that I'm missing some pre-requisite.
Or does building gcc-4.5.x Ada require a newer native Ada compiler than
4.3.4?
I installed gcc 4.5.x from experimental for this purpose. The GCC docs
say to have a native ada compiler of the same version installed first.
GCC 4.5.0 and 4.5.1 should be close enough.
(*) I notice that both the -headers and -runtime cygport included this
line as the final command in src_install:
mv ${D}${CROSS_PREFIX}/${CROSS_HOST}/* ${D}${CROSS_PREFIX}
I see the same thing when I tried to use my old mingw*-zlib cygport; I
think the problem is in cygport(1), and your cygport(5) is just working
around the issue.
To sum up, assuming the Ada thing has a reasonable explanation, and the
setup.hints are fixed, I think this is GTG.
If you want to hold off and see what Yaakov does about the issue below,
and maybe revise your cygport(5)'s based on a new release of cygport(1),
that's up to you.
OK, my cygport was mostly from Yaakov's examples.
== POSSIBLE CYGPORT(1) BUG =
Yaakov?
the config.status for includedir has this:
S[includedir]=${prefix}/include
but other dirs are explicit:
S[bindir]=/usr/x86_64-w64-mingw32/sys-root/mingw/bin
Looking at the
Re: [ITP] mingw-w64 Second try
On 8/31/2010 8:52 PM, JonY wrote: On 9/1/2010 03:32, Charles Wilson wrote: Rebuilds fine from source (*), but the binary tarball above is not ok. It has the headers in the following directory: usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ instead of usr/x86_64-w64-mingw32/sys-root/mingw/include/ Now, if I *rebuild*, the binary tarball generated has the headers in the correct spot; I think you just uploaded an old version. Strange, I'll try a rebuild. The former should be the correct location. Errr...no. The *latter* is the correct location (at least, that's where the sysroot'ed compiler will look for them). the (buggy) cygport(1) puts them in usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ but we really want them to be in usr/x86_64-w64-mingw32/sys-root/mingw/include/ which is what your cygport(5) does -- when you actually use it to rebuild. Or does building gcc-4.5.x Ada require a newer native Ada compiler than 4.3.4? I installed gcc 4.5.x from experimental for this purpose. The GCC docs say to have a native ada compiler of the same version installed first. GCC 4.5.0 and 4.5.1 should be close enough. Oh, I did not know that; I figured any old Ada would do. OK... To sum up, assuming the Ada thing has a reasonable explanation, and the setup.hints are fixed, I think this is GTG. If you want to hold off and see what Yaakov does about the issue below, and maybe revise your cygport(5)'s based on a new release of cygport(1), that's up to you. OK, my cygport was mostly from Yaakov's examples. Thanks for your hard work. -- Chuck
Re: [ITP] mingw-w64 Second try
On 9/1/2010 10:28, Charles Wilson wrote: On 8/31/2010 8:52 PM, JonY wrote: On 9/1/2010 03:32, Charles Wilson wrote: Rebuilds fine from source (*), but the binary tarball above is not ok. It has the headers in the following directory: usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ instead of usr/x86_64-w64-mingw32/sys-root/mingw/include/ Now, if I *rebuild*, the binary tarball generated has the headers in the correct spot; I think you just uploaded an old version. Strange, I'll try a rebuild. The former should be the correct location. Errr...no. The *latter* is the correct location (at least, that's where the sysroot'ed compiler will look for them). the (buggy) cygport(1) puts them in usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ but we really want them to be in usr/x86_64-w64-mingw32/sys-root/mingw/include/ which is what your cygport(5) does -- when you actually use it to rebuild. Right, the latter is correct. I'm misreading it.
Re: Possible cygport bug with cross compiles
On Tue, 2010-08-31 at 17:34 -0400, Charles Wilson wrote:
When testing JonY's mingw64 compiler, I found that often the include
files ended up in the wrong directory.
Often?
Also, JonY apparently did as well, since his cygport(5)'s
Which were likely borrowed from mine...
included this bit in src_install():
mv ${D}${CROSS_PREFIX}/${CROSS_HOST}/* ${D}${CROSS_PREFIX}
The reason for that is the *upstream* mingw-w64 Makefiles install to
$prefix/$host/{include,lib}, based on the pre-sysroot convention; so if
we want to use the sysroot for *everything*, including the system
headers, then they end up in $CROSS_PREFIX/$CROSS_HOST/{include,lib} and
need to be moved thereafter.
IOW this could be seen as an issue with the mingw-w64 sources, not
cygport. OTOH, mingw-w64 is not unique; both newlib and avr-libc are
coded to install into $prefix/$host/{include,lib}; glibc and mingw.org
install correctly into sysroot OOTB. A possible solution is to
reconsider to what degree we use the sysroot.
I'm not real sure about the ${prefix%/...} manipulation, either,
especially for cross. (The effect of this manipulation for a cross for
$host=mingw is not apparent, since $prefix doesn't actually end in /usr
in that case). But...the current code seems to be incorrect, IMO.
The point is that (per FHS) if prefix=/usr, then sysconfdir=/etc
(NOT /usr/etc) and localstatedir=/var (NOT /usr/var), However, if
prefix != /usr (e.g. /mingw), then these should also go under the prefix
(/mingw/etc and /mingw/var). The same goes for cyginstall.
Yaakov
Re: changing font
Yes, it displays the font but it does not set the font. Only the 'quit' button works. On Mon, Aug 30, 2010 at 4:22 PM, Thomas Dickey dic...@his.com wrote: On Mon, 30 Aug 2010, matias kaukonen wrote: The above worked on my previous computer, but now it does not work with my current computer. This is what I tried: 1. a) Added XTerm[.*]vt100.font:lucidasanstypewriter-10 to .Xdefaults b) typed: xrdb ~/.Xdefaults; xrdb ~/.Xresources next, 2. a) Added XTerm[.*]vt100.font:lucidasanstypewriter-10 to .Xresources b) typed: xrdb ~/.Xdefaults; xrdb ~/.Xresources But neither one affected the xterm font. does xfd -fn lucidasanstypewriter-10 display the font you asked for? -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- 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/ -- 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 12/08/2010 17:07, Jon TURNEY wrote: On 12/08/2010 16:49, Ryan Johnson wrote: On 8/12/2010 5:46 PM, Jon TURNEY wrote: On 10/08/2010 06:48, Ryan Johnson wrote: On 8/10/2010 12:02 AM, Jon TURNEY wrote: On 09/08/2010 22:14, Ryan Johnson wrote: When I detached the monitor to leave the office, X disappeared with signal 11 (log attached). Oddly, the log file didn't mention -resize as an argument to XWin, but it did attempt to resize so I assume the feature was active. Oh dear. Well it seems I only thought I added code to only enable resize support in multiwindow mode when requested, so it's always on for multiwindow mode at the moment. That wouldn't be so bad, but it also seems that the -resize code completely fails to correctly handle a change of colour depth (e.g. from 32 bits to 16 bits or vice versa) leading to this segfault. Unfortunately, fixing this looks to be quite complex :-( Thanks for testing, anyhow :-) So... does that mean I have to roll back or face a seg fault after every commute? Or is there a way to explicitly disable it? I'm afraid so. As I say, I meant to add a means to disable -resize in -multiwindow mode to avoid exactly this kind of situation. Since it's the transition from 32bpp to 16bpp which breaks this, one possible workaround would be to run your large monitor at 16bpp, which might also give you working resize. 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 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: xwin -multiwindow puts glass pane over windows taskbar
On 16/08/2010 11:57, Ryan Johnson wrote: The latest versions of the X server put a glass pane over the windows taskbar -- you have to click on it and then wait several seconds before it responds and gets out of the way. This seems related to the previous problem of generally slow response to key presses... Has anyone else run into this? I don't see any behaviour like that, and I can't really visualize what you are describing. Can you upload some screenshots somewhere? Facts which might be relevant: - do you have the taskbar set to autohide? - what version of Windows are you using? - is this the same problem as you mentioned at [1]? [1] http://cygwin.com/ml/cygwin-xfree/2010-08/msg00011.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: xwin -multiwindow puts glass pane over windows taskbar
On 8/31/2010 7:06 PM, Jon TURNEY wrote: On 16/08/2010 11:57, Ryan Johnson wrote: The latest versions of the X server put a glass pane over the windows taskbar -- you have to click on it and then wait several seconds before it responds and gets out of the way. This seems related to the previous problem of generally slow response to key presses... Has anyone else run into this? I don't see any behaviour like that, and I can't really visualize what you are describing. Can you upload some screenshots somewhere? Facts which might be relevant: - do you have the taskbar set to autohide? - what version of Windows are you using? - is this the same problem as you mentioned at [1]? [1] http://cygwin.com/ml/cygwin-xfree/2010-08/msg00011.html Sorry my description was so vague. It is indeed the same problem as in [1] (I thought maybe the other had gotten lost in the shuffle and reposted it). Basically, you know how the previous bug would make X apps unresponsive to key presses and mouse events until you did an alt-tab to wake them? Now I never get that any more but I get virtually the same behavior with my XP Pro non-autohide task bar, which is docked on the left side of my screen. If I mouse over systray icons, the tooltips don't appear. Mousing over the window entries doesn't make them highlight. Clicking on a window's entry or the 'start' button does nothing. It really is like something invisible sits over the whole area and intercepts all mouse events. The behavior continues for around 5 seconds or until I alt-tab some other window to foreground (whichever comes first). This doesn't always happen, and it only happens when an X window is in the foreground. 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/
src/winsup/cygwin ChangeLog include/cygwin/ver ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-31 07:47:51 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/include/cygwin: version.h Log message: * include/cygwin/version.h: Bump DLL minor version number to 7. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5017r2=1.5018 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/version.h.diff?cvsroot=srcr1=1.324r2=1.325
src/winsup/cygwin ChangeLog path.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-31 13:48:04 Modified files: winsup/cygwin : ChangeLog path.cc Log message: * path.cc (normalize_posix_path): Preserve //./ and //?/ prefixes. (path_conv::check): Allow access to root directory of native NT disk devices. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5018r2=1.5019 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.604r2=1.605
Re: Cygwin slow on x64 systems
Hi Sagi and all others, Thanks Sagi for your investigation! This is great news that it could finally be tracked down. I am also suffering badly here from this speed drop. I haven't yet tried myself to revert this change to see whether it brings back speed but will certainly try to do so soon. What are our cygwin gurus (CGF,Corinna,?) saying about this? Can the results of these investigations be incorporated in a change in an upcoming version to get a more performant cygwin version? I know that in 1.7 codebase a lot has changed so it might not be that easy to transport these results to the current version. Beside of the fork problems the speed drop is (in my eyes) the other big problem of cygwin on x64. Thanks in advance, Roland, hoping that this problem gets cured soon -- 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: Building Mutt: configure: invalid value of canonical build
On Mon, Aug 30, 2010 at 11:52 PM, Michael Ludwig wrote: It is only after receiving an error because of the script's failure to guess the build system that I added the --build option to configure. But obviously I didn't fill in a correct value. What should I try? Try: i686-pc-cygwin This is what gcc -v reports. -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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: setup.exe crashes when downgrading gcc4
On Tue, Aug 31 2010, Andy Koppe wrote: The Bochum http mirror works fine for me, but the ftp one just stops during the download of setup.bz2, so it seems something's not right with that server. Which one were you using? The http server. Regarding the crash, I can only guess that the Bochum mirror's subdirectory in your Cygwin download directory had somehow got into an inconsistent state. Of course that shouldn't cause a crash, but if you do want to use that mirror again you could try deleting its subdirectory. Ok, thanks. If you do see the crash again, sending /var/log/setup.log.full may be helpful too. I've - deleted /var/log/setup.log* - switched back to Bochum - uninstalled some packages - /var/log/setup.log* have been created - tried to install gcc4-core - crash - /var/log/setup.log* files have not been modified since creation... Nevertheless, I attach the 2 files. Last step: I've deleted the *gcc* sub-directories in the cygwin download area for Bochum, and indeed, there is no more crash. Thanks! Peter -- Contact information: http://pmrb.free.fr/contact/ 2010/08/31 09:36:31 Starting cygwin install, version 2.721 2010/08/31 09:36:31 io_stream_cygfile: fopen(/etc/setup/net-proxy-host) failed 2 No such file or directory 2010/08/31 09:36:31 io_stream_cygfile: fopen(/etc/setup/net-proxy-port) failed 2 No such file or directory 2010/08/31 09:36:31 io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No such file or directory 2010/08/31 09:36:31 io_stream_cygfile: fopen(/etc/setup/chooser_window_settings) failed 2 No such file or directory 2010/08/31 09:36:31 Current Directory: C:\Temp\cygwin 2010/08/31 09:36:31 User has backup/restore rights 2010/08/31 09:36:31 Changing gid to Administrators 2010/08/31 09:36:31 Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. 2010/08/31 09:36:42 source: network install 2010/08/31 09:36:43 root: C:\cygwin binary system 2010/08/31 09:36:44 Selected local directory: C:\Temp\cygwin 2010/08/31 09:36:45 net: IE5 2010/08/31 09:36:47 site: http://linux.rz.ruhr-uni-bochum.de/download/cygwin/ 2010/08/31 09:38:09 Adding required dependency gcc-mingw-core: Selecting version 20050522-1 for installation. 2010/08/31 09:38:17 Extracting from file://C:\Temp\cygwin/http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%2fcygwin%2f/release/gcc/gcc-core/gcc-core-3.4.4-999.tar.bz2 2010/08/31 09:38:20 Extracting from file://C:\Temp\cygwin/http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%2fcygwin%2f/release/gcc-mingw/gcc-mingw-core/gcc-mingw-core-20050522-1.tar.bz2 2010/08/31 09:38:20 Changing gid back to original 2010/08/31 09:38:24 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/gcc-mingw-core.sh 2010/08/31 09:38:25 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/gcc.sh 2010/08/31 09:38:25 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libglade2.0.sh 2010/08/31 09:38:26 abnormal exit: exit code=2 2010/08/31 09:38:26 Changing gid to Administrators 2010/08/31 09:38:30 note: Installation Complete 2010/08/31 09:38:30 Ending cygwin install 2010/08/31 09:36:31 Starting cygwin install, version 2.721 2010/08/31 09:36:31 io_stream_cygfile: fopen(/etc/setup/net-proxy-host) failed 2 No such file or directory 2010/08/31 09:36:31 io_stream_cygfile: fopen(/etc/setup/net-proxy-port) failed 2 No such file or directory 2010/08/31 09:36:31 io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No such file or directory 2010/08/31 09:36:31 io_stream_cygfile: fopen(/etc/setup/chooser_window_settings) failed 2 No such file or directory 2010/08/31 09:36:31 Current Directory: C:\Temp\cygwin 2010/08/31 09:36:31 User has backup/restore rights 2010/08/31 09:36:31 Changing gid to Administrators 2010/08/31 09:36:31 Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. 2010/08/31 09:36:42 source: network install 2010/08/31 09:36:43 root: C:\cygwin binary system 2010/08/31 09:36:44 Selected local directory: C:\Temp\cygwin 2010/08/31 09:36:45 net: IE5 Loaded cached mirror list get_url_to_membuf http://cygwin.com/mirrors.lst getUrlToStream http://cygwin.com/mirrors.lst 2010/08/31 09:36:47 site: http://linux.rz.ruhr-uni-bochum.de/download/cygwin/ get_url_to_membuf http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup.bz2 getUrlToStream http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup.bz2 get_url_to_membuf http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup.bz2.sig getUrlToStream http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup.bz2.sig 2010/08/31 09:38:09 Adding required dependency gcc-mingw-core: Selecting version 20050522-1 for installation. Checking MD5 for file://C:\Temp\cygwin/http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%2fcygwin%2f/release/gcc/gcc-core/gcc-core-3.4.4-999.tar.bz2 MD5 verified OK:
[ANNOUNCEMENT] Updated: cygwin-1.7.7-1
Hi Cygwin friends and users, I just released 1.7.7-1. This release fixes a bunch of bugs, some of them freshly introduced with 1.7.6. It also introduces a very few number of new features. Most notably it partially reverts a backward incompatibility which affects Cygwin applications which also call native Win32 functions to do part of their job. Unfortunately this goes hand in hand with a regression, kind of. So far it was possible in Cygwin 1.7.x to remove a directory which was the current working directory (CWD) of another Cygwin process, or even the CWD of the process itself. This Linux-like feature had to be dropped, because the implementation could result in strange handle problems on Vista and later, and the workaround in 1.7.6 introduced more problems than anticipated. So we're back to Win32-like behaviour, which is, rmdir returns with Device or resource busy when trying to remove a directory which is CWD of a Cygwin process. Fortunately this behaviour is covered and explicitely allowed by the POSIX standard, so we're still on firm ground, standards-wise. I think this goes without saying, but please have another look into the documentation at http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html. It contains a couple of improvements and the description for new features and changes from old behaviour. What's new since Cygwin 1.7.6: == - Make sure to follow the Microsoft security advisory concerning DLL hijacking. http://www.microsoft.com/technet/security/advisory/2269637.mspx - Allow to link against -lbinmode instead of /lib/binmode.o. Same for -ltextmode, -ltextreadmode and -lautomode. See http://cygwin.com/cygwin-ug-net/using-textbinary.html#textbin-devel - BSD macros in endian.h (htobe16, le32toh, etc). What changed since Cygwin 1.7.6: - Partially revert the 1.7.6 change to set the Win32 current working directory (CWD) always to an invalid directory, since it breaks backward compatibility too much. See the reworked http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api - A crash in a virtual directory (/proc, /cygdrive, //) does not produce a stackdump file in some unrelated directory anymore. - Improve d_type info in dirent structure. - /proc/partitions now prints entire partition layout also for non-privileged users. - cygcheck now prefers the \\?\X: DOS device name over every other available device name for a harddisk. Bugfixes since Cygwin 1.7.6: - Avoid accidental usage of buggy newlib version of wcsncpy. - Set st_rdev stat member for filesystem-based device nodes correctly. - Fix bug in statvfs et al. which returned incorrect information for volume mount points. - Close handle leak when following symlinks. - Fix problem with mount options when using the mount(1) command to create new, session-temporary mount points. - Workaround a bug in Tru64 filesystems. - Fix long-standing problem that calling select(2) on /dev/windows hangs for timeout, if no new messages arrived in the message queue since the last call to select. - Fix pathname problem in ldd. Have fun, Corinna *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://cygwin.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:cygwin@cygwin.com Red Hat, Inc. -- 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
Gentoo Prefix on Cygwin
Hello Cygwin community! I try to install Gentoo Prefix onto Cygwin. My goal is to get a second level administration tool, that I can run on Mac, Windows and Linux from the userspace. This way I can customize the environment for any software project in a platform independent way. That is especially usefull for projects that depend on multiple tools. While a single tool is often platform independent (java), the whole stack often is not. At least you need to install different types of binaries. That results in an overhead of organization for typical projects. My approach is to automatically compile from the same sources instead. The Gentoo Prefix sources are platform independent. Meanwhile I spend a week of research. If you are interested in my results you will always find the current status here: http://en.gentoo-wiki.com/wiki/Prefix/Cygwin. As the cygwin project has already solved many issues that I will run into, I will come back with some questions and hope to find advice from Cygwin developers. 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: xfig startup with latest user versions of xfig
On 8/30/2010 9:14 PM, Carl Lund wrote: Hi-- After updating to the latest version of xfig, I got the following error message from xfig when I ran (countr.fig is a new figure I am building): xfig countr.fig -error message The app-defaults file (version: 3.2.4) is older than this version of xfig (3.2.5b). You should install the correct version or you may lose some features. This may be done with make install in the xfig source directory. --- I don't build cygwin routines myself. I assume that the setup routines take care of consistency requirements such as this, so I thought I should send you this note. This is a known (one-time) problem: http://cygwin.com/ml/cygwin-xfree/2010-05/msg00037.html Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin slow on x64 systems
Edward Lam wrote: Just curious, has the performance characteristics of your test changed with the lastest cygwin snapshot? The affected code has moved somewhat since revision 1.288. I ran my test script on version 1.7.6 and on the release from today, i.e. 1.7.7-1, and performance are even worse. I get only 5 lines/second. Sagi. -- Sagi Ben-Akiva - sagi at graphtech dot co dot il GraphTech Computer Systems, www.graphtech.co.il -- 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: Keyboard issue: unresponsive keystroke
Thanks for the response, Eric, it helped me troubleshoot the issue. Seems I never set my HOME environment variable (sigh), so it all ended up in my Windows home directory. Asserting ~/.inputrc did not have DOS line endings didn't have any effect, but removing the file allowed me to type all chars again (that's a relief). The only thing I had in that custom ~/.inputrc were system beep suppression directives, namely: set bell-style no setterm -blength 0 After setting the HOME variable in my .bat file, I recreated .inputrc in vim and everything is fine again. I suspect permissions in the Windows user directory conflicted with Cygwin's installation. Cheers, Éric On Mon, Aug 30, 2010 at 6:58 PM, Eric Blake ebl...@redhat.com wrote: On 08/30/2010 10:52 AM, Eric Vautier wrote: Hello all, I've used the US-International keyboard layout for ages without issues. Recently, I fired cygwin and noticed the s key was unresponsive. Did you check whether ~/.inputrc has DOS line endings? If so, run d2u on it, and see if that fixes things. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org -- 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 Tue, Aug 31, 2010 at 08:32:41AM +0200, Roland Schwingel wrote: Hi Sagi and all others, Thanks Sagi for your investigation! This is great news that it could finally be tracked down. I am also suffering badly here from this speed drop. I haven't yet tried myself to revert this change to see whether it brings back speed but will certainly try to do so soon. What are our cygwin gurus (CGF,Corinna,?) saying about this? Can the results of these investigations be incorporated in a change in an upcoming version to get a more performant cygwin version? Here's what I'm saying: It makes absolutely no sense that moving the call would have any effect. The code is the way it is for a reason so we're not going to just revert the change. 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: Cygwin slow on x64 systems
On 8/31/2010 10:08 AM, Christopher Faylor wrote: Here's what I'm saying: It makes absolutely no sense that moving the call would have any effect. The code is the way it is for a reason so we're not going to just revert the change. I don't think anyone is asking to revert the change. In any case, is it absolutely necessary for us to call wait_for_sigthread() before we do the other initialization in dll_crt0_1() ? ie. can we move it further down? Or perhaps we can reorder the initialization code somewhat such that we can do more work before calling wait_for_sigthread()? Regards, -Edward -- 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 Tue, Aug 31, 2010 at 10:18:39AM -0400, Edward Lam wrote: On 8/31/2010 10:08 AM, Christopher Faylor wrote: Here's what I'm saying: It makes absolutely no sense that moving the call would have any effect. The code is the way it is for a reason so we're not going to just revert the change. I don't think anyone is asking to revert the change. Don't be too sure. I'm sure that is the knee-jerk reaction of many reading the observations. In any case, is it absolutely necessary for us to call wait_for_sigthread() before we do the other initialization in dll_crt0_1() ? ie. can we move it further down? Or perhaps we can reorder the initialization code somewhat such that we can do more work before calling wait_for_sigthread()? If you are capable of building from source then you can answer these questions for yourself. This is not terrifically complicated code we're talking about here. 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: Linking shared libraries problem
Larry Hall (Cygwin) wrote: On 8/29/2010 7:08 PM, Tomás Staig wrote: Hi, I have been trying to port some software from Linux (Scientific Linux/RedHat) to windows using Cygwin. I have been able to port most of it with little changes but I encountered a problem when linking shared libraries. It seems that the chain of dependencies is not included when linking. Furthermore, ldd does not show the dependency libraries as in Linux. I have tried both using the import libraries (%.dll.a) and linking the dll files (%.dll) directly. I have arranged a small example program that reproduces this effect. Used Ubuntu 8.04 to and CYGWIN_NT-5.1 version 1.7.6(0.230/5/3) 2010-08-16 16:06 on top of a 32-bits Windows XP Machine to test the above examples. snip As you can see, there is no reference to liby.dll. I could add the library (-ly) directly to the compiling line of main and it works, but the truth is that it would not be a good approach, since in the software I'm trying to port, there are several dependent modules, so the last ones would have an incredibly large list of dependencies. So, am I doing something wrong? Is there any way to add the dependency to be shown with ldd or any workaround(maybe a linker flag or something) to make the above example work? The Windows loader requires full resolution at link time. You need to list at least the import libraries for all dependencies if you want the link to succeed. Sorry, that's just the way Windows works. Thanks for your reply. I have found a workaround, however. Probably not the best thing to do in general, but for my case it is pretty useful: Makefile in Cygwin: all: g++ -c x.cpp g++ -c y.cpp g++ -shared -Wl,--output-def,liby.def -Wl,-out-implib=liby.dll.a -Wl,-export-all-symbols -Wl,-enable-auto-import -Wl,-whole-archive y.o -Wl,-no-whole-archive -o liby.dll g++ -shared -Wl,-out-implib=libx.dll.a -Wl,-export-all-symbols -Wl,-enable-auto-import -Wl,-whole-archive x.o liby.def -Wl,-no-whole-archive -L./ -ly -o libx.dll g++ -o main main.cpp -L./ -lx If anyone is going to use this, be aware that it might get you multiple definition problems. I still haven't checked how this behaves in the project I'm porting, but in this tiny example it works flawlessly. -- 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
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: Here's what I'm saying: It makes absolutely no sense that moving the call would have any effect. The code is the way it is for a reason so we're not going to just revert the change. I think it makes sense, if the signal thread initialization takes time. Which it does: 69 15954 [main] date 2708 wait_for_sigthread: wait_sig_inited 0x4C 13706 29660 [main] date 2708 wait_for_sigthread: process/signal handling enabled, state 0x41 146 29806 [sig] date 2708 wait_sig: entering ReadFile loop, my_readsig 0xFC, my_sendsig 0x100 The above is a snippet from strace date (with some wrapping by me), using Cygwin 1.7.6 on Vista x64. And 1.7.7 is said to be slower still - and guess what, sigproc_init is called later; see r1.382 of dcrt0.cc. 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: Cygwin slow on x64 systems
On Tue, Aug 31, 2010 at 05:26:24PM +, Magnus Holmgren wrote: Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: Here's what I'm saying: It makes absolutely no sense that moving the call would have any effect. The code is the way it is for a reason so we're not going to just revert the change. I think it makes sense, if the signal thread initialization takes time. Which it does: 69 15954 [main] date 2708 wait_for_sigthread: wait_sig_inited 0x4C 13706 29660 [main] date 2708 wait_for_sigthread: process/signal handling enabled, state 0x41 146 29806 [sig] date 2708 wait_sig: entering ReadFile loop, my_readsig 0xFC, my_sendsig 0x100 The above is a snippet from strace date (with some wrapping by me), using Cygwin 1.7.6 on Vista x64. And 1.7.7 is said to be slower still - and guess what, sigproc_init is called later; see r1.382 of dcrt0.cc. You are using a different value of makes sense. I was not saying Your observations are wrong. If I was saying that then yes, you would not be making sense. Yes, if a function takes longer than you want it to, then it will cause things to be slow. That does make sense but it is basically a tautology. I am saying that looking at the code, it does not make sense that it would take longer. It especially does not make any sense given the fact that the signal thread does not get started until well after dll_crt0_0 has exited, so, moving the sigproc_init should not cause any difference in behavior. And, you really haven't proved that it does since you are checking the difference between 1.7.6 and 1.7.7 and there have been many changes between those two. 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
scp and cygwin randomly and automatically converts text files from utf-8 to windows encoding (cp1251)
It happens when files are copied from cygwin windows machines to any linux (tried different versions of ubuntu and gentoo with utf-8 locale). As it is not possible to understand in what cases are re-encoding, sometimes enough to add one blank line in a text file that, when the transfer encoding has not happened. Just changing the format of a newline (in the source files are unix-style \n, but on the linux machine has come to win-style \r\n) Sorry for my english - google translate. -- View this message in context: http://old.nabble.com/scp-and-cygwin-randomly-and-automatically-converts-text-files-from-utf-8-to-windows-encoding-%28cp1251%29-tp29586716p29586716.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin slow on x64 systems
Sagi Ben-Akiva sagi at graphtech.co.il writes: For the last couple of weeks I'm trying to identify the cause for cygwin slowdown on x64 machines which was reported by David Morgan about 6 months ago. ... Any help will be appreciated. I did some testing on my 64-bit Vista system, and it appears that CreateThread is the main cause. I added a few traces, and got this: $ strace --mask=thread,sigp date 149 149 [main] date 2944 cygthread::create: name ... 159 308 [main] date 2944 cygthread::create: created name ... 62416549 [main] date 2944 wait_for_sigthread: wait_sig_inited 0xB0 23606 30155 [sig] date 2944 cygthread::stub: cygthread::stub enter 111 30266 [sig] date 2944 cygthread::stub: cygthread::stub callfunc 65 30331 [sig] date 2944 cygthread::callfunc: wait for 'h' 59 30390 [sig] date 2944 cygthread::callfunc: func 65 30455 [sig] date 2944 init_sig_pipe: enter 5343 35798 [sig] date 2944 init_sig_pipe: create pipe 134 35932 [sig] date 2944 init_sig_pipe: exit 72 36004 [sig] date 2944 wait_sig: entering ReadFile loop ... 4 36008 [main] date 2944 wait_for_sigthread: process/signal ... The second trace line is printed after CreateThread has returned, and the fourth line is the first thing executed in the new thread (don't know if it is a good idea to trace that early in the thread, but...). 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
[ANNOUNCEMENT] Updated: m4-1.4.15-1
A new release of m4, 1.4.15-1, is available for download, leaving 1.4.14-1 as previous. NEWS This is a new upstream release, with upstream NEWS attached. See also /usr/share/doc/m4/. You must rebuild from source if you want the experimental changeword feature enabled, as using it can slow down normal operation, and since it will disappear from the eventual m4 2.0. DESCRIPTION === m4 is an implementation of the traditional Unix macro processor. It is mostly SVR4 compatible although it has some extensions (for example, handling more than 9 positional parameters to macros). GNU m4 also has built-in functions for including files, running shell commands, doing arithmetic, etc. UPDATE == To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'm4' from the 'Interpreters' category. DOWNLOAD: = Note that downloads from cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin m4 maintainer CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. * Noteworthy changes in release 1.4.15 (2010-08-31) [stable] ** Fix regression introduced in 1.4.9b where the `format' builtin could crash on an invalid format string. ** Fix compilation against newer glibc, and on AIX 7.1BETA. ** A number of portability improvements inherited from gnulib. signature.asc Description: OpenPGP digital signature
Cygwin for windows 7
Hello, I just downloaded and installed the new cygwin for windows 1.7.7-1. I am having trouble issuing basic ls commands against network drives. For example,after I NET USE to a network drive and cd to it (I.e. Cd /cygdrive/z/test) and then issue the ls command, I get invalid argument. I have never seen this on xp or vista, only win 7. Is this a known problem by any chance? Thank you! Charlie Bryant Binghamton, ny charl...@stny.rr.com Sent from my Verizon Wireless BlackBerry -- 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 for windows 7
On 8/31/2010 6:31 PM, charl...@stny.rr.com wrote: Hello, I just downloaded and installed the new cygwin for windows 1.7.7-1. I am having trouble issuing basic ls commands against network drives. For example,after I NET USE to a network drive and cd to it (I.e. Cd /cygdrive/z/test) and then issue the ls command, I get invalid argument. I have never seen this on xp or vista, only win 7. Is this a known problem by any chance? Thank you! No, this is not a known problem and certainly not a common one. Please submit a problem report as described by the link below if you continue to have problems. Problem reports: http://cygwin.com/problems.html -- 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: [ANNOUNCEMENT] Updated: cygwin-1.7.7-1
Corinna Vinschen schrieb: - Fix long-standing problem that calling select(2) on /dev/windows hangs for timeout, if no new messages arrived in the message queue since the last call to select. Yeah! Will test tcltk immediately and report back. This was my only blocker. Maybe I can even persuade pTk to emit a fine cygwin wish with native GDI for git, insight and friends. -- 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: Building Mutt: configure: invalid value of canonical build
Matthias Andree schrieb am 31.08.2010 um 00:58 (+0200): On 30.08.2010 23:52, Michael Ludwig wrote: The mutt mail reader shipping with Cygwin does not have SMTP enabled, which I'd like to give a try. So I tried to build mutt, but encountered problems. [... long whine about non-working build snipped ...] Whatever pills you've taken to discern lengthiness and whininess, I'd definitely recommend you stop taking them, especially when driving or writing email. [ irrelevant advice snipped ] -- 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: Building Mutt: configure: invalid value of canonical build
Csaba Raduly schrieb am 31.08.2010 um 09:17 (+0200): On Mon, Aug 30, 2010 at 11:52 PM, Michael Ludwig wrote: It is only after receiving an error because of the script's failure to guess the build system that I added the --build option to configure. But obviously I didn't fill in a correct value. What should I try? Try: i686-pc-cygwin This is what gcc -v reports. Thanks, I didn't know that. Unfortunately, the outcome is identical: \,,,/ (o o) --oOOo-(_)-oOOo-- cd /usr/src cp -r mutt-1.5.20-1/ mutt-1.5.20-1.milu # copy mutt source package cd mutt-1.5.20-1.milu touch install-sh# else you'll get an error touch config.sub# ditto ./configure --build=i686-pc-cygwin --prefix=/usr/local/mutt \ --enable-imap --enable-smtp --enable-hcache --with-regex --with-ssl # configure output snipped checking build system type... configure: error: invalid value of canonical build - Might there be something wrong with the source package for mutt? I remember building mutt from another Cygwin source package without any problems. -- 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: Building Mutt: configure: invalid value of canonical build
Am 01.09.2010, 01:37 Uhr, schrieb Michael Ludwig: Matthias Andree schrieb am 31.08.2010 um 00:58 (+0200): On 30.08.2010 23:52, Michael Ludwig wrote: The mutt mail reader shipping with Cygwin does not have SMTP enabled, which I'd like to give a try. So I tried to build mutt, but encountered problems. [... long whine about non-working build snipped ...] Whatever pills you've taken to discern lengthiness and whininess, I'd definitely recommend you stop taking them, especially when driving or writing email. It's your problem if you don't like the answers. Your fix attempts break the build system further, meaning that: if you touch config.sub, you create a blank canonicalization script, so don't complain about canonicalization errors or other malfunctions -- you triggered those that you caused yourself. You chose the blue pill, asking for blitheness, joy, and ignorance. So to sell you a faint clue of what the red pill might have provided if you had so chosen: a *real* config.sub is what should be doing the canonicalization -- a blank script won't achieve that. automake --add-missing (which is called as part of ./prepare) is what would install a set of real config.sub, install-sh, missing, and related scripts. The question of if the mutt distribution is incomplete is a distinct one - and the command line you showed on Monday works fine on a mutt HEAD checkout from the Mercurial repo. -- Matthias Andree -- 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: Building Mutt: configure: invalid value of canonical build
Am 01.09.2010, 01:37 Uhr, schrieb Michael Ludwig: Matthias Andree schrieb am 31.08.2010 um 00:58 (+0200): On 30.08.2010 23:52, Michael Ludwig wrote: The mutt mail reader shipping with Cygwin does not have SMTP enabled, which I'd like to give a try. So I tried to build mutt, but encountered problems. [... long whine about non-working build snipped ...] Whatever pills you've taken to discern lengthiness and whininess, I'd definitely recommend you stop taking them, especially when driving or writing email. Sorry, the first edition went out prematurely. Now for the good one: It's your problem if you don't like the answers. Your fix attempts break the build system further, meaning that: if you touch config.sub, you create a blank canonicalization script, so don't complain about canonicalization errors or other malfunctions -- you triggered those yourself. You chose the blue pill, asking for blitheness, joy, and ignorance. So to sell you a faint clue of what the red pill might have provided if you had so chosen: a *real* config.sub is what should be doing the canonicalization -- a blank script won't achieve that. automake --add-missing (which is called as part of ./prepare) is what would install a set of real config.sub, install-sh, missing, and related scripts. The question of if the mutt distribution is incomplete is a distinct one - and the command line you showed on Monday works fine on a mutt HEAD checkout from the Mercurial repo if you follow Csaba's advice; however you can usually just omit --build=... and the auto* built stuff will call config.guess to figure. -- Matthias Andree -- 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: endless problems with SSHD - bug ??
On 8/18/2010 11:24 PM, Bob Goldberg wrote: -Original Message- From: cygwin-owner http://cygwin.com/acronyms/#PCYMTNQREAIYR We don't encourage feeding the spammers around here. Thanks. Sent: Wednesday, August 18, 2010 1:04 PM To: cygwin ^^ Ditto. And actually all these header fields are unnecessary. snip and as I finish this - just had a h... having cygwin installed on non- C: isn't a problem - is it?? No but this may be relevant: http://www.cygwin.com/ml/cygwin/2009-12/msg01052.html Make sure you read the whole thread. -- 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: Support for the TIOCINQ ioctl
On Sat, 28 Aug 2010, Andy Koppe wrote: On 27 August 2010 23:31, Brennan Peter Sellner wrote: By any chance, has support for the TIOCINQ ioctl on file descriptors (used to check how many bytes of data are in the input buffer) been added to Cygwin? It hadn't as of 2004: http://sourceware.org/ml/cygwin/2004-07/msg00910.html It's still implemented only for serial devices. As I suspected. Thanks for the confirmation. ...but I haven't found any newer references to it. I'm inferring that it's not supported, as ioctl(fd, TIOCINQ, available) (where fd is a valid file descriptor, and available is a long) fails, with errno set to 'invalid argument'. I'm running Cygwin 1.7.6 on Vista. I'm hoping I'm missing something... Is there an alternative way to check the number of bytes on an fd's input buffer in Cygwin? What's your use case? And on what sort of fd? select() of course can tell you whether there are any bytes available to be read from an fd, and usually that's all one needs to know. I'm porting a fair chunk of legacy code that spawns processes in the background, provides an emulated tty, and monitors the output, allowing remote clients to interact with the backgrounded processes as if they were running in a local terminal. select can indeed do the trick: there were ioctl calls sprinkled liberally throughout the code, and I was attempting to avoid extensive refactoring. :-) Now that I've refactored things properly using select, things are once again working smoothly. Thanks again, -Brennan -- 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: Building Mutt: configure: invalid value of canonical build
Download the mutt 1.5.20 source from the mutt website.. it configures fine for me (had to add some dev libs, etc) ...snip... checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking for iswalnum... yes checking for iswalpha... yes checking for iswcntrl... yes checking for iswdigit... yes checking for iswgraph... yes checking for iswlower... yes checking for iswprint... yes checking for iswpunct... yes checking for iswspace... yes checking for iswupper... yes checking for iswxdigit... yes checking for towupper... yes checking for towlower... yes checking for mbstate_t... yes checking for wchar_t functions... yes checking for nl_langinfo and CODESET... yes checking for nl_langinfo and YESEXPR... yes checking for ospcat... none configure: creating ./config.status config.status: creating Makefile config.status: creating contrib/Makefile config.status: creating doc/Makefile config.status: creating imap/Makefile config.status: creating intl/Makefile config.status: creating m4/Makefile config.status: creating po/Makefile.in config.status: creating hcachever.sh config.status: creating muttbug.sh config.status: creating doc/instdoc.sh config.status: creating config.h config.status: executing depfiles commands config.status: executing default-1 commands config.status: creating po/POTFILES config.status: creating po/Makefile desktop ~/src/mutt-1.5.20 -- 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: scp and cygwin randomly and automatically converts text files from utf-8 to windows encoding (cp1251)
On 31 August 2010 20:23, rPman wrote: It happens when files are copied from cygwin windows machines to any linux (tried different versions of ubuntu and gentoo with utf-8 locale). Cygwin does not change the encoding of file content when copying files. Cygwin 1.7 does translate file names between the UTF-16 encoding used by Windows and the encoding you have configured in Cygwin via the LC_ALL, LC_CTYPE or LANG variables. Please try to desribe in more detail what you were trying to do and how it went wrong. Also, what version of Cygwin are you using? As it is not possible to understand in what cases are re-encoding, sometimes enough to add one blank line in a text file that, when the transfer encoding has not happened. Just changing the format of a newline (in the source files are unix-style \n, but on the linux machine has come to win-style \r\n) Line endings are a separate issue from character encodings. By default, directories are mounted in binary mode, where file content is left alone. Alternatively, they can be mounted in text mode, were line endings are automatically translated between Windows and Unix style. See http://www.cygwin.com/cygwin-ug-net/using-textbinary.html for lots more on that. 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
Updated: cygwin-1.7.7-1
Hi Cygwin friends and users, I just released 1.7.7-1. This release fixes a bunch of bugs, some of them freshly introduced with 1.7.6. It also introduces a very few number of new features. Most notably it partially reverts a backward incompatibility which affects Cygwin applications which also call native Win32 functions to do part of their job. Unfortunately this goes hand in hand with a regression, kind of. So far it was possible in Cygwin 1.7.x to remove a directory which was the current working directory (CWD) of another Cygwin process, or even the CWD of the process itself. This Linux-like feature had to be dropped, because the implementation could result in strange handle problems on Vista and later, and the workaround in 1.7.6 introduced more problems than anticipated. So we're back to Win32-like behaviour, which is, rmdir returns with Device or resource busy when trying to remove a directory which is CWD of a Cygwin process. Fortunately this behaviour is covered and explicitely allowed by the POSIX standard, so we're still on firm ground, standards-wise. I think this goes without saying, but please have another look into the documentation at http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html. It contains a couple of improvements and the description for new features and changes from old behaviour. What's new since Cygwin 1.7.6: == - Make sure to follow the Microsoft security advisory concerning DLL hijacking. http://www.microsoft.com/technet/security/advisory/2269637.mspx - Allow to link against -lbinmode instead of /lib/binmode.o. Same for -ltextmode, -ltextreadmode and -lautomode. See http://cygwin.com/cygwin-ug-net/using-textbinary.html#textbin-devel - BSD macros in endian.h (htobe16, le32toh, etc). What changed since Cygwin 1.7.6: - Partially revert the 1.7.6 change to set the Win32 current working directory (CWD) always to an invalid directory, since it breaks backward compatibility too much. See the reworked http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api - A crash in a virtual directory (/proc, /cygdrive, //) does not produce a stackdump file in some unrelated directory anymore. - Improve d_type info in dirent structure. - /proc/partitions now prints entire partition layout also for non-privileged users. - cygcheck now prefers the \\?\X: DOS device name over every other available device name for a harddisk. Bugfixes since Cygwin 1.7.6: - Avoid accidental usage of buggy newlib version of wcsncpy. - Set st_rdev stat member for filesystem-based device nodes correctly. - Fix bug in statvfs et al. which returned incorrect information for volume mount points. - Close handle leak when following symlinks. - Fix problem with mount options when using the mount(1) command to create new, session-temporary mount points. - Workaround a bug in Tru64 filesystems. - Fix long-standing problem that calling select(2) on /dev/windows hangs for timeout, if no new messages arrived in the message queue since the last call to select. - Fix pathname problem in ldd. Have fun, Corinna *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://cygwin.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:cyg...@cygwin.com Red Hat, Inc.
Updated: m4-1.4.15-1
A new release of m4, 1.4.15-1, is available for download, leaving 1.4.14-1 as previous. NEWS This is a new upstream release, with upstream NEWS attached. See also /usr/share/doc/m4/. You must rebuild from source if you want the experimental changeword feature enabled, as using it can slow down normal operation, and since it will disappear from the eventual m4 2.0. DESCRIPTION === m4 is an implementation of the traditional Unix macro processor. It is mostly SVR4 compatible although it has some extensions (for example, handling more than 9 positional parameters to macros). GNU m4 also has built-in functions for including files, running shell commands, doing arithmetic, etc. UPDATE == To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'm4' from the 'Interpreters' category. DOWNLOAD: = Note that downloads from cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin m4 maintainer CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. * Noteworthy changes in release 1.4.15 (2010-08-31) [stable] ** Fix regression introduced in 1.4.9b where the `format' builtin could crash on an invalid format string. ** Fix compilation against newer glibc, and on AIX 7.1BETA. ** A number of portability improvements inherited from gnulib. signature.asc Description: OpenPGP digital signature
