Re: RFC: cygport cross-compiling APIs
On Thu, 2010-07-15 at 01:46 -0400, Christopher Faylor wrote:
On Wed, Jul 14, 2010 at 06:54:41PM -0500, Yaakov (Cygwin/X) wrote:
On Wed, 2010-07-14 at 11:12 -0400, Christopher Faylor wrote:
You know, back when I was distributing the mingw and w32api packages I
would have sworn that I put them in cross-compiler locations and created
legacy symlinks back to the old /usr/include /usr/lib locations.
That would be possible with mingw-runtime but not with w32api.
It's possible with anything if you modify the compiler which is, I believe,
what I had done.
Let me clarify: mingw-runtime and mingw-w32api will end up in the same
directory, namely /usr/i686-pc-mingw32/sys-root/mingw/{include,lib}.
Theoretically, one could create symlinks from there
to /usr/{include,lib}/mingw without issues. But if you do the same
for /usr/{include,lib}/w32api, then suddenly the MSVCRT headers and libs
end up in native gcc's default search path, and that is a recipe for
disaster.
However, practically, we won't be able to ship /usr/{include,lib}/mingw
symlinks because those locations are currently real directories
containing the soon-to-be-old mingw-* packages. OTOH, if the new
mingw-gcc cross-compiler outright replaces the old gcc-3 -mno-cygwin
support packages, then we won't need /usr/{include,lib}/mingw at all.
Yaakov
setup: gcc-4.5 compatibility
My test case for the mingw toolchain is, of course, setup.exe. I have
uploaded test builds of all mingw-* prereqs here:
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW/
setup-gcc45.patch contains the changes necessary to compile and link
with mingw-gcc-4.5. However, the resulting setup.exe promply SEGVs in
rtlinitunicodestr...@8. The problem is centered around the autoload
code, because if you circumvent autoload and link directly against those
APIs, then the resulting binary works. This can be demonstrated by
applying setup-no-autoload.patch on top of the first patch, then:
make CPPFLAGS=-DSETUP_NO_AUTOLOAD LIBS='-lmingw32 -lntdll -lwininet'
The reason for the crash is beyond me. Hopefully this will be enough
for someone to help figure it out.
Yaakov
DRAFT PATCH: DO NOT COMMIT!!
Fix compatibility with GCC 4.5.
* Makefile.am (setup_LDFLAGS): Pass -static to compiler instead of
linker so that libgcc is statically linked as well.
* doconfigure: Remove usused PATH manipulation.
Change CC and CXX to $target-prefixed names.
* localdir.cc (browse_cb): Fix jump to case label crosses
initialization error.
* mklink2.cc (sfli): Fix non-local variable uses anonymous type
warning.
* ntdll.h: Fix redeclared without dllimport attribute: previous
dllimport ignored warnings.
* package_message.h (display): Fix ‘exit’ was not declared in this
scope error.
Index: Makefile.am
===
RCS file: /cvs/cygwin-apps/setup/Makefile.am,v
retrieving revision 2.81
diff -u -r2.81 Makefile.am
--- Makefile.am 8 Apr 2010 15:50:38 - 2.81
+++ Makefile.am 15 Jul 2010 04:58:07 -
@@ -117,7 +117,7 @@
libinilex.a \
-Linst/lib -lgetopt++ -lgcrypt -lgpg-error \
-lshlwapi -lcomctl32 -lole32 -lwsock32 -lnetapi32 -luuid -llzma -lbz2 -lz
-setup_LDFLAGS = -mwindows -Wl,-static -static-libtool-libs
+setup_LDFLAGS = -mwindows -Wc,-static -static-libtool-libs
setup_SOURCES = \
AntiVirus.cc \
AntiVirus.h \
Index: doconfigure
===
RCS file: /cvs/cygwin-apps/setup/doconfigure,v
retrieving revision 2.2
diff -u -r2.2 doconfigure
--- doconfigure 30 Mar 2010 23:55:15 - 2.2
+++ doconfigure 15 Jul 2010 04:58:07 -
@@ -9,19 +9,11 @@
( cd $DIR ./bootstrap.sh )
fi
-# If $build == cygwin, set PATH so that correct (mingw)
-# version of gpg-error-config and libgcrypt-config are
-# used. Otherwise: assume cross-compiler users are
-# sophisticated enough to do this manually.
-case `uname -s` in
-*CYGWIN* ) export PATH=/usr/lib/mingw:${PATH} ;;
-esac
-
# Configure
cmd=\$DIR/configure\
cmd=$cmd' -C --disable-shared --enable-maintainer-mode'
cmd=$cmd' --host=i686-pc-mingw32 --build=i686-pc-cygwin'
-cmd=$cmd' CC=gcc-3 -mno-cygwin CXX=g++-3 -mno-cygwin'
+cmd=$cmd' CC=i686-pc-mingw32-gcc CXX=i686-pc-mingw32-g++'
for i in $@; do
case $i in
Index: localdir.cc
===
RCS file: /cvs/cygwin-apps/setup/localdir.cc,v
retrieving revision 2.36
diff -u -r2.36 localdir.cc
--- localdir.cc 2 Feb 2010 17:28:10 - 2.36
+++ localdir.cc 15 Jul 2010 04:58:07 -
@@ -152,12 +152,14 @@
SendMessage (h, BFFM_SETSELECTION, TRUE, (LPARAM) local_dir.c_str());
break;
case BFFM_SELCHANGED:
- // Make a note of each new dir we successfully select, so that
- // we know where to create the new directory if an invalid name
- // is entered in the text box.
- LPITEMIDLIST pidl = reinterpret_castLPITEMIDLIST(lp);
- SHGetPathFromIDList (pidl, dirname);
- break;
+ {
+// Make a note of each new dir we successfully select, so that
+// we know where to create the new directory if an invalid name
+// is entered in the text box.
+LPITEMIDLIST pidl = reinterpret_castLPITEMIDLIST(lp);
+SHGetPathFromIDList (pidl, dirname);
+break;
+ }
case BFFM_VALIDATEFAILED:
// See if user wants to create a dir in the last successfully-selected.
CHAR tempname[MAX_PATH];
Index: mklink2.cc
===
RCS file: /cvs/cygwin-apps/setup/mklink2.cc,v
retrieving revision 2.11
diff -u -r2.11 mklink2.cc
--- mklink2.cc 18 Dec 2009 11:59:54 - 2.11
+++ mklink2.cc 15 Jul 2010 04:58:07 -
@@ -111,7 +111,7 @@
: mkcygsymlink_9x (from, to);
}
-struct {
+static struct {
FILE_LINK_INFORMATION fli;
WCHAR namebuf[32768];
} sfli;
Index: ntdll.h
===
RCS file: /cvs/cygwin-apps/setup/ntdll.h,v
retrieving revision 2.2
diff -u -r2.2 ntdll.h
--- ntdll.h 13 May 2009 11:28:34 - 2.2
+++ ntdll.h 15 Jul 2010 04:58:07 -
@@ -14,6 +14,8 @@
#ifndef SETUP_NTDLL_H
#define SETUP_NTDLL_H
+#define NTOSAPI
+
#include ddk/ntapi.h
#include ddk/ntifs.h
Index: package_message.h
===
RCS
Re: cygport cross-compiling beta1
On Thu, 2010-07-15 at 12:50 -0500, Yaakov (Cygwin/X) wrote:
2) Cygwin-to-other cross-compiling, via cross.cygclass
Cross-compiling is supported for packages using autotools, cmake, or
hand-written makefiles. Packages are automatically installed into the
sysroot (under $D).
The way I used the sysroot so far was to configure packages for their
regular prefix (/usr or /mingw), then install with DESTDIR=
${D}${CROSS_SYSROOT}. Without the sysroot path hard-coded anywhere, the
cross-compiled files should be usable either on the host system as-is or
within the sysroot for further cross-compiling.
Unfortunately I found two problems with this approach: libtool and
*-config scripts (NOT pkg-config).
libtool's ignorance of sysroots is well documented and seems to be
considered a known bug. I've seen it manifested in at least two ways:
1) on ELF platforms, during relink; in linux-i686-glib2.0, libgio
consistently refused to relink because a spurious -L/usr/lib caused
Cygwin's libc.a to be picked up. The offending -L flag was caused by
the line in libtool following the words we'll fake it, triggered by
relinking against libglib and friends from the same package, which
libtool thought would literally reside in /usr/lib.
2) when building setup.exe, libtool complained that it could not
find /mingw/lib/libgpg-error.la, a dependency_libs of libgcrypt. Of
course, libgpg-error was there, under the sysroot. (Note that I
manually fixed my mingw-libgcrypt test build to not interfere with the
setup.exe/gcc-4.5 discussion.)
The other problem would be packages relying on a foo-config script to
discover foo's cflags/libs, which would be prone to output -I or -L
flags for the native path instead of within the sysroot. Note that
pkg-config can understand sysroots through an environment variable,
which cross.cygclass uses.
The alternative to mitigate these issues would be to configure with
--prefix=$CROSS_SYSROOT$prefix et. al., causing the sysroot to be
hard-coded throughout. This should fix these cases, but packages so
built would be unsuitable for use on the host system, and using
host-built packages under the sysroot would require adding the sysroot
to their .la and .pc files.
Thoughts?
Yaakov
RE: Mouse offset when using java swing based gui applications
There's a bug reported against Java relating to this, with some more details. It claims to be fixed, but it still occurs. There's a small test case in the bug report. It makes many Java UI applications unusable with Cygwin/X. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434227 Richard -Original Message- From: Jon TURNEY [mailto:jon.tur...@dronecode.org.uk] Sent: 15 July 2010 14:38 To: cygwin-xfree@cygwin.com Cc: jonas_wink...@gmx.de Subject: Re: Mouse offset when using java swing based gui applications On 13/07/2010 22:56, Jonas Winkler wrote: I just noticed a very strange behaviour of my Cygwin/X-setup. I have a laptop running Debian 5.0 and openssh-server 1.5.1. My windows7 x64 machine is running cygwin 1.7.5 and cygwin/x 1.8.0 (fresh installation). I'm using ssh and x forwarding to use gui applications - especially Netbeans 6.9 - on my windows machine. So far, all X applications run fine on windows. Using Netbeans is somewhat weird. After startup, i can use the menues, edit code, etc. But as soon as I change the window position (moving, maximizing) of Netbeans, it seems as if the position of the window actually does not change. Clicking works, but selecting a menu item not. I need to click and hold on the menu item, drag the mouse to the position where the menu would be before moving the window and then release it. Same goes for code completition windows - they pop up where they should be before moving the window. I investigated a bit more and build a very basic Java gui application using swing (same library used by netbeans to display gui elemets) and the problem persists. As said before other applications (tested: gnome-terminal, gedit and nautilus) just work fine. So this is a swing-related rather than a netbeans-related problem. I attached the cygcheck.out. I dont know what other kind of information I should provide, so if there's anything you need, please let me know. Thanks very much for the clear problem report. We've had some similar reports before of problems with the mouse position reporting with Java applications, for e.g. [1], but I've never had a simple test case that has allowed me to reproduce it and investigate. So, I'd be very interested to see your simple Java application which demonstrates the problem. If you could also start the Xserver with the '-logverbose 3' option and attach your /var/log/XWin.0.log, that would be most helpful. [1] http://sourceware.org/ml/cygwin-xfree/2009-08/msg00060.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/
Resizing problem
I installed cygwin/xcygwin 1.7.5 with KDE. I tried clicking on XWin Server from the Start menue, but nothing happened. I tried startx from the cygwin basic terminal. Nothing. After some Google archaeology, I found someone that had done this: cd \cygwin\bin ash PATH=. rebaseall -v at the DOS command. Good. It worked. Running startx at the cygwin command did start a twm session. But how the KDE would run, I couldn't figure out from any amount of documentation or Googling. After some more Googling, I saw a reference to an Openbox. Guessing along, I got startx /usr/bin/openbox to give me Openbox. My problem is that I cannot minimize anything because it goes down below and out of sight. The XWin container window is sized on start up to my right computer screen, but when I drag it over to my larger left screen, it can't be resized. I suspect Openbox has a default size larger (lower?) and down in the hidden part is no doubt either a task bar with the minimized apps or the minimized apps themselves, right? Alt-Tab only cycles the Win7 apps, not the XWin session apps, BTW. Actually, I don't need the startx version, I could very well use the startxwin multi-windows version IF I could get Emacs in shell mode to do cygwin bash. Starting the X server and then Emacs multi-windows style gets a shell mode that apparently doesn't see cygwin. I'm guessing it's using the DOS command. How can I a) get at the minimized apps? or b) how can I get a stand-alone X server-run Emacs to see cygwin bash? Olwe Bottorff Grand Marais, MN -- 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: Resizing problem
On 7/15/2010 1:02 PM, Olwe Melwasul wrote: [...] Actually, I don't need the startx version, I could very well use the startxwin multi-windows version IF I could get Emacs in shell mode to do cygwin bash. Starting the X server and then Emacs multi-windows style gets a shell mode that apparently doesn't see cygwin. I'm guessing it's using the DOS command. I can't comment on the first part of your post, but I'm Cygwin's emacs maintainer and can try to help you get emacs running. If you want to run emacs under X, install the emacs-X11 package and then type 'emacs' in an xterm window. If something doesn't work the way you expect, please give a precise recipe for reproducing the problem. I don't know what you mean by a shell mode that apparently doesn't see cygwin. Ken -- 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: Resizing problem
Yes, I am using the emacs-X11 and yes, I started it (after starting the X server to get multiwindowed mode) with emacs at the cygwin command. Emacs-X11 comes up fine, looking good. Then I do M-x shell to get a shell environment inside of Emacs. But what comes up is not bash. I'm not sure what it is, but it sees no cygwin apps: It doesn't know what ls or which diff or any other GNU/cygwin stuff is. I assume it is the DOS shell. Oddly, if I start emacs-X11 inside the windowed mode (startx) and do emacs shell mode, it does see bash and the rest of the GNU/cygwin apps. O GM, MN On Thu, Jul 15, 2010 at 1:12 PM, Ken Brown kbr...@cornell.edu wrote: On 7/15/2010 1:02 PM, Olwe Melwasul wrote: [...] Actually, I don't need the startx version, I could very well use the startxwin multi-windows version IF I could get Emacs in shell mode to do cygwin bash. Starting the X server and then Emacs multi-windows style gets a shell mode that apparently doesn't see cygwin. I'm guessing it's using the DOS command. I can't comment on the first part of your post, but I'm Cygwin's emacs maintainer and can try to help you get emacs running. If you want to run emacs under X, install the emacs-X11 package and then type 'emacs' in an xterm window. If something doesn't work the way you expect, please give a precise recipe for reproducing the problem. I don't know what you mean by a shell mode that apparently doesn't see cygwin. Ken -- 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: Resizing problem
On 7/15/2010 3:51 PM, Olwe Melwasul wrote: Yes, I am using the emacs-X11 and yes, I started it (after starting the X server to get multiwindowed mode) with emacs at the cygwin command. Emacs-X11 comes up fine, looking good. Then I do M-x shell to get a shell environment inside of Emacs. But what comes up is not bash. I'm not sure what it is, but it sees no cygwin apps: It doesn't know what ls or which diff or any other GNU/cygwin stuff is. I assume it is the DOS shell. Oddly, if I start emacs-X11 inside the windowed mode (startx) and do emacs shell mode, it does see bash and the rest of the GNU/cygwin apps. [Please don't top-post.] I think the problem is that your PATH isn't set correctly inside emacs. How are you starting the X server? If you use the start menu shortcut (with target C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe) you shouldn't have that problem. Notice that it uses 'bash -l' precisely so that the environment, including PATH, is set up in the normal way. Ken -- 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: Resizing problem
On Thu, Jul 15, 2010 at 4:20 PM, Ken Brown kbr...@cornell.edu wrote: On 7/15/2010 3:51 PM, Olwe Melwasul wrote: Yes, I am using the emacs-X11 and yes, I started it (after starting the X server to get multiwindowed mode) with emacs at the cygwin command. Emacs-X11 comes up fine, looking good. Then I do M-x shell to get a shell environment inside of Emacs. But what comes up is not bash. I'm not sure what it is, but it sees no cygwin apps: It doesn't know what ls or which diff or any other GNU/cygwin stuff is. I assume it is the DOS shell. Oddly, if I start emacs-X11 inside the windowed mode (startx) and do emacs shell mode, it does see bash and the rest of the GNU/cygwin apps. [Please don't top-post.] I think the problem is that your PATH isn't set correctly inside emacs. How are you starting the X server? If you use the start menu shortcut (with target C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe) you shouldn't have that problem. Notice that it uses 'bash -l' precisely so that the environment, including PATH, is set up in the normal way. Ken I started the X-server with the menu shortcut (which has the execute string you listed) and ... after ... a full minute it delivers a stand-alone xterm. I then click on the Emacs-X11, and after a long wait, it comes up. I do an M-x shell -- and get a sh-3.2$ prompt. I try some commands, and it only seems to know a few. cd does get me to /home/Olwe which tells me it must have something to do with cygwin, but it knows no other GNU/cygwin other than perhaps pwd. Next, I kill it and start Emacs-X11 in the xterm emacs . It comes up fine. I do M-x shell -- and get the identical prompt I got in xterm, namely, o...@olwe-pc $ I type commands and they work -- it sees the GNU/cygwin apps fine -- but it leaves odd characters after it returns, e.g. $ which diff /usr/bin/diff ^[]0;~^G The last string is not random, it has some method to its madness. For example $ ls dbus-4xiZFwCMPa dbus-U6vB5c6MSd dbus-hdtwMyVbXA dbus-yXQ8LOSIN3 ]0;/tmp Actually, I copied the above output and lost the ^[ and the ^G, but they show up on the emacs shell output. Next, I kill emacs-X11 stand-alone and start emacs -nw in the xterm. Same funky characters. I try other consoles -- same funky characters. Again, the windowed mode doesn't have these problems, just the issues with minimized apps disappearing beyond the bottom of Openbox. If I could just get rid of the funky xterm characters, I'd call it a day -- 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: Resizing problem
On 7/15/2010 9:26 PM, Olwe Melwasul wrote: On Thu, Jul 15, 2010 at 4:20 PM, Ken Brownkbr...@cornell.edu wrote: On 7/15/2010 3:51 PM, Olwe Melwasul wrote: Yes, I am using the emacs-X11 and yes, I started it (after starting the X server to get multiwindowed mode) with emacs at the cygwin command. Emacs-X11 comes up fine, looking good. Then I do M-x shell to get a shell environment inside of Emacs. But what comes up is not bash. I'm not sure what it is, but it sees no cygwin apps: It doesn't know what ls or which diff or any other GNU/cygwin stuff is. I assume it is the DOS shell. Oddly, if I start emacs-X11 inside the windowed mode (startx) and do emacs shell mode, it does see bash and the rest of the GNU/cygwin apps. [Please don't top-post.] I think the problem is that your PATH isn't set correctly inside emacs. How are you starting the X server? If you use the start menu shortcut (with target C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe) you shouldn't have that problem. Notice that it uses 'bash -l' precisely so that the environment, including PATH, is set up in the normal way. Ken I started the X-server with the menu shortcut (which has the execute string you listed) and ... after ... a full minute it delivers a stand-alone xterm. I then click on the Emacs-X11, and after a long It sounds like you're using the Emacs-X11 start menu shortcut that's created by the X-start-menu-icons package. Don't use it. It doesn't set up the environment properly before starting emacs. To get a useful shortcut, you can use the script /usr/bin/make-emacs-shortcut that comes with the emacs package. wait, it comes up. I do an M-x shell -- and get a sh-3.2$ prompt. I try some commands, and it only seems to know a few. cd does get me to /home/Olwe which tells me it must have something to do with cygwin, but it knows no other GNU/cygwin other than perhaps pwd. Next, I kill it and start Emacs-X11 in the xterm emacs. It comes up fine. I do M-x shell -- and get the identical prompt I got in xterm, namely, o...@olwe-pc $ I type commands and they work -- it sees the GNU/cygwin apps fine -- but it leaves odd characters after it returns, e.g. $ which diff /usr/bin/diff ^[]0;~^G This is ugly but harmless. It's an escape sequence that's part of the shell prompt, which is controlled by the PS1 environment variable. (In a normal shell, as opposed to one in emacs, you don't see it directly; I think it affects the color of the current directory, displayed as part of the prompt.) The last string is not random, it has some method to its madness. For example $ ls dbus-4xiZFwCMPa dbus-U6vB5c6MSd dbus-hdtwMyVbXA dbus-yXQ8LOSIN3 ]0;/tmp Actually, I copied the above output and lost the ^[ and the ^G, but they show up on the emacs shell output. Next, I kill emacs-X11 stand-alone and start emacs -nw in the xterm. Same funky characters. I try other consoles -- same funky characters. Again, the windowed mode doesn't have these problems, just the issues with minimized apps disappearing beyond the bottom of Openbox. If I could just get rid of the funky xterm characters, I'd call it a day Read about the PS1 environment variable in the bash manual (or google). Ken -- 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: Resizing problem
On 7/15/2010 10:03 PM, Ken Brown wrote: On 7/15/2010 9:26 PM, Olwe Melwasul wrote: On Thu, Jul 15, 2010 at 4:20 PM, Ken Brownkbr...@cornell.edu wrote: On 7/15/2010 3:51 PM, Olwe Melwasul wrote: Yes, I am using the emacs-X11 and yes, I started it (after starting the X server to get multiwindowed mode) with emacs at the cygwin command. Emacs-X11 comes up fine, looking good. Then I do M-x shell to get a shell environment inside of Emacs. But what comes up is not bash. I'm not sure what it is, but it sees no cygwin apps: It doesn't know what ls or which diff or any other GNU/cygwin stuff is. I assume it is the DOS shell. Oddly, if I start emacs-X11 inside the windowed mode (startx) and do emacs shell mode, it does see bash and the rest of the GNU/cygwin apps. [Please don't top-post.] I think the problem is that your PATH isn't set correctly inside emacs. How are you starting the X server? If you use the start menu shortcut (with target C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe) you shouldn't have that problem. Notice that it uses 'bash -l' precisely so that the environment, including PATH, is set up in the normal way. Ken I started the X-server with the menu shortcut (which has the execute string you listed) and ... after ... a full minute it delivers a stand-alone xterm. I then click on the Emacs-X11, and after a long It sounds like you're using the Emacs-X11 start menu shortcut that's created by the X-start-menu-icons package. Don't use it. It doesn't set up the environment properly before starting emacs. To get a useful shortcut, you can use the script /usr/bin/make-emacs-shortcut that comes with the emacs package. I should have added that you should see /usr/share/doc/Cygwin/emacs.README for more information about that script and the shortcut it creates. Ken -- 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: Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt
--- On Tue, 7/13/10, Jon TURNEY wrote: From: Jon TURNEY Subject: Re: Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt To: cygwin-xfree@cygwin.com Date: Tuesday, July 13, 2010, 3:21 PM On 09/07/2010 07:58, Marco Atzeri wrote: Snipped on my Win-XP SP2 under cygwin/X MC with F10 exits in the current directory Peter, as mc is an alias alias mc='. /usr/share/mc/bin/mc-wrapper.sh' I guess that under X this wrapper is working differently than under console Perhaps more likely, the alias isn't setup by the shell init scripts under xterm because of the way the xterm was started (which the OP hasn't said) (but is being setup for cmd.exe or rxvt) Note that it's impossible for mc to change the current directory of the parent shell without this alias. For the record, the xterm I used for this test was the one started from the cygwin-X start menu item. I still have not found the round tuits to compile a debugging version of MC to check this out in more detail, but I hope to do so sometime in the next 30 days (lots of RL intruding). I will reply again when I have more information. Thank you all for your advice and help. Peter -- 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: Resizing problem
On Thu, Jul 15, 2010 at 9:20 PM, Ken Brown kbr...@cornell.edu wrote: I should have added that you should see /usr/share/doc/Cygwin/emacs.README for more information about that script and the shortcut it creates. Ken make-emacs-shortcut was in /bin. There was nothing in the .../README about it, though. README talked about a source code compile and install of Emacs. So what exactly should I do with make-emacs-shortcut? I clicked on it from WinManager and it did something, now I get normal bash behavior from the non-X11 console (e.g. default cygwin console and mintty) when I start emacs no window. When I start multiwindowed, same good behavior. Will look into PS1 environment stuff. And BTW, thank you very much. Olwe Grand Marais, MN -- 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 wincap.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-07-15 08:00:52 Modified files: winsup/cygwin : ChangeLog wincap.cc Log message: * wincap.cc (wincap_7): Set needs_count_in_si_lpres2 to false. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4975r2=1.4976 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wincap.cc.diff?cvsroot=srcr1=1.99r2=1.100
Re: Problem with select() on console
Am 15.07.2010, 07:49 Uhr, schrieb Christopher Faylor: On Thu, Jul 15, 2010 at 01:44:19AM +0100, Cliff Hones wrote: When select() is used to test for input availability on the standard cygwin console in normal (cooked) mode, it indicates input is available as soon as any key is pressed. However, a call to read(0,...) will (correctly) block until a terminating RETURN is entered. select() should only indicate input is available when a call to read would *not* block - ie when a read call will immediately return at least one character or an error such as EOF. The behaviour of the following test case illustrates this. When run in a console window typing a single key causes the program to wait for the whole line. When run under mintty or on Linux the select() calls will continue to return no input until RETURN is entered. Since, AFAIK, Windows has no way to do this, I don't see how it could be done easily. You could, I guess, pull characters into a buffer until a newline was found but that would be pretty error-prone and any use of select() would potentially invalidate console i/o for subprocesses. So, I don't see this changing anytime soon. Is there a way to detect that the application is run from a Windows console rather than mintty? If so, cygwin1.dll could print a warning to the console, (something along the lines that running the application under some X11 terminal or mintty is advised) and return EINVAL, or abort the application, in either case if POSIXLY_CORRECT is set in the environment, much like some GNU tools will switch to a more POSIX compliant behaviour with that variable. Just a rough thought... -- 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: {lp,cb}Reserved2 under Windows 7 and file descriptors
On Jul 14 15:38, Daniel Colascione wrote: This is from sigproc.cc: /* It appears that when running under WOW64 on Vista 64, the first DWORD value in the datastructure lpReserved2 is pointing to (msv_count in Cygwin), has to reflect the size of that datastructure as used in the Microsoft C runtime (a count value, counting the number of elements in two subsequent arrays, BYTE[count and HANDLE[count]), even though the C runtime isn't used. Otherwise, if msv_count is 0 or too small, the datastructure gets overwritten. [...] While this workaround is indeed necessary for Vista, it's *not* necessary for Windows 7, which again handles copying the data structure pointed to by lpReserved2 properly. Therefore, needs_count_in_si_lpres2 can be false on that platform. Thanks for the hint. You *did* test that, did you? I made a quick test on Windows 7 x64. Starting a shell, running scripts and starting other processes looks good. I checked in the change to wincap.cc. [...] Furthermore, there is a very long-standing issue with Cygwin pty devices: while Cygwin programs report true from isatty() when called on a Cygwin PTY, MSVCRT applications do *not*. Right. [...] However, due to the way the CRT works, we can fool it into thinking a passed-in file descriptor is actually a tty. All you need to do is use 3 for the value of *lpReserved2, then follow it with three flag bytes, then three HANDLE values --- corresponding respectively to flags[fd0], flags[fd1], flags[fd2] and fh[0], fh[fd1] and fh[fd2]. This information would be followed by the normal child_info structure. If stdin, stdout, or stderr is a Cygwin PTY, Cygwin can manually set the FDEV bit (described in the old MSDOS headers) in corresponding flag byte, which will make _isatty() return true in the child. (Not that I've actually tried it --- it's just an idea.) That sounds like an interesting idea. I'll play around with it as soon as I have a bit of spare time again. Unless, of course, nobody else will try it or already did... 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: {lp,cb}Reserved2 under Windows 7 and file descriptors
On 7/15/10 1:19 AM, Corinna Vinschen wrote: Thanks for the hint. You *did* test that, did you? Yep. I've been using this setup for a few days now and everything works. [...] That sounds like an interesting idea. I'll play around with it as soon as I have a bit of spare time again. Unless, of course, nobody else will try it or already did... Likewise, I'll see if I can hack that up if I ever get some free time. Thanks again for 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: {lp,cb}Reserved2 under Windows 7 and file descriptors
On 15 July 2010 09:19, Corinna Vinschen wrote: Furthermore, there is a very long-standing issue with Cygwin pty devices: while Cygwin programs report true from isatty() when called on a Cygwin PTY, MSVCRT applications do *not*. Right. [...] However, due to the way the CRT works, we can fool it into thinking a passed-in file descriptor is actually a tty. All you need to do is use 3 for the value of *lpReserved2, then follow it with three flag bytes, then three HANDLE values --- corresponding respectively to flags[fd0], flags[fd1], flags[fd2] and fh[0], fh[fd1] and fh[fd2]. This information would be followed by the normal child_info structure. If stdin, stdout, or stderr is a Cygwin PTY, Cygwin can manually set the FDEV bit (described in the old MSDOS headers) in corresponding flag byte, which will make _isatty() return true in the child. (Not that I've actually tried it --- it's just an idea.) That sounds like an interesting idea. I'll play around with it as soon as I have a bit of spare time again. Unless, of course, nobody else will try it or already did... It would be brilliant if this did work, taking at least some of the sting out of the whole pty vs interactive console app issue. 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: Problem with select() on console
Christopher Faylor wrote: On Thu, Jul 15, 2010 at 01:44:19AM +0100, Cliff Hones wrote: When select() is used to test for input availability on the standard cygwin console in normal (cooked) mode, it indicates input is available as soon as any key is pressed. However, a call to read(0,...) will (correctly) block until a terminating RETURN is entered. select() should only indicate input is available when a call to read would *not* block - ie when a read call will immediately return at least one character or an error such as EOF. ... Since, AFAIK, Windows has no way to do this, I don't see how it could be done easily. You could, I guess, pull characters into a buffer until a newline was found but that would be pretty error-prone and any use of select() would potentially invalidate console i/o for subprocesses. So, I don't see this changing anytime soon. Hmm. Having looked further, it's not just select() which is affected. If you set the NONBLOCK flag on the console, and perform a read(), you get error EWOULDBLOCK/EAGAIN until a key is hit. When a key is hit, the read blocks until RETURN is entered. I must look at the console source - but it seems from behaviour and what you are saying that Windows provides a way for the user to determine that console input has started (since read() and select() behaviour changes when a key is pressed) but no way to determine in advance that a call to input a complete line will block because an incomplete line is present. I'm surprised this hasn't come up more frequently. In my case, I have an app which needs to respond to user input line-based commands, but also does other processing. I don't want the app to block every time the user starts to enter a command. Of course I could use threads, but that's an unnecessary change (at least unnecessary on Linux etc). And I could insist users use mintty, but that's rather presumptuous. -- Cliff -- 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: DomainUser homedir should be ? = probem: mkpasswd: (434): [31] A device attached to the system is not functioning.
2010/7/13 Linda Walsh cyg...@tlinx.org: ... Windows 7 Ultimate Ver 6.1 Build 7600 Running under WOW64 on AMD64 Path: . C:\sbin C:\usr\sbin C:\usr\local\sbin C:\Prog64\strawberry-perl\c\bin C:\prog64\strawberry-perl\perl\site\bin C:\prog64\strawberry-perl\perl\bin %CommonProgramFiles%\Microsoft Shared\Windows Live C:\bin C:\prog64\vim C:\prog\sysinternals C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Prog64\WIDCOMM\Bluetooth Software C:\Prog64\WIDCOMM\Bluetooth Software\syswow64 C:\Prog\Common Files\Acronis\SnapAPI C:\Prog\Autodesk\Backburner C:\Prog64\Common Files\Autodesk Shared C:\Prog\Common Files\DivX Shared\ C:\Prog\Common Files\Acronis\SnapAPI\ C:\Prog\NVIDIA Corporation\PhysX\Common C:\Prog\Sysinternals\cmd C:\Prog\Sysinternals C:\usr\local\bin C:\users\law.Bliss\bin C:\users\law.Bliss\scripts /bin behind the strawberry bins cries for trouble. If you want cygwin put c:/bin first If you want strawberry gcc and perl prepend strawberry in your cmd.exe console. But do not mix it. Found: C:\bin\awk - C:\bin\gawk.exe Found: C:\bin\bash.exe Found: C:\bin\cat.exe Found: C:\bin\cp.exe Found: C:\Prog64\strawberry-perl\c\bin\cpp.exe Found: C:\bin\cpp.exe Found: C:\bin\crontab.exe Found: C:\bin\find.exe Found: C:\Windows\system32\find.exe Found: C:\Prog64\strawberry-perl\c\bin\gcc.exe Found: C:\bin\gcc.exe Found: C:\bin\gdb.exe Found: C:\bin\grep.exe Found: C:\bin\kill.exe Found: C:\Prog64\strawberry-perl\c\bin\ld.exe Found: C:\bin\ld.exe Found: C:\bin\ls.exe Found: C:\bin\make.exe Found: C:\bin\mv.exe Found: C:\Prog64\strawberry-perl\c\bin\patch.exe Found: C:\bin\patch.exe Found: C:\prog64\strawberry-perl\perl\bin\perl.exe Good to see that mess finally, so I can reject your cygwin perl problems right away net time. Found: C:\bin\perl.exe -- 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: Problem with select() on console
Cliff Hones wrote: I must look at the console source... And now I have, and I see that fhandler_console does its own line editing, so is perfectly aware of the input line state. So blocking as soon as any key is typed seems a shortcoming of cygwin, not windows? I see there may be a difficulty with storing incomplete lines, or with synchronizing processing of new console events seen by different cygwin threads/processes, and it may be deemed unworthwhile (especially as it doesn't seem to be a frequently raised question), but to it seems doable. -- Cliff -- 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: Problem with select() on console
On 15 July 2010 12:57, Cliff Hones wrote: On Thu, Jul 15, 2010 at 01:44:19AM +0100, Cliff Hones wrote: When select() is used to test for input availability on the standard cygwin console in normal (cooked) mode, it indicates input is available as soon as any key is pressed. However, a call to read(0,...) will (correctly) block until a terminating RETURN is entered. select() should only indicate input is available when a call to read would *not* block - ie when a read call will immediately return at least one character or an error such as EOF. I'm surprised this hasn't come up more frequently. In my case, I have an app which needs to respond to user input line-based commands, but also does other processing. I don't want the app to block every time the user starts to enter a command. Of course I could use threads, but that's an unnecessary change (at least unnecessary on Linux etc). You could disable terminal line editing (with tcsetattr) and do the line processing yourself, or let the readline library do it all for you, which your users would proabably appreciate anyway. Readline's Alternate Interface allows you to interleave line input with other I/O. See http://tiswww.case.edu/php/chet/readline/readline.html#SEC41 I suspect readline() is the reason why this hasn't come up more frequently. 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: Tab Completion Problem - Solved
On 7/8/2010 9:08 AM, Jacob Jacobson wrote: I recently updated my Cygwin installation and now I get, [~$:501] cd /c/home/bash: exclude: unbound variable [~$:501] when I hit TAB. I have seen Eric's announcement followed that. A new release of bash-completion, 1.2-1, is now available for download, leaving 1.1-2 as previous. NEWS: = This is a new upstream release. I put - . /etc/bash_completion in my .bashrc file. The file /etc/bash_completion exists. Cygcheck output attached. Please help. This problem was due to set -o nounset line in my bashrc file. -- 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: {lp,cb}Reserved2 under Windows 7 and file descriptors
On Thu, Jul 15, 2010 at 12:25:09PM +0100, Andy Koppe wrote: On 15 July 2010 09:19, Corinna Vinschen wrote: Furthermore, there is a very long-standing issue with Cygwin pty devices: while Cygwin programs report true from isatty() when called on a Cygwin PTY, MSVCRT applications do *not*. Right. [...] However, due to the way the CRT works, we can fool it into thinking a passed-in file descriptor is actually a tty. All you need to do is use 3 for the value of *lpReserved2, then follow it with three flag bytes, then three HANDLE values --- corresponding respectively to flags[fd0], flags[fd1], flags[fd2] and fh[0], fh[fd1] and fh[fd2]. ??This information would be followed by the normal child_info structure. If stdin, stdout, or stderr is a Cygwin PTY, Cygwin can manually set the FDEV bit (described in the old MSDOS headers) in corresponding flag byte, which will make _isatty() return true in the child. (Not that I've actually tried it --- it's just an idea.) That sounds like an interesting idea. ??I'll play around with it as soon as I have a bit of spare time again. ??Unless, of course, nobody else will try it or already did... It would be brilliant if this did work, taking at least some of the sting out of the whole pty vs interactive console app issue. I actually have thought about doing this in the past but it always seemed to me that lying to a program about the ttyness of a file handle was going to cause more subtle problems than what we have currently. It also obviously isn't a panacea since not everything is going to use msvcrt file handles. If we really can create a standard file handle structure and not have to tweak it for the next five years and if we only fill it out for non-cygwin programs (which we do know when we're about to exec something) maybe it will be worth it. I think I'm going to need some real convincing though. Hmm. I wonder if anything else does this. Does MKS do something similar? 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: Problem with select() on console
On Thu, Jul 15, 2010 at 01:45:43PM +0100, Cliff Hones wrote: Cliff Hones wrote: I must look at the console source... And now I have, and I see that fhandler_console does its own line editing, so is perfectly aware of the input line state. So blocking as soon as any key is typed seems a shortcoming of cygwin, not windows? You could say that about just about everything that Cygwin has problems with. For instance, the fact that Cygwin's ptys aren't properly recognized by pure Windows programs is a limitation of Cygwin too. It really isn't an interesting distinction since it boils down to a cost/benefit situation. I see there may be a difficulty with storing incomplete lines, or with synchronizing processing of new console events seen by different cygwin threads/processes, and it may be deemed unworthwhile (especially as it doesn't seem to be a frequently raised question), but to it seems doable. The readahead stuff in fhandler_console.cc (which I wrote) was intended to be used for small amounts of data. Extending it to properly handle cooked mode would be quite an undertaking. Since, as Andy pointed out, most sophisticated applications used something like readline, this has not come up previously that I can recall. So, this is a PTC case. 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: Problem with select() on console
On Thu, Jul 15, 2010 at 09:54:21AM +0200, Matthias Andree wrote: Am 15.07.2010, 07:49 Uhr, schrieb Christopher Faylor: On Thu, Jul 15, 2010 at 01:44:19AM +0100, Cliff Hones wrote: When select() is used to test for input availability on the standard cygwin console in normal (cooked) mode, it indicates input is available as soon as any key is pressed. However, a call to read(0,...) will (correctly) block until a terminating RETURN is entered. select() should only indicate input is available when a call to read would *not* block - ie when a read call will immediately return at least one character or an error such as EOF. The behaviour of the following test case illustrates this. When run in a console window typing a single key causes the program to wait for the whole line. When run under mintty or on Linux the select() calls will continue to return no input until RETURN is entered. Since, AFAIK, Windows has no way to do this, I don't see how it could be done easily. You could, I guess, pull characters into a buffer until a newline was found but that would be pretty error-prone and any use of select() would potentially invalidate console i/o for subprocesses. So, I don't see this changing anytime soon. Is there a way to detect that the application is run from a Windows console rather than mintty? If so, cygwin1.dll could print a warning to the console, (something along the lines that running the application under some X11 terminal or mintty is advised) and return EINVAL, or abort the application, in either case if POSIXLY_CORRECT is set in the environment, much like some GNU tools will switch to a more POSIX compliant behaviour with that variable. Print a warning to the console if something uses select??? Nuh uh. This behavior has been in existence for more than ten years. I think I'll opt for explaining it once every ten years instead. 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: Sending SIGUSR1 to thread in nanosleep causes segfault
On Mon, Jul 12, 2010 at 11:36:04AM -0500, James Cotton wrote: Hello, I've been trying to get the FreeRTOS Posix simulator to run on Cygwin and have run into a few bugs in the signal handling/pthread libraries and have isolated test cases Essentially sending a SIGUSR1 to a pthread causes a segfault if that thread is in sleep/nanosleep/select. This behavior continues if you comment out the printing behavior. I believe at least nanosleep is meant to return when it receives a signal so this seems like a bug. Well, yes. A SIGSEGV in cygwin code is always a bug. I'm investigating. I see how it happens but not why yet. 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: Mirrors
On 13/07/2010 19:48, Nellis, Kenneth wrote: From: DePriest, Jason R. On Tue, Jul 13, 2010 at 9:49 AM, Tekerman Romanov wrote: Hi, I'm not able to find e-mail where I could ask Sourcemaster is also the place to send requests to be added to this list. Who is this sourcemaster? I am not putting it in this email because I don't want to be responsible for that address getting spammed. FWIW, there are lots of ways to show complete e-mail addresses on web pages such that they won't be recognized by spammers, e.g., Google: obfuscate email address Such a technique could have prevented a lot of postings. I'm inclined to agree. How about something like so: * smaster.gif: New file. * check-mirrors (makeweb): Add img tag referring to it. Suitable? cheers, DaveK Index: check-mirrors === RCS file: /cvs/cygwin/htdocs/check-mirrors,v retrieving revision 1.81 diff -p -u -r1.81 check-mirrors --- check-mirrors 21 Jul 2008 21:28:31 - 1.81 +++ check-mirrors 15 Jul 2010 01:12:33 - @@ -228,7 +228,7 @@ anyone about this./p pIf a site is listed here that seems to be out-of-date for more than a few days, that could mean that there is a problem. Contact emsourcemaster/em -at this site to report this potential problem. emsourcemaster/em is also the +at this site (img align=top src=smaster.gif) to report this potential problem. emsourcemaster/em is also the place to send requests to be added to this list./p EOF Index: smaster.gif === RCS file: smaster.gif diff -N smaster.gif Binary files /dev/null and smaster.gif differ smaster.gif.bz2 Description: Binary data -- 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: Colours used in mintty
Is there a way of changing the default text colours used by mintty for directories, links, executables, etc? From man mintty: use echo $'\e]4;3;255,255,0\a' and similarly, in a script. I am using echo $'\e]4;3;255, 0, 0\a' # color3 for devices echo $'\e]4;6;139, 69, 19\a' # color6 for links in .bashrc with the consequence that each new mintty terminal starts with 2 blank lines. Is there a way I can set the colors but suppress the newlines? Thank you. Fergus -- 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: gcc4: throwing exception from signal handler
On 09/07/2010 17:51, Christopher Faylor wrote: Someone may be looking into this but if this is adding complication to the signal handler it is going to take some real convincing that it should go into the DLL. :) Fortunately, it doesn't have to do that. All the magic takes place in libgcc's last-chance unwind fallback hook(*). The only impact on the DLL, in the design I've been experimenting with, is that we need to build it with EH unwind tables, add a cygwin_internal method to return a pointer to the EH data, and export a couple of entrypoints that libgcc needs to be able to look up. There are no changes in any of the signal/exception code paths, or at any rate I didn't yet find any need to change anything (I didn't finish getting it working before I put it aside though, so it's conceivable-but-low-probability that something might turn up). Dave, this is something that you should be talking about early rather than springing it as a patch in cygwin-patches. Sure, I was going to get a working PoC first because I wanted to convince myself it was possible, but no reason not to discuss it right now. Luckily I think there's very little to discuss. (I'll report what the EH data does to the DLL size when I've got the code up and running again, but since everyone's been waiting long enough, I guess the first thing I should do is get out a more vanilla-flavoured 4.5.0 release.) cheers, DaveK -- (*) - MD_FALLBACK_FRAME_STATE_FOR -- 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: Colours used in mintty
On 7/15/2010 10:18 AM, Fergus wrote: Is there a way of changing the default text colours used by mintty for directories, links, executables, etc? From man mintty: use echo $'\e]4;3;255,255,0\a' and similarly, in a script. I am using echo $'\e]4;3;255, 0, 0\a' # color3 for devices echo $'\e]4;6;139, 69, 19\a' # color6 for links in .bashrc with the consequence that each new mintty terminal starts with 2 blank lines. Is there a way I can set the colors but suppress the newlines? Have you tried using echo -n? -Jeremy -- 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: Colours used in mintty
Is there a way of changing the default text colours used by mintty for directories, links, executables, etc? From man mintty: use echo $'\e]4;3;255,255,0\a' and similarly, in a script. I am using echo $'\e]4;3;255, 0, 0\a' # color3 for devices echo $'\e]4;6;139, 69, 19\a' # color6 for links in .bashrc with the consequence that each new mintty terminal starts with 2 blank lines. Is there a way I can set the colors but suppress the newlines? Use echo -n. (Sorry for public soliloquy.) Fergus -- 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
Michael, did you ever find a fix for this? I had to give up on cygwin on the Amazon 64-bit and instead cobbled together freesshd and random freewares. Larry or others - what's the right way to report this as a bug? I think working on newer 64-bit OSes is pretty important... And it should be trivial to reproduce since the Amazon instances are publicly available; nobody has to actually buy them expensive licenses... Thanks, Ernest __ UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT information is ENCOURAGED. From: Michael Higgins michael.higg...@advancedinnovationsinc.com To: cygwin@cygwin.com Date: 06/30/2010 09:39 AM Subject:Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud Sent by:cygwin-ow...@cygwin.com I am unable to install Cygwin on a Windows Datacenter 2008 server image running in the Amazon Web Services cloud. The install process fails at the execution of the post install scripts with a bash segmentation fault and core dump. The scripts complete but do not actually do anything. Attempting to run them after the install produces the same result, script exit but no actions executed. Running the commands in the script one at a time from a shell window works, but this is not acceptable, especially for running the ssh host configuration script !! Things tried so far: running the setup script in compatibility modes, running the scripts after the install completes, running the scripts in bash or sh from the command line. Nothing makes any difference, the scripts fail to do the work required. This seems to be the same as a problem reported already this month, with the same Subject line. However I am opening this new thread, as Cygwin is 100% required on this server in our environment in order to enable Oracle Grid Control 11g to accept agent data from this server. This is a production level server running Oracle applications and I need urgent HELP solving this Cygwin install failure. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/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 -- 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: gcc4: throwing exception from signal handler
On 7/15/2010 11:42 AM, Dave Korn wrote: I guess the first thing I should do is get out a more vanilla-flavoured 4.5.0 release.) Err... 4.5.1? Does the ABI breakage between 4.5.0 and 4.5.1/4.6.0 mentioned wrt x86_64-mingw affect i386, or cygwin? -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
runas, su, sudo
Hi, Is there any (working) way to change privileges in cygwin? Regards, Luke -- 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: runas, su, sudo
On Thu, Jul 15, 2010 at 1:31 PM, Lukas Haase wrote: Hi, Is there any (working) way to change privileges in cygwin? Regards, Luke Try this: http://www.cygwin.com/faq/faq.using.html#faq.using.su It tells you to use s...@localhost but has a link to some mailing list archives that explain why su / sudo can't work properly. -Jason -- 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 7/15/2010 11:44 AM, Ernest Mueller wrote: Michael, did you ever find a fix for this? I had to give up on cygwin on the Amazon 64-bit and instead cobbled together freesshd and random freewares. Larry or others - what's the right way to report this as a bug? I think working on newer 64-bit OSes is pretty important... And it should be trivial to reproduce since the Amazon instances are publicly available; nobody has to actually buy them expensive licenses... Reporting this issue on the list is the right way to report the bug. -- 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: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
On Thu, Jul 15, 2010 at 10:44 AM, Ernest Mueller wrote: Michael, did you ever find a fix for this? I had to give up on cygwin on the Amazon 64-bit and instead cobbled together freesshd and random freewares. Larry or others - what's the right way to report this as a bug? I think working on newer 64-bit OSes is pretty important... And it should be trivial to reproduce since the Amazon instances are publicly available; nobody has to actually buy them expensive licenses... Thanks, Ernest It isn't all newer 64-bit OSes because I run Cygwin 1.7 on my Windows 7 Home Premium 64-bit OS with no problems at all. -Jason -- 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 7/15/2010 3:12 PM, DePriest, Jason R. wrote: On Thu, Jul 15, 2010 at 10:44 AM, Ernest Mueller wrote: Michael, did you ever find a fix for this? I had to give up on cygwin on the Amazon 64-bit and instead cobbled together freesshd and random freewares. Larry or others - what's the right way to report this as a bug? I think working on newer 64-bit OSes is pretty important... And it should be trivial to reproduce since the Amazon instances are publicly available; nobody has to actually buy them expensive licenses... Thanks, Ernest It isn't all newer 64-bit OSes because I run Cygwin 1.7 on my Windows 7 Home Premium 64-bit OS with no problems at all. Yup, good point. I should have pointed this out, since it's apparently not clear to Ernest and perhaps others. I, in fact, run Cygwin from Window 7 Ultamite x64 on my laptop. Whatever the issue is, it would be nice to have a recipe to reproduce it for Windows 2008 or 7 x64 without the Amazon tie-in. That would at least help localize the problem. :-) -- 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: Colours used in mintty
I am using echo $'\e]4;3;255, 0, 0\a' # color3 for devices Have you tried using echo -n? Don't get in the habit. Use printf(1) instead: printf %s %'\e]4;3;255, 0, 0\a' echo(1) is non-portable when it comes to options, and 'echo -n' will not behave the same on all shells; you are better off learning the portable alternative up front, in case you run into a situation where you aren't using bash. [I'll leave the fact that $'' is also a non-portable bash-ism for another discussion] -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Minimal setup to build apps from source?
I always hear some applications thrown out there that you should have to build software from source like gcc and vim, but is there a more complete list of what is required? I built up somewhat of a list for myself to track what I've installed, but there seems to be a lot of missing points. Some of the list is as follows (there is tons more, but this is what I feel this necessary as of now): ncureses libncurses-devel ncursesw libncursesw-devel make patchutils gcc gcc-mingw zip unzip xorg-server xinit inetutils (for telnet) openssh nano git cvs subversion ruby If I, and everybody else who needs, can get some help to atleast build some of the applications that everybody wishes that would be very beneficial! Thank you. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: nasm-2.08.02-1
The cygwin package of nasm has been updated to version 2.08.02. This is the latest stable upstream version available from http://nasm.us/ The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. In addition to the upstream changes noted below, the I have re-added the -f gnuwin32 output format switch to the Cygwin package, in order to retain compatibility with build scripts engineered around this previously-necessary workaround. It now behaves identically to -f win32 except that it uses a .o output extension. Excerpts from the upstream changelog, since 2.06: Version 2.08: - A number of enhancements/fixes in macros area. - Support for converting strings to tokens. - Fuzzy operand size logic introduced. - Fix COFF stack overrun on too long export identifiers. - Fix Macho-O alignment bug. - Fix crashes with -fwin32 on file with many exports. - Fix stack overrun for too long [DEBUG id]. - Fix incorrect sbyte usage in IMUL (hit only if optimization flag passed). - Append ending token for .stabs records in the ELF output format. - New NSIS script which uses ModernUI and MultiUser approach. - Visual Studio 2008 NASM integration (rules file). - Warn a user if a constant is too long (and as result will be stripped). - The obsoleted pre-XOP AMD SSE5 instruction set which was never actualized was removed. - Fix stack overrun on too long error file name passed from the command line. - Bind symbols to the .text section by default (ie in case if SECTION directive was omitted) in the ELF output format. - Fix sync points array index wrapping. - A few fixes for FMA4 and XOP instruction templates. - Add AMD Lightweight Profiling (LWP) instructions. - Fix the offset for %arg in 64-bit mode. - An undefined local macro (%$) no longer matches a global macro with the same name. - Fix NULL dereference on too long local labels. Version 2.07 - NASM is now under the 2-clause BSD license. - Fix the section type for the .strtab section in the elf64 output format. - Fix the handling of COMMON directives in the obj output format. - New ith and srec output formats; these are variants of the bin output format which output Intel hex and Motorola S-records, respectively. - rdf2ihx replaced with an enhanced rdf2bin, which can output binary, COM, Intel hex or Motorola S-records. - The Windows installer now puts the NASM directory first in the PATH of the NASM Shell. - Revert the early expansion behavior of %+ to pre-2.06 behavior: %+ is only expanded late. - Yet another Mach-O alignment fix. - Don't delete the list file on errors. Also, include error and warning information in the list file. - Support for 64-bit Mach-O output. - Fix assert failure on certain operations that involve strings with high-bit bytes. -- Dean *** 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://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: Minimal setup to build apps from source?
On 7/15/2010 8:17 PM, Monte Cabet wrote: I always hear some applications thrown out there that you should have to build software from source like gcc and vim, but is there a more complete list of what is required? I built up somewhat of a list for myself to track what I've installed, but there seems to be a lot of missing points. Some of the list is as follows (there is tons more, but this is what I feel this necessary as of now): snipped list of packages Cygwin already provides If I, and everybody else who needs, can get some help to atleast build some of the applications that everybody wishes that would be very beneficial! Thank you. It's not really clear to me what you're asking for but if you're just looking for these packages, you can get them (and many others) pre-built by installing them using 'setup.exe' from cygwin.com. If instead you want to know what packages are prerequisites to build a package, that's information that you get from the package of interest. Check out its documentation. But there's no complete list of prerequisites unless you consider all possible packages a valid response. -- 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
Updated: nasm-2.08.02-1
The cygwin package of nasm has been updated to version 2.08.02. This is the latest stable upstream version available from http://nasm.us/ The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler designed for portability and modularity. In addition to the upstream changes noted below, the I have re-added the -f gnuwin32 output format switch to the Cygwin package, in order to retain compatibility with build scripts engineered around this previously-necessary workaround. It now behaves identically to -f win32 except that it uses a .o output extension. Excerpts from the upstream changelog, since 2.06: Version 2.08: - A number of enhancements/fixes in macros area. - Support for converting strings to tokens. - Fuzzy operand size logic introduced. - Fix COFF stack overrun on too long export identifiers. - Fix Macho-O alignment bug. - Fix crashes with -fwin32 on file with many exports. - Fix stack overrun for too long [DEBUG id]. - Fix incorrect sbyte usage in IMUL (hit only if optimization flag passed). - Append ending token for .stabs records in the ELF output format. - New NSIS script which uses ModernUI and MultiUser approach. - Visual Studio 2008 NASM integration (rules file). - Warn a user if a constant is too long (and as result will be stripped). - The obsoleted pre-XOP AMD SSE5 instruction set which was never actualized was removed. - Fix stack overrun on too long error file name passed from the command line. - Bind symbols to the .text section by default (ie in case if SECTION directive was omitted) in the ELF output format. - Fix sync points array index wrapping. - A few fixes for FMA4 and XOP instruction templates. - Add AMD Lightweight Profiling (LWP) instructions. - Fix the offset for %arg in 64-bit mode. - An undefined local macro (%$) no longer matches a global macro with the same name. - Fix NULL dereference on too long local labels. Version 2.07 - NASM is now under the 2-clause BSD license. - Fix the section type for the .strtab section in the elf64 output format. - Fix the handling of COMMON directives in the obj output format. - New ith and srec output formats; these are variants of the bin output format which output Intel hex and Motorola S-records, respectively. - rdf2ihx replaced with an enhanced rdf2bin, which can output binary, COM, Intel hex or Motorola S-records. - The Windows installer now puts the NASM directory first in the PATH of the NASM Shell. - Revert the early expansion behavior of %+ to pre-2.06 behavior: %+ is only expanded late. - Yet another Mach-O alignment fix. - Don't delete the list file on errors. Also, include error and warning information in the list file. - Support for 64-bit Mach-O output. - Fix assert failure on certain operations that involve strings with high-bit bytes. -- Dean *** 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://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
