RE: [ITP] run.exe was Re: Running ssh in background[solution/patch]
Alexander Gottwald wrote on Wednesday, October 26, 2005 7:00 PM: On Wed, 2005-10-26 at 18:49 +0200, Alexander Gottwald wrote: run.exe is often used from Windows shortcuts to start programs like XWin. Even the X-start-menu-icons uses it this way, A shortcut will not work. To clarify this: X-start-menu-icons won't be a showstopper since it can be easily adjusted. I'm more concerned about the shortcuts on user X's desktop like those on mine: [snip] Why don't drop it into /bin as well as in /usr/X11R6/bin ? Modern X11 distributions will eliminate the X11RX directory anyway and so might do the Cygwin version in some time. - Jörg
xorg upload ready (but need space)
Does anyone have website or ftp space available to upload the xorg packages too temporarily until they are moved to sourceware ? They are around 70Mb of files. Alan.
g-b-s and bin dir
I'm attempting to create my first Cygwin package, and decided to use the
generic-build-script method.
The package is ctags (http://ctags.sourceforge.net/), which builds just
fine out of the box. With a bit of scripting [*] I have the build
process automated. Problem is, the generated binary tarball has no
binaries in it. It only has usr/share/doc/*. I don't see the binaries
in ctags-$VER/.inst/usr/bin, either.
I don't know if this is because of some nonstandardness in the ctags
autoconf setup, or if g-b-s is not passing the right options to the
configure script.
Exuberant Ctags uses autoconf only; no automake. The install target in
the top-level Makefile puts the binaries in $(bindir), which is set from
the corresponding autoconf variable. As g-b-s runs configure, ${bindir)
ends up being /usr/bin, so when the g-b-s inst step runs, the binaries
go to /usr/bin, not to $UNPACKED_TARBALL/.inst/usr/bin.
Who is at fault here, and how do I fix it?
[*] I've attached the build script I'm using. It's a driver for g-b-s,
to handle things that I think g-b-s should handle already. Whoever is
maintaining g-b-s these days can feel free to rob whatever code they
want from this.
With this interface, you just say ./build ctags 5.5.4 1 to create
ctags-5.5.4-1[-src].tar.bz2. It requires that you have a README file in
the current directory, which is based on the generic README file from
the cygwin.com docs; the build script does variable replacement in it
for package name, version number, and release number. I've attached my
original README file so you can see what the build script has to work
with. The build script also requires that the original source tarball
be in the current directory.
This mechanism works best if you have a directory dedicated to a given
package. I use ~/src/ctags, for instance. The build script, the
README, and any tarballs are here.
#!/bin/sh
if [ $# -lt 3 ]
then
echo usage: $0 pkg version release
echo
exit 1
fi
PKG=$1
VER=$2
REL=$3
ID1=$PKG-$VER
ID2=$PKG-$VER-$REL
TARBALL=$ID1.tar.gz
SRCID=$ID2-src.tar.bz2
BUILD=./$ID2.sh
if [ ! -e $TARBALL ]
then
echo Could not find tarball: $TARBALL
echo
exit 1
fi
rm -rf $ID1
tar xvzf $TARBALL
mkdir $ID1/CYGWIN-PATCHES
sed -e s/PKG/$PKG/g -e s/VER/$VER/g -e s/REL/$REL/g README
$ID1/CYGWIN-PATCHES/$PKG.README
$BUILD mkdirs $BUILD spkg
( cp $SRCID /tmp cd /tmp tar xjf $SRCID $BUILD all )
mv /tmp/$ID2.tar.bz2 . rm -f /tmp/$PKG-*
Exuberant Ctags
--
Exuberant Ctags is an indexing and cross-reference tool for many
programming languages. It is typically used in conjunction with a
programmer's text editor, such as Vim or Emacs.
Runtime requirements:
Should work with any version of Cygwin.
Build requirements:
A bare Cygwin installation plus gcc should suffice.
Canonical homepage:
http://ctags.sourceforge.net/
Canonical download:
http://prdownloads.sourceforge.net/ctags/PKG-VER.tar.gz
License:
GPL
Language:
Written in C. Works with source code for any of 33 different
programming languages, as of this writing.
Build instructions:
unpack PKG-VER-REL-src.tar.bz2
if you use setup to install this src package, it will be
unpacked under /usr/src automatically
cd /usr/src
./PKG-VER-REL.sh all
This will create:
/usr/src/PKG-VER-REL.tar.bz2
/usr/src/PKG-VER-REL-src.tar.bz2
Or use './PKG-VER-REL.sh prep' to get a patched source directory
To find out the files included in the binary distribution, you can
use cygcheck -l PKG, or browse the listing for the appropriate version
at http://cygwin.com/packages/.
--
Port Notes:
Official distribution builds out of the box. No changes required.
For more information about this package, see the upstream documentation in
/usr/share/doc/PKG-VER.
Cygwin port maintained by Warren Young warren at etr dash usa dot com
Please address all questions to the Cygwin mailing list at cygwin@cygwin.com
Re: xorg upload ready (but need space)
On Oct 27 10:51, Alan Hourihane wrote: Does anyone have website or ftp space available to upload the xorg packages too temporarily until they are moved to sourceware ? They are around 70Mb of files. You have an account on sourceware and upload rights. Just scp your stuff to your home dir or /tmp (there's more than enough space on both disks) and when that went fine, move it over to the appropriate spot in the release directory (below /sourceware/ftp/anonftp/pub/cygwin/release/X11). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: g-b-s and bin dir
Warren Young wrote:
the corresponding autoconf variable. As g-b-s runs configure, ${bindir)
ends up being /usr/bin, so when the g-b-s inst step runs, the binaries
go to /usr/bin, not to $UNPACKED_TARBALL/.inst/usr/bin.
Most standard autoconf/automake-generated configure scripts support the
use of DESTDIR for the make install step. This lets you use the
desired --prefix=/usr but divert the destination at the final install
step by doing make install DESTDIR=/some/path, causing the tree to be
installed to /some/path rather than /usr. But note that the package is
otherwise still configured to be installed in /usr, so for example if
there are any hard coded paths they will reference /usr and not
/some/path.
I think this is what the GBS uses to redirect the install to the .inst
dir. If the ctags configure script does not have this capability then
you will have to do one of:
1. Manually recreate the install tree by copying stuff out of /usr and
into .inst/ for inclusion in the binary package.
2. Patch configure.ac/.in to honor $DESTDIR for the install target and
regenerate.
3. Configure with --prefix=/some/temp/packaging/path/.inst and hope that
this prefix is not hard coded anywhere in any files.
#3 is risky but probably okay for very simple packages. #1 is easy but
clumsy. #2 requires that you maintain local patches to configure.ac,
and re-run autoconf to rebuild generated files.
This last point touches on another issue: Do you include patches to
generated files in the source package? One school of thought says that
you do since it's simpler and the end user that builds the package
doesn't have to worry about having the correct version of
autoconf/automake/libtool installed. However this can result in huge
(multiple-megabyte) patches since the generated files can often be quite
large, and it really obscures the actual patches (if any) from the noise
of the diffs in generated files.
The other school of thought is that you should only include patches to
the configure.ac (and other primary source files), and modify the build
script to first run autoreconf to regenerate everything before
configuring. This makes for nice, small, easy to inspect patches, but
the user building the package from source must have the proper developer
tools installed and must know to either run autoreconf or use your build
script.
Brian
Please upload: xorg-*-6.8.99.901
A new release of the xorg-* binaries are available for upload. This coincides with X.Org 6.9/7.0 RC1 (release candidate 1) I'm not sure how or whether packages are identified as test packages anymore through setup, but they should be marked so if possible. Files are at :- http://www.mathematik.uni-kl.de/~wienand/xorg Thanks to Oliver Wienand for the temporary upload space. Alan.
Re: Please upload: xorg-*-6.8.99.901
On Oct 27 12:56, Alan Hourihane wrote: A new release of the xorg-* binaries are available for upload. This coincides with X.Org 6.9/7.0 RC1 (release candidate 1) I'm not sure how or whether packages are identified as test packages anymore through setup, but they should be marked so if possible. Files are at :- http://www.mathematik.uni-kl.de/~wienand/xorg http://cygwin.com/setup.html http://cygwin.com/ml/cygwin-apps/2005-10/msg00264.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: xorg upload ready (but need space)
On Thu, 2005-10-27 at 13:49 +0200, Corinna Vinschen wrote: On Oct 27 10:51, Alan Hourihane wrote: Does anyone have website or ftp space available to upload the xorg packages too temporarily until they are moved to sourceware ? They are around 70Mb of files. You have an account on sourceware and upload rights. Just scp your stuff to your home dir or /tmp (there's more than enough space on both disks) and when that went fine, move it over to the appropriate spot in the release directory (below /sourceware/ftp/anonftp/pub/cygwin/release/X11). I keep forgetting about that. I'll remember next time. Thanks Corinna. Alan.
Re: Please upload: xorg-*-6.8.99.901
On Thu, 2005-10-27 at 14:01 +0200, Corinna Vinschen wrote: On Oct 27 12:56, Alan Hourihane wrote: A new release of the xorg-* binaries are available for upload. This coincides with X.Org 6.9/7.0 RC1 (release candidate 1) I'm not sure how or whether packages are identified as test packages anymore through setup, but they should be marked so if possible. Files are at :- http://www.mathematik.uni-kl.de/~wienand/xorg http://cygwin.com/setup.html http://cygwin.com/ml/cygwin-apps/2005-10/msg00264.html Yep, uploading myself to sourceware now. They'll be in-place in the next hour. Alan.
Re: g-b-s and bin dir
Brian Dessent wrote: Most standard autoconf/automake-generated configure scripts support the use of DESTDIR for the make install step. Ah. Then I think I can fix this by making ctags' Makefile.in honor DESTDIR. Tiny patch with low impact, so likely to be accepted upstream.
[ITP] gnubg: A backgammon player and analysis tool
Hi I would like to contribute and maintain the gnubg package: * http://www.gnu.org/software/gnubg/gnubg.html (Homepage) * ftp://alpha.gnu.org/gnu/gnubg/ (Download location) Ciao Volker -- Here is the setup.hint file: sdesc: A backgammon player and analysis tool ldesc: GNU Backgammon (gnubg) plays and analyses backgammon games and matches. It is currently a work-in-progress. So far it is able to play both independent games and tournament matches, evaluate and roll out positions, tune its own evaluation functions using either TD or supervised training, maintain databases of positions for training and other purposes, and more. It is driven by a command-line interface, and displays an ASCII rendition of a board on text-only terminals, but also allows the user to play games and manipulate positions with a GTK+ board window where available. It is extensible on platforms which support Guile and/or Python. It currently plays at about the level of a championship flight tournament player (depending on its parameters and its luck in recent games, it rates at around 2000 on FIBS, the First Internet Backgammon Server - at its best, it is in the top 5 of over 6000 rated players there) and is gradually improving; it should be somewhat stronger than this when released. GNU Backgammon can be played at numerous other online backgammon servers. category: Games requires: cygwin gmp gtk2-x11-runtime libart_lgpl libesound0 libfreetype26 libgdbm4 libguile12 libintl3 libpng12 libreadline6 libxml2 python xorg-x11-bin-dlls cut here #!/bin/bash mkdir gnubg cd gnubg wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/gnubg/setup.hint wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/gnubg/gnubg-0.14.3-1-src.tar.bz2 wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/gnubg/gnubg-0.14.3-1.tar.bz2 cut here
xorg-x11-fcyr/xorg-x11-fnts packaging error
I'm getting email about this: upset: *** warning package xorg-x11-fcyr refers to non-existent external-source: xorg-x11-fnts xorg-x11-fcyr contains an external-source line but, unfortunately, upset will only recognize source packages that are actually included in the distribution. That means that upset will not find xorg-x11-fnts-6.8.1.0-2.tar.bz2 since the xort-x11-fnts setup.hint file only mentions 6.8.1.0-3 and 6.8.99.901-1. I've added a prev: 6.8.1.0-2 to the setup.hint for xorg-x11-fnts, which fixes the problem. However, shouldn't the curr release xorg-x11-fcyr be at 6.8.1.0-3, like xorg-x11-fnts? cgf
Re: xorg-x11-fcyr/xorg-x11-fnts packaging error
On Thu, 27 Oct 2005, Christopher Faylor wrote: However, shouldn't the curr release xorg-x11-fcyr be at 6.8.1.0-3, like xorg-x11-fnts? Actually the xorg-x11 packages are not built from the -src files but from a CVS checkout becuase of the monolitic structure. The correct solution would be one large -src file and several bin packages which must all be updated even if only a small package like xorg-x11-xwin has changed. In fact, the font packages are still on version 6.8.1 while the binaries have been updated to 6.8.2 in the meantime, but the fonts were kept at the older version to save unnecessary downloads. Same for the fnts and fcyr package. fnts has been changed (a small tool for updating the font indices) but fcyr has not, so I did not pull it to the newer version. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: xorg-x11-fcyr/xorg-x11-fnts packaging error
On Thu, 2005-10-27 at 10:25 -0400, Christopher Faylor wrote: I'm getting email about this: upset: *** warning package xorg-x11-fcyr refers to non-existent external-source: xorg-x11-fnts xorg-x11-fcyr contains an external-source line but, unfortunately, upset will only recognize source packages that are actually included in the distribution. That means that upset will not find xorg-x11-fnts-6.8.1.0-2.tar.bz2 since the xort-x11-fnts setup.hint file only mentions 6.8.1.0-3 and 6.8.99.901-1. I've added a prev: 6.8.1.0-2 to the setup.hint for xorg-x11-fnts, which fixes the problem. However, shouldn't the curr release xorg-x11-fcyr be at 6.8.1.0-3, like xorg-x11-fnts? I'm not sure why fnts is bumped at -3 and fcyr at -2 as it's been that way for quite some time. Given that your fix works we can either stick with that, or just copy the fcyr -2 package to -3 and remove the prev: keyword. Which do you prefer Chris ? Alan.
Cygwin X-Windows Crestron SimplWindows Cross Compiler clashing
Neither will work while the other is installed. For testing purposes: Cygwin error message when running startxwin.bat: A fatal error has occurred and Cygwin/X will now exit. Please open /tmp/XWin.log for more information. Vendor: The Cygwin/X Project Release: 6.8.2.0-4 Contact: cygwin-xfree@cygwin.com XWin was started with the following command-line: /cygdrive/d/Cygwin/usr/X11 -multiwindow -clipboard -silent-dup-error SimplWindows error message while compiling a project: Could not copy SIMPL + output file to [dir path][filename].spl. I've noticed that both Cygwin and Crestron SimplWindows share the same directory in the registery keys which is HKEY_CURRENT-USER Software Cygnus Solutions Cygwin. The SimplWindows however adds the additional directory / to the registry so we have Cygwin mounts V2 /. This contains keys: (Default) flags native which points to D:\Crestron\ColdFire I've found that exporting the registry configurations for each and then importing them does nothing however. I've also noticed that when I run Cygwin's setup.exe it thinks that D:\Crestron\ColdFire is the root directory I selected for the previous instal of Cygwin. -- 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: Cygwin X-Windows Crestron SimplWindows Cross Compiler clashing
On Thu, Oct 27, 2005 at 11:45:06AM -0600, Matthew Snow wrote: Neither will work while the other is installed. For testing purposes: Cygwin error message when running startxwin.bat: A fatal error has occurred and Cygwin/X will now exit. Please open /tmp/XWin.log for more information. Vendor: The Cygwin/X Project Release: 6.8.2.0-4 Contact: cygwin-xfree@cygwin.com XWin was started with the following command-line: /cygdrive/d/Cygwin/usr/X11 -multiwindow -clipboard -silent-dup-error SimplWindows error message while compiling a project: Could not copy SIMPL + output file to [dir path][filename].spl. I've noticed that both Cygwin and Crestron SimplWindows share the same directory in the registery keys which is HKEY_CURRENT-USER Software Cygnus Solutions Cygwin. The SimplWindows however adds the additional directory / to the registry so we have Cygwin mounts V2 /. This contains keys: (Default) flags native which points to D:\Crestron\ColdFire I've found that exporting the registry configurations for each and then importing them does nothing however. I've also noticed that when I run Cygwin's setup.exe it thinks that D:\Crestron\ColdFire is the root directory I selected for the previous instal of Cygwin. This is just a WAG, but it sounds like Crestron is using cygwin for its' underlying functionality. If this is true, you need to contact Crestron for support. None of the cygwin people that I know of (as wonderfully helpful as they are) are willing to support third party applications. Regards, 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/
Missing dll's in new package [was Re: Please upload: xorg-*-6.8.99.901]
On 10/27/05, Alan Hourihane wrote: Yep, uploading myself to sourceware now. They'll be in-place in the next hour. Alan, I've taken the opportunity to evaluate the new package. Prior versions of Cygwin/Xorg provided the dlls and development files for the libDPS interface. For some reason, they were omitted in this release. I've been hunting through the Imake config files, and I cannot understand why they weren't built. Perhaps this is a problem in the packaging script? Cheers, Nicholas -- 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/mingw ChangeLog Makefile.in include ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-10-27 21:21:58 Modified files: winsup/mingw : ChangeLog Makefile.in winsup/mingw/include: _mingw.h Log message: 2005-10-27 Chris Sutcliffe [EMAIL PROTECTED] * Include/_mingw.h: Increment version to 3.9. * Makefile.in: Ditto. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog.diff?cvsroot=srcr1=1.291r2=1.292 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/Makefile.in.diff?cvsroot=srcr1=1.57r2=1.58 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/include/_mingw.h.diff?cvsroot=srcr1=1.40r2=1.41
src/winsup/w32api ChangeLog Makefile.in includ ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-10-27 23:28:21 Modified files: winsup/w32api : ChangeLog Makefile.in winsup/w32api/include: w32api.h Log message: 2005-10-27 Chris Sutcliffe [EMAIL PROTECTED] * include/w32api.h: Increment version to 3.4. * Makefile.in: Ditto. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.692r2=1.693 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/Makefile.in.diff?cvsroot=srcr1=1.34r2=1.35 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/w32api.h.diff?cvsroot=srcr1=1.23r2=1.24
Re: Accessing signal context from a handler
On Wed, Oct 26, 2005 at 05:56:15PM -0400, Christopher Faylor wrote: On Wed, Oct 26, 2005 at 09:36:53PM +, Adam Irawan wrote: Igor Pechtchanski pechtcha at cs.nyu.edu writes: On Mon, 15 Jul 2002, Christopher Faylor wrote: On Mon, Jul 15, 2002 at 01:00:23PM -0400, Igor Pechtchanski wrote: Does Cygwin allow accessing the context (register state, etc) of the faulted instruction from a signal handler installed by sigaction(), similar to ucontext/mcontext in Linux? [snip] It's not available. cgf [snip snip] Basically, I'm trying to port an application that intercepts SIGSEGV and makes decisions based on the IP of the faulted instruction. The application currently uses the sigaction/ucontext mechanism in Linux. Any suggestions on how to do this in Cygwin (preferably similar to the Linux code, to maximize reuse) would be appreciated. [snipped the code bit] Wow, dug up an ancient post today that seems to relate to my current problem more than anything else I've searched for. Just wondering, has there been changes regarding this topic at all? Thanks alot, It's not available. cgf You left out the bit where ucontext used to not be passed at all, but in current snapshots it's passed as a null pointer... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Invalid argument error when using recvfrom
On Oct 26 13:57, Fernando Barsoba wrote: Hi all, Using raw sockets with cygwin is being really painful... After being able to create an IP datagram using the latest snapshot now I'm getting the error Invalid argument when calling recvfrom() without doing BIND first. There is no need to call bind() before recvfrom when using raw sockets. Why am i getting this error now? Some restriction with winsock? Probably. When using raw sockets with Cygwin, you're really in the hands of Winsock, which has a couple of restrictions in that matter. I'd suggest to have a look into MSDN which elaborates a bit on the usage of raw sockets. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
rxvt and 'pointerBlank'
I've just discovered that the 'pointerBlank true' setting for rxvt seems to work only for mice connected via USB and has no effect for PS/2 connections. Can anyone confirm this or offer a suggestion? I've tried using several different mice (Logitech, MS Intellimouse, etc.) on Windows 2000 systems, with and without third-party drivers, and still end up with a visible cursor. The problem isn't evident on Linux or BSD systems with the same hardware. For the moment, I've resorted to changing the colour of my mouse pointer to the same colour as my terminal, but that workaround is proving to be somewhat unsatisfactory. Thanks. -- George -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
tar 1.15.1 broken
This is probably just for Eric Blake, but I thought I'd let others know. I'm currently packaging a new xorg release for cygwin. I only ever build directly on my WinXP box for this too. Now, having upgraded everything to the latest releases things started to go wrong with the packaging scripts. tar started to bleat with Cannot stat: No such file or directory for lots of different things. I've reverted to tar 1.13.25 and everything is fine. One other thing to note is that I'm building on a samba connected drive if that matters to tar. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: AllVersions: Running Cygwin X w/ Registy Entries
Thorsten Kampe wrote: * Chris Taylor (2005-10-26 17:38 +0100) Thorsten Kampe wrote: * Christopher Faylor (2005-10-26 15:37 +0100) On Wed, Oct 26, 2005 at 10:26:36AM +0100, Thorsten Kampe wrote: * [EMAIL PROTECTED] (2005-10-26 00:45 +0100) Quoting Igor Pechtchanski [EMAIL PROTECTED]: See man mount. Please, please, please don't manipulate the registry directly if you want to stay portable. You can easily create a batch file to reproduce the mounts properly. ... User mounts is the answer. The CURRENT_USER tree is usually writable. Make sure you don't write over the existing settings if they are present. Current XP computers I am trying to run this into give me: Registry Editing has been Disabled by your administrator. even if I try to write to Current_User All I am trying to keep portable is the X server thus XWIN.exe is the only executable I have, the only one I execute. After running the X server as the background server I am tunneling the packets using Putty / Securecrt. Try regedit /s in a batch (instead of double clicking). This sometimes works. Or, I dunno, if that works, you could just use mount and forget about regedit entirely. It's a crazy idea, I know. I wonder why no one has thought of it before. *I* didn't know about it (because I was under the impression that all cygwin programs depend on the mount tables). Well, obviously there are a few that don't (mount, cygcheck, ash (?), etc.?) And I think it's easier to just import a reg file than dealing with multiple mount commands... Problem with that is that if the sysadmin knows what he's doing, it only takes about 4 seconds to block off almost all possible ways of actually editing the registry... Definitely not. As a user running programs you are almost constantly changing the registry (your HKEY_CURRENT_USER). So often importing a .reg file is not allowed (by double clicking) and starting regedit in GUI mode. When I say editing the registry, I'm talking about the ability to directly manipulate it with .reg files, regedit, or other registry editing tools. Yes, you are able to make changes to HKCU, but not *directly*. Your method is flawed and destroys the existing setup, which is bad. I disable ALL aspects of regedit and other tools, and I know I'm not alone in this. It's perfectly normal and *common* to do it. A batch file that checks for an existing mount table and saves it, then mounts it according to what you want is far, far better. This batch file is registry editing, too. If you edit the registry or the mount command - that's no difference from a sysadmin's point of view. It's not *directly* editing the registry. As a sysadmin, I'm telling you it *is* different. The (l)user should *never* be allowed to edit the registry themselves. That's a recipe for disaster. In my book, this includes so-called junior sysadmins/techs/whatever. Using a command that alters the registry as part of it's function, but does not allow the user to directly alter it is a very different ballgame. mount would be permissable. Some console app to directly edit the registry would not be. -- Spinning complacently in the darkness, covered and blinded by a blanket of little lives, false security has lulled the madness of this world into a slumber. Wake up! An eye is upon you, staring straight down and keenly through, seeing all that you are and everything that you will never be. Yes, an eye is upon you, an eye ready to blink. So face forward, with arms wide open and mind reeling. Your future has arrived... Are you ready to go? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: AllVersions: Running Cygwin X w/ Registy Entries
Dave Korn wrote: Thorsten Kampe wrote: * Chris Taylor (2005-10-26 17:38 +0100) Problem with that is that if the sysadmin knows what he's doing, it only takes about 4 seconds to block off almost all possible ways of actually editing the registry... Definitely not. Oh yes it does. Start-Run-regedit. Right-click the user's tree under HKEY_USERS, choose Permissions, remove their write access leaving them a read-only per-user registry tree. Easily done in 4 seconds by an experienced BOFH, and can't be reversed without admin rights! cheers, DaveK Thankyou for proving my point Dave. Does anyone else feel Thorsten should let this go now, before we all lose any semblance of respect for him as a person? (Or did that already happen to the rest of you?) Chris -- Spinning complacently in the darkness, covered and blinded by a blanket of little lives, false security has lulled the madness of this world into a slumber. Wake up! An eye is upon you, staring straight down and keenly through, seeing all that you are and everything that you will never be. Yes, an eye is upon you, an eye ready to blink. So face forward, with arms wide open and mind reeling. Your future has arrived... Are you ready to go? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: AllVersions: Running Cygwin X w/ Registy Entries
Thorsten Kampe wrote: * Dave Korn (2005-10-26 19:45 +0100) Thorsten Kampe wrote: * Chris Taylor (2005-10-26 17:38 +0100) Problem with that is that if the sysadmin knows what he's doing, it only takes about 4 seconds to block off almost all possible ways of actually editing the registry... Definitely not. Oh yes it does. Start-Run-regedit. Right-click the user's tree under HKEY_USERS, choose Permissions, remove their write access leaving them a read-only per-user registry tree. Easily done in 4 seconds by an experienced BOFH, and can't be reversed without admin rights! Yea, sure. And how many programms will you be able to run in that configuration? Will you even be able to logon? Anyway: mount won't work in that scenario either (because it modifies the registry). I can't say about mount, but pretty much any program will work, logging on will not be an issue. You just won't be able to change _anything_ in your logins setup that depends on the registry. This is an important point. You'd basically be able to create new favourites (unless said BOFH had disabled that too - not hard), and new documents in your home drive / shared work area. Chris -- Spinning complacently in the darkness, covered and blinded by a blanket of little lives, false security has lulled the madness of this world into a slumber. Wake up! An eye is upon you, staring straight down and keenly through, seeing all that you are and everything that you will never be. Yes, an eye is upon you, an eye ready to blink. So face forward, with arms wide open and mind reeling. Your future has arrived... Are you ready to go? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: AllVersions: Running Cygwin X w/ Registy Entries
Chris Taylor wrote: When I say editing the registry, I'm talking about the ability to directly manipulate it with .reg files, regedit, or other registry editing tools. You can block access to certain known tools like regedit. This does *nothing* to block access to the registry itself, except for amateur users that think regedit is the only way to access the registry. Registry keys are full NT objects each with their own ACL, and so if you *really* want to prevent someone from being able to edit the registry, this is the *only* way. And doing so breaks lots of programs that expect to be able to store their settings in HKCU. I suppose you could allow specific write access to those keys that known programs need to access, and deny everything else. But that would be an enormous amount of work, and by the time you're done you'd have granted access to a large portion of HKCU. The point here is that regedit is only *one* way of arbitrarily manipulating the registry, and a user that knows what he's doing will *always* be able to get around this. Disabling regedit is *not* a form of security, unless you define security as keeping out casual users but nothing else. Yes, you are able to make changes to HKCU, but not *directly*. echo 1 /proc/registry/HKEY_CURRENT_USER/Software/Foobar Oh look, I just edited the registry directly. Okay, so you don't allow Cygwin. So I compile a C program that takes a key+value on the command line and calls RegSetValueEx(). Oh, so you disallow that filename or checksum. So I make a different C program and call it something else. There are an infinite number of programs that I can write and it's impossible to block them all. The point here is that there is no such thing as blocking direct access while still letting some programs write to the registry. Either it's writeable or it's not. If it is, then the user can make arbitrary changes. There's no middle ground. Your method is flawed and destroys the existing setup, which is bad. I disable ALL aspects of regedit and other tools, and I know I'm not alone in this. It's perfectly normal and *common* to do it. You can disable every piece of software that has ever existed in the known universe, and I will still be able to make arbitrary registry changes if I want -- provided that the desired HKCU key is writeable. The (l)user should *never* be allowed to edit the registry themselves. That's a recipe for disaster. If you think it is possible to block direct editing of the registry while still allowing HKCU to be writeable, then you are clearly mistaken at how windows security works. Using a command that alters the registry as part of it's function, but does not allow the user to directly alter it is a very different ballgame. mount would be permissable. Some console app to directly edit the registry would not be. There is absolutely no way for a sysadmin to block one and not the other. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: AllVersions: Running Cygwin X w/ Registy Entries
Chris Taylor wrote: It's not *directly* editing the registry. As a sysadmin, I'm telling you it *is* different. The (l)user should *never* be allowed to edit the registry themselves. That's a recipe for disaster. In my book, this includes so-called junior sysadmins/techs/whatever. No one should be allowed to make software which puts the (l)user in the position of having to use registry tools. But, this will not happen. For example, it is practically impossible to use Windows outside a corporate environment without installing something from SBC which habitually messes up the registry. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: AllVersions: Running Cygwin X w/ Registy Entries
Brian Dessent wrote: Chris Taylor wrote: When I say editing the registry, I'm talking about the ability to directly manipulate it with .reg files, regedit, or other registry editing tools. You can block access to certain known tools like regedit. This does *nothing* to block access to the registry itself, except for amateur users that think regedit is the only way to access the registry. You can, as per your next paragraph. Registry keys are full NT objects each with their own ACL, and so if you *really* want to prevent someone from being able to edit the registry, this is the *only* way. And doing so breaks lots of programs that expect to be able to store their settings in HKCU. I suppose you could allow specific write access to those keys that known programs need to access, and deny everything else. But that would be an enormous amount of work, and by the time you're done you'd have granted access to a large portion of HKCU. Yes, though most programs will silently fail if they can't save their settings. Most don't actually require you to have access of certain levels to function, at least that are commonly used in a corporate environment. Ideally you should have - perhaps restricted to the software key though, and with the Windows section read only. The point here is that regedit is only *one* way of arbitrarily manipulating the registry, and a user that knows what he's doing will *always* be able to get around this. Disabling regedit is *not* a form of security, unless you define security as keeping out casual users but nothing else. Indeed. Hence the ACLs. Yes, you are able to make changes to HKCU, but not *directly*. echo 1 /proc/registry/HKEY_CURRENT_USER/Software/Foobar Oh look, I just edited the registry directly. Okay, so you don't allow Cygwin. So I compile a C program that takes a key+value on the command line and calls RegSetValueEx(). Oh, so you disallow that filename or checksum. So I make a different C program and call it something else. There are an infinite number of programs that I can write and it's impossible to block them all. The point here is that there is no such thing as blocking direct access while still letting some programs write to the registry. Either it's writeable or it's not. If it is, then the user can make arbitrary changes. There's no middle ground. Yes, but it isn't black and white either. As we all agree, you have the joy of acl's, which complicates matters. Then you also have the option of purging all current user registry files on logoff.. Letting them make changes to aspects at runtime, but losing them all at the end of the session. Myself, I feel this is the best compromise. Your method is flawed and destroys the existing setup, which is bad. I disable ALL aspects of regedit and other tools, and I know I'm not alone in this. It's perfectly normal and *common* to do it. You can disable every piece of software that has ever existed in the known universe, and I will still be able to make arbitrary registry changes if I want -- provided that the desired HKCU key is writeable. The (l)user should *never* be allowed to edit the registry themselves. That's a recipe for disaster. If you think it is possible to block direct editing of the registry while still allowing HKCU to be writeable, then you are clearly mistaken at how windows security works. This is why you have application allow lists. Admittedly this also isn't foolproof, but it does make it more difficult. Using a command that alters the registry as part of it's function, but does not allow the user to directly alter it is a very different ballgame. mount would be permissable. Some console app to directly edit the registry would not be. There is absolutely no way for a sysadmin to block one and not the other. Brian Oh, I agree, but Thorsten was under the impression that regedit /s would work when regedit itself was disabled - this is blatantly not the case. Aside from that.. The whole concept of security on windows is a bit of a farce.. A compromise is the best you're ever likely to manage. Anyway.. I think this got rather off-topic :P -- Spinning complacently in the darkness, covered and blinded by a blanket of little lives, false security has lulled the madness of this world into a slumber. Wake up! An eye is upon you, staring straight down and keenly through, seeing all that you are and everything that you will never be. Yes, an eye is upon you, an eye ready to blink. So face forward, with arms wide open and mind reeling. Your future has arrived... Are you ready to go? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: CPU usage issue with bash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://cygwin.com/acronyms/#PPIOSPE According to Sarcar, Shourya C (GE Healthcare) on 10/27/2005 1:29 AM: Now it looks like you have two copies of cygwin installed, and that c:\insite\bin is still trying to compete with c:\cygwin\bin. Cygwin does not work well if you have two copies of cygwin1.dll, even if the two copies are the same version. I don't know what insite is trying to provide, but it is probably the source of your problems. Thanks for the help. I am struggling with a legacy system, so do not have the answers right away. I will try to establish some sanity and then ask some more questions if I am still stuck. Is there a specific reason why two versions of Cygwin do not coexist well ? Yes. cygwin1.dll shares memory between all cygwin processes, and if you have two versions of the .dll, the shared memory region is incompatible between them and you are practically guaranteed a crash or other unexpected behavior. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDYMGd84KuGfSFAYARAn5bAJ9u8WMyrpCjklzgcJI0NDrIkzU3sQCaApBH XJNop1P8HlRghpIE/SjPW0g= =BkZl -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tar 1.15.1 broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Alan Hourihane on 10/27/2005 3:30 AM: Now, having upgraded everything to the latest releases things started to go wrong with the packaging scripts. tar started to bleat with Cannot stat: No such file or directory for lots of different things. Can you reproduce this down into a smaller test case? Tar is only printing the error message it gets from calling stat(), so now we need to figure out if tar is passing bad information to stat() or if cygwin is having problems doing the stat(). If you can reproduce a smaller testcase, it might also help to run strace between the two versions to see what might have changed in the sequence of syscalls. I've reverted to tar 1.13.25 and everything is fine. One other thing to note is that I'm building on a samba connected drive if that matters to tar. I don't have access to a samba drive myself, so if it IS drive related (although I am inclined to doubt that), it will be up to you to do a lot of the debugging effort. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] volunteer cygwin tar maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDYMfC84KuGfSFAYARAgnhAJ9Z4pN1D4KGfq2mmzCsmg9h7DTYLACfZhBU wuTQwH0/TgzbXl4GXoNKgU0= =1Nom -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Apache apx2s does not produce shared libs with mod_security
Hi I'm trying to compile mod_security-1.8.7 from o http://www.modsecurity.org as an Apache2 shared module. As I understand it the apxs2 tool is supposed to create shared libs. This is what I get: apxs2 -c mod_security.c /usr/share/apr-build/libtool --silent --mode=compile gcc -prefer-pic -O2 -DAP_HAVE_DESIGNATED_INITIALIZER -DCYGWIN -I/usr/include/apache2 -I/usr/include -I/usr/include -c -o mod_security.lo mod_security.c touch mod_security.slo /usr/share/apr-build/libtool --silent --mode=link gcc -o mod_security.la -rpath /usr/lib/apache2 -module -avoid-versionmod_security.lo libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries Am I doing something wrong ? Latest cygwin packages are installed. Ciao Volker -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Apache apx2s does not produce shared libs with mod_security
On Thu, 27 Oct 2005, Dr. Volker Zell wrote: apxs2 -c mod_security.c /usr/share/apr-build/libtool --silent --mode=compile gcc -prefer-pic -O2 -DAP_HAVE_DESIGNATED_INITIALIZER -DCYGWIN -I/usr/include/apache2 -I/usr/include -I/usr/include -c -o mod_security.lo mod_security.c touch mod_security.slo /usr/share/apr-build/libtool --silent --mode=link gcc -o mod_security.la -rpath /usr/lib/apache2 -module -avoid-versionmod_security.lo libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries libtool always wants -no-undefined switch on cygwin. I guess this is something apxs2 has to add. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tar 1.15.1 broken
On Thu, 2005-10-27 at 06:27 -0600, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Alan Hourihane on 10/27/2005 3:30 AM: Now, having upgraded everything to the latest releases things started to go wrong with the packaging scripts. tar started to bleat with Cannot stat: No such file or directory for lots of different things. Can you reproduce this down into a smaller test case? Tar is only printing the error message it gets from calling stat(), so now we need to figure out if tar is passing bad information to stat() or if cygwin is having problems doing the stat(). If you can reproduce a smaller testcase, it might also help to run strace between the two versions to see what might have changed in the sequence of syscalls. I've reverted to tar 1.13.25 and everything is fine. One other thing to note is that I'm building on a samba connected drive if that matters to tar. I don't have access to a samba drive myself, so if it IS drive related (although I am inclined to doubt that), it will be up to you to do a lot of the debugging effort. O.k. I've found the problem. This works with tar 1.13.25 tar cvjf test.tbz2 files --exclude=file In 1.15.1 it mucks up parsing of --exclude=file and somehow later tries to stat --exclude=file as being the complete filename. But actually when it reports the Cannot stat: No such file or directory message the filename is correct. Moving --exclude=file to this... tar --exclude=file -cvjf test.tbz2 files makes it work. Hope that helps, Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tar 1.15.1 broken
On Thu, 27 Oct 2005, Alan Hourihane wrote: Moving --exclude=file to this... tar --exclude=file -cvjf test.tbz2 files makes it work. I remember... I hit those some time ago too. tar is now more strict where options can be put on the command line. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
OpenSSH w/cygwin
I'm new to Cygwin, wanting to use it to connect to a Unix server using SSH. I see that there is a package for OpenSSH, but don't find it in the setup.exe window or anywhere else. Can someone please point me in the right direction and tell me how to install this package to an existing Cygwin install? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tar 1.15.1 broken
This works with tar 1.13.25 tar cvjf test.tbz2 files --exclude=file Hmm, I agree that the behavior has changed, but am not yet sure it is a bug. I'll ask upstream if the change in behavior was intentional, or whether it should be construed as a bug. In 1.15.1 it mucks up parsing of --exclude=file and somehow later tries to stat --exclude=file as being the complete filename. But actually when it reports the Cannot stat: No such file or directory message the filename is correct. Moving --exclude=file to this... tar --exclude=file -cvjf test.tbz2 files makes it work. The info pages for 1.15 are more explicit - tar supports three types of argument parsing - traditional, short, and long options. Traditional options use no dash, and must be the very first argument. The traditional options also have weird behavior; when using multiple options that require an argument, such as f and b, the syntax is tar fb file blocking (ie. the number of options that required an argument consume that many more arguments). If you are mixing option types, then once the traditional options have been consumed, the next argument must be a short or long option, otherwise all remaining arguments are treated as filenames even if they look like options. The upshot of this is that: tar cvjf test.tbz2 --exclude=file files is different from tar cvjf test.tbz2 files --exclude=file Fixing your invocation to use long options followed by short options instead of traditional options followed by long options is an appropriate workaround. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
how to get a coredump [was RE: Asterisk Cygwin]
As I don't use debuggers every day, I am posing this to the list: On Mon, 24 Oct 2005, Jerris, Michael MI wrote: With the patch on that bug in mantis, everything compiles great and starts, but I am getting segfaults when I try to pass calls. Do you know how to get a coredump, I don't seem to be able to on my machine, just a stackdump which is basically useless. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner Sr. Manager 7 West 24th Street #100 - - +1 (443) 921-0381 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: another manifestation of the .. bug
From: Corinna Vinschen [snip Cygwin non-POSIXness, which unless I'm delirious used to be a big deal to the Cygwin PTB] My point is that I'm happy to make Cygwin mostly POSIX compatible, but that implementing all crude border cases sometimes has more negative impact in other areas (one of them: speed), than it does help to make Cygwin useful (I hear cgf falling from his chair and rolling on the floor laughing in the background). That's why I like the way the OP (?) was going to go about it: add it, test it, and see what the actual impact on performance is. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: OpenSSH w/cygwin
On 10/27/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm new to Cygwin, wanting to use it to connect to a Unix server using SSH. I see that there is a package for OpenSSH, but don't find it in the setup.exe window or anywhere else. After you select a mirror, a category view of the available packages comes up. OpenSSH is under net/openssh. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: how to get a coredump [was RE: Asterisk Cygwin]
Jason Pyeron wrote:
As I don't use debuggers every day, I am posing this to the list:
On Mon, 24 Oct 2005, Jerris, Michael MI wrote:
With the patch on that bug in mantis, everything compiles great and
starts, but I am getting segfaults when I try to pass calls. Do you
know how to get a coredump, I don't seem to be able to on my machine,
just a stackdump which is basically useless.
You can't. Cygwin doesn't do core.
Having said that, as long as you've built the executable with debugging info
('-g'), the stackdump isn't completely useless at all. Cut'n'paste the
addresses in the second column of the file into addr2line
--exe=path/to/executable - this is easily done by cat'ing the file in a
bash shell in a standard DOS box and using the rectangular cut'n'paste feature
it provides. That should show you a backtrace with source file/line numbers,
at any rate.
Other than that, why not just run the exe under gdb, so that it will catch
the segfault when and where it happens?
cheers,
DaveK
--
Can't think of a witty .sigline today
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: how to get a coredump [was RE: Asterisk Cygwin]
thanks I passed it on, and it sound like it will help -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner Sr. Manager 7 West 24th Street #100 - - +1 (443) 921-0381 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to get a coredump [was RE: Asterisk Cygwin]
On Thu, Oct 27, 2005 at 12:17:15PM -0400, Jason Pyeron wrote: As I don't use debuggers every day, I am posing this to the list: On Mon, 24 Oct 2005, Jerris, Michael MI wrote: With the patch on that bug in mantis, everything compiles great and starts, but I am getting segfaults when I try to pass calls. Do you know how to get a coredump, I don't seem to be able to on my machine, just a stackdump which is basically useless. Add error_start:/usr/bin/dumper.exe to your CYGWIN environment variable. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hang with 20051018 (3rd version) snapshot while building OOo
(BIG-SNIP) I only paste/attach the 20051024 info, if there is interest I can also send the 20051023 info. (snip) I would like to see the old strace and any other straces you have to see if there's any pattern to something I'm noticing. I got a few more, but before spamming this list with straces I have some news. We managed to reproduce the hangs on that particular machine more easily now, but I didn't have the time yet to try to reproduce it on my machines. I hope tonight ... But I can relay the answers to the following questions: I don't see any large times being reported at the beginning of the strace. I'd expect that if you notice the hang, attach to the process, and then do the ls /proc/hangpid/fd. Can you give me a feel for times of: First reproducibility: Initially the 20051024 hung every ~ 10 minutes, but now (At the time I got the email) it is running for more than 15 hours. - noticed the problem 1 min - several hours, then doing ps and cygcheck. - attached to process with strace 5-10 minutes after noticing (max) - performed ls 1 min (right after...) Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
Re: Hang with 20051018 (3rd version) snapshot while building OOo
On Thu, Oct 27, 2005 at 01:04:25PM -0400, Volker Quetschke wrote: (BIG-SNIP) I only paste/attach the 20051024 info, if there is interest I can also send the 20051023 info. (snip) I would like to see the old strace and any other straces you have to see if there's any pattern to something I'm noticing. I got a few more, but before spamming this list with straces I have some news. We managed to reproduce the hangs on that particular machine more easily now, but I didn't have the time yet to try to reproduce it on my machines. I hope tonight ... But I can relay the answers to the following questions: I don't see any large times being reported at the beginning of the strace. I'd expect that if you notice the hang, attach to the process, and then do the ls /proc/hangpid/fd. Can you give me a feel for times of: First reproducibility: Initially the 20051024 hung every ~ 10 minutes, but now (At the time I got the email) it is running for more than 15 hours. - noticed the problem 1 min - several hours, then doing ps and cygcheck. - attached to process with strace 5-10 minutes after noticing (max) - performed ls 1 min (right after...) Are you sure that attaching to the process with strace isn't what actually what caused the process to start up? I don't see any 1 minute delays in the strace log. However, if you could wait for a couple minutes between attaching via strace and doing the ls that might be instructive. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to get a coredump [was RE: Asterisk Cygwin]
Christopher Faylor wrote: Add error_start:/usr/bin/dumper.exe to your CYGWIN environment variable. Is there a reason why this isn't the default? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to get a coredump [was RE: Asterisk Cygwin]
On Thu, Oct 27, 2005 at 02:09:01PM -0400, Rolf Campbell wrote: Christopher Faylor wrote: Add error_start:/usr/bin/dumper.exe to your CYGWIN environment variable. Is there a reason why this isn't the default? WJM? cgf (Wow. It's been a while. That felt good.) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rebase emacs [was: cygwin-setup rebaseall]
On Wed, 26 Oct 2005, Satish Balay wrote: On Tue, 25 Oct 2005, Brian Dessent wrote: As far as I know almost all of the issues of corrupted DLLs have been fixed, but there still remains at least one known problem: emacs will hang and refuse to start after running rebaseall, unless you revert cygncurses-7.dll to its non-rebased version. However other ncurses programs don't seem to have an issue with the rebased DLL. I've had issues with emacs when using it over ssh. Maybe this is the reason. I should try reverting this dll and try again. Ok - I tried a complete 'reinstall' [from setup menu] - and now emacs works fine [both locally - and via ssh] Satish -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: AllVersions: Running Cygwin X w/ Registy Entries
* Chris Taylor (2005-10-27 12:43 +0100) Brian Dessent wrote: Chris Taylor wrote: Oh, I agree, but Thorsten was under the impression that regedit /s would work when regedit itself was disabled - this is blatantly not the case. That's /exactly/ the case. I've been to Internet Cafes where I couldn't launch regedit - but regedit /s in a batch worked just fine. Where I'm now sitting I cannot launch cmd.exe (This operation has been cancelled due to restrictions in effect on this computer. Please contact your system administrator. But I'm perfectly able to run /any/ batch script - which just runs cmd.exe (visible in Task Manager). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: python rebase [Was: cygwin-setup rebaseall]
On Wed, 26 Oct 2005, Brian Dessent wrote: Satish Balay wrote: According to Jason's post, --enable-auto-image-base is been in use for a while. [Since python doesn't always work without rebaseall] - is there some other issue with this approach? [mabye some dependent package should be built with --enable-auto-image-base - but it isn't?] It is used for python itself, but it's not used for DLLs in other packages that python modules might load. That is why you still have to rebaseall for python to work. In order to completely retire rebaseall, *every* package that contains a DLL must be compiled with this option. Of course in reality, not every DLL necessarily *has* to be rebased, only those that might be dynamically loaded at runtime, and even then it's not always necessary. But it's hard to determine which particular cases those might be, and so in the general case you have to assign a unique base address to every DLL. I've tried using python after doing a complete 'reinstall' and so far It works fine. I'll keep track of any future breakages. It will be great if rebase is not required at all... Satish -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: python rebase [Was: cygwin-setup rebaseall]
Satish, On Thu, Oct 27, 2005 at 02:15:01PM -0500, Satish Balay wrote: I've tried using python after doing a complete 'reinstall' and so far It works fine. I'll keep track of any future breakages. It will be great if rebase is not required at all... The following is a good test: $ python /usr/lib/python2.4/test/regrtest.py Do you get any unable to remap errors? Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: python rebase [Was: cygwin-setup rebaseall]
On Thu, 27 Oct 2005, Jason Tishler wrote: Satish, On Thu, Oct 27, 2005 at 02:15:01PM -0500, Satish Balay wrote: I've tried using python after doing a complete 'reinstall' and so far It works fine. I'll keep track of any future breakages. It will be great if rebase is not required at all... The following is a good test: $ python /usr/lib/python2.4/test/regrtest.py Do you get any unable to remap errors? I don't see any remap errors, but the first time I tried - it gave thread errros. The second time - it completed fine. BTW: we disable threads on cygwin+python-2.4. Is this problem likely to get fixed? [I'm guessing its upstream issue - where I see sem_xx errors on AIX as well] thanks, Satish - test_slice test_socket sem_init: Resource temporarily unavailable Unhandled exception in thread started by bound method SmallBufferedFileObjectCl assTestCase.clientRun of test.test_socket.SmallBufferedFileObjectClassTestCase testMethod=testFullRead Traceback (most recent call last): File /tmp/python.572/usr/lib/python2.4/test/test_socket.py, line 121, in cli entRun File /usr/lib/python2.4/threading.py, line 348, in wait self.__cond.wait(timeout) File /usr/lib/python2.4/threading.py, line 197, in wait -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: OpenSSH w/cygwin
On 10/27/05, rogersbr wrote: I'm new to Cygwin, wanting to use it to connect to a Unix server using SSH. I see that there is a package for OpenSSH, but don't find it in the setup.exe window or anywhere else. Can someone please point me in the right direction and tell me how to install this package to an existing Cygwin install? (You probably know this, but just in case...) You don't need anything as awesome as Cygwin, if *all* you need is an ssh client for Windows. You can use PuTTY, which is Windows-native (doesn't need cygwin1.dll or anything of the sort), and can be run as a GUI application or a command-line application, at your preference. http://www.chiark.greenend.org.uk/~sgtatham/putty/ -Eliah -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to get a coredump [was RE: Asterisk Cygwin]
Christopher Faylor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Thu, Oct 27, 2005 at 12:17:15PM -0400, Jason Pyeron wrote: As I don't use debuggers every day, I am posing this to the list: On Mon, 24 Oct 2005, Jerris, Michael MI wrote: With the patch on that bug in mantis, everything compiles great and starts, but I am getting segfaults when I try to pass calls. Do you know how to get a coredump, I don't seem to be able to on my machine, just a stackdump which is basically useless. Add error_start:/usr/bin/dumper.exe to your CYGWIN environment variable. Well either that or the man page is slightly wrong. the manpage says: One common way to use dumper is to plug it into cygwin's Just-In-Time debugging facility by adding error_start=x:\path\to\dumper.exe to theCYGWIN environmentvariable.Pleasenotethat x:\path\to\dumper.exe is Windows-style and not cygwin path. If error_start is set this way, then dumper will be started whenever some program encounters a fatal error. That makes it explicit that windows paths must be used, but your post does not use it. Without doing any testing, I'll guess that the man page is out of date. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to get a coredump [was RE: Asterisk Cygwin]
Joe Smith wrote: Add error_start:/usr/bin/dumper.exe to your CYGWIN environment variable. Well either that or the man page is slightly wrong. the manpage says: The manpage and users guide are correct, it takes a win32 path. That makes it explicit that windows paths must be used, but your post does not use it. Without doing any testing, I'll guess that the man page is out of date. People make typos in emails on occasion, even project leaders. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin strange error after installing new package -- bash: /usr/bin/tr: No such file or directory
On 10/27/05, Lei Sun [EMAIL PROTECTED] wrote: Hi, The error message seems to be too general, google just returned tons of junk. Story: 1. Fresh install of cygwin, chose some package, happily using it for like an hour or two 2. found that I need to install some additional package, so I stopped all cygwin process, and went back to setup.exe and did the install of the new package. 3. When I relaunch the cygwin, I see abnormal shell window with an error message: bash: /usr/bin/tr: No such file or directory and Suddenly, the programs that I comipled doesn't work any more. I checked the PATH, they are all there, (except tr) This happened to me for 3 times today, which really pisses me off. Would someone please help me. Here is the cygcheck log: Cygwin Configuration Diagnostics Current System Time: Thu Oct 27 19:57:06 2005 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path:C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\Perl\bin\ c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\UltraEdit c:\Program Files\SecureCRT 3.0 Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(lsun) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(lsun) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = `lsun' PWD = `/home/lsun' CYGWIN = `server' HOME = `/home/lsun' MAKE_MODE = `unix' HOMEPATH = `\Documents and Settings\Lei Sun' MANPATH = `/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = `C:\Documents and Settings\Lei Sun\Application Data' TERM = `cygwin' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel' WINDIR = `C:\WINDOWS' OLDPWD = `/usr/bin' USERDOMAIN = `JUPITER' OS = `Windows_NT' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' !:: = `::\' TEMP = `/cygdrive/c/DOCUME~1/LEISUN~1/LOCALS~1/Temp' COMMONPROGRAMFILES = `C:\Program Files\Common Files' USERNAME = `Lei Sun' PROCESSOR_LEVEL = `15' FP_NO_HOST_CHECK = `NO' SYSTEMDRIVE = `C:' USERPROFILE = `C:\Documents and Settings\Lei Sun' CLIENTNAME = `Console' PS1 = `$ ' LOGONSERVER = `\\JUPITER' PROCESSOR_ARCHITECTURE = `x86' !C: = `C:\cygwin\bin' SHLVL = `1' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = `C:' PROMPT = `$P$G' COMSPEC = `C:\WINDOWS\system32\cmd.exe' TMP = `/cygdrive/c/DOCUME~1/LEISUN~1/LOCALS~1/Temp' SYSTEMROOT = `C:\WINDOWS' PRINTER = `Microsoft Office Document Image Writer' CVS_RSH = `/bin/ssh' PROCESSOR_REVISION = `0209' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' INFOPATH = `/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = `C:\Program Files' NUMBER_OF_PROCESSORS = `2' SESSIONNAME = `Console' COMPUTERNAME = `JUPITER' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd NTFS 30725Mb 35% CP CS UN PA FC d: hd NTFS 83745Mb 90% CP CS UN PA FC e: hd NTFS 57254Mb 85% CP CS UN PA FC f: cd N/AN/A g: cd N/AN/A h: cd N/AN/A i: hd FAT3276290Mb 1% CPUN WD Passport C:\cygwin / system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode . /cygdrive system binmode,cygdrive Found: C:\cygwin\bin\awk.exe Found: C:\cygwin\bin\bash.exe Not Found: cat Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cpp.exe Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\gcc.exe Not Found: gdb Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\mv.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\sh.exe Found:
Re: how to get a coredump [was RE: Asterisk Cygwin]
On Thu, Oct 27, 2005 at 08:48:57PM -0700, Brian Dessent wrote: Joe Smith wrote: Add error_start:/usr/bin/dumper.exe to your CYGWIN environment variable. Well either that or the man page is slightly wrong. the manpage says: The manpage and users guide are correct, it takes a win32 path. Yes. Sorry. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
